Kernel Panic - Part 2 (ABANDONED)

Linux Support
1

Hi Mark - kernel panic has raised it’s ugly head again after updating Mint 18.3 >:(

I ran through your instructions from here -

http://linuxforums.org.uk/index.php?topic=13291.msg108388#msg108388

twice, but to no avail this time - yet they have worked flawlessly in the past.

For the life of me I can’t figure out why this keeps happening? It seems that the bootloader files ‘may’ be the culprit as they seem to be getting overwritten on updates but why, I haven’t a clue. This has never happened before on any distro I’ve used in the past. :o I’m wondering if the Update Manager itself may be at fault but truthfully, I’m clutching at straws!

After the Meltdown/Spectre fiasco and the faff I had to get the patched kernel installed, I’ve deliberately unchecked updated kernels from the Update Manager list but something else must have slipped through this time. I’m currently booted from the M18.3 install disk and have disconnected my 2nd (slave) drive as in the past so as to work only with my main HDD.

Any guidance would be welcome!

Thanks

Rich

EDIT: I also ran an integrity check from the install disk but no errors were reported.

2

GRUB files have to be overwritten when you get a kernel upgrade … otherwise they’d point to the wrong kernel.

Anyway, I’d be more boothered why you keep getting kernel (or GRUB)updates at all in Mint … I thought the Mint update manager classed kernel and GRUB updates as “level 5” so didn’t apply them ?

Are you applying them manually ?

So where do we stand currently … are you able to boot into Mint 17 (or whatever the second distro was) ?

Will Mint18 boot if you select the previous Mint 18 kernel ?

3

In the meantime I tried swapping the data ribbon for a spare I have (in case it was a faulty cable) but that hasn’t worked either so I’ve returned to original set up. From the install disk, GParted ‘sees’ both sda1 (160 GiB with M18.3 installed) and sdb1 (40GiB with M18.1 installed) and from the Desktop, ‘Computer’ ‘sees’ all the users and files so everything looks to be intact - it just refuses to boot to anything. ??? I’ve double-checked all connections etc so now I’m stumped!

What really bothers me is why this keeps happening? It’s done it twice since my original post but both times your instructions worked fine. Perhaps there is a more serious underlying problem? I’ve never had this issue with other distro’s (as far as I can recall) so it’s a real puzzle.

4

I’m surprised Mint is updating the kernel at all, their update manager is specifically set not to … for this very reason.

Anyway, boot to the LiveUSB and post the output from:

sudo fdisk -l

and

sudo blkid
5

As requested -


mint@mint ~ $ sudo fdisk -l
Disk /dev/loop0: 1.8 GiB, 1867780096 bytes, 3648008 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0001ba51

Device     Boot     Start       End   Sectors   Size Id Type
/dev/sda1  *         2048   3905535   3903488   1.9G 83 Linux                 *Boot partition
/dev/sda2         3907582 312580095 308672514 147.2G  5 Extended
/dev/sda5         3907584  42967039  39059456  18.6G 83 Linux         *Operating System       
/dev/sda6       304769024 312580095   7811072   3.7G 82 Linux swap / Solaris
/dev/sda7        42969088 304752639 261783552 124.8G 83 Linux   *Home partition[/b]

Partition table entries are not in disk order.
mint@mint ~ $

mint@mint ~ $ sudo blkid
/dev/sda1: UUID="a26bc950-d260-4a63-a445-4740125cf628" TYPE="ext4" PARTUUID="0001ba51-01"
/dev/sda5: UUID="de5ae2cf-f7c1-4f91-a9c5-949295740ba2" TYPE="ext4" PARTUUID="0001ba51-05"
/dev/sda7: UUID="9b884754-f604-421e-a4a1-e0c4bb30c64c" TYPE="ext4" PARTUUID="0001ba51-07"
/dev/sr0: UUID="2017-11-24-14-47-32-00" LABEL="Linux Mint 18.3 MATE 64-bit" TYPE="iso9660" PTUUID="568a6b74" PTTYPE="dos"
/dev/loop0: TYPE="squashfs"
/dev/sda6: UUID="43554194-1663-4a37-95c7-0724c4d0aa2e" TYPE="swap" PARTUUID="0001ba51-06"
mint@mint ~ $
6

I thought you had 2 hard drives in this machine ?

It’s only showing one … are both connected,? … and are both being seen by the BIOS ?

7

Quote from my first post -
I’m currently booted from the M18.3 install disk and have disconnected my 2nd (slave) drive as in the past so as to work only with my main HDD.

I disconnected the 2nd drive in preparation for any repair to the main drive - as you have requested in the past. When both drives are connected, both are recognised by BIOS and also by Grub but neither will boot. GParted sees both and all can be mounted and viewed from the install disk.

8

Okay on the HDD that’s attached now, do you have separate
/boot (at sda1)
and
/ (at sda5)
and
/home (at sda6)
partitions ?

If so, boot the LiveDVD and run:

sudo mount /dev/sda5 /mnt

then

sudo mount /dev/sda1 /mnt/boot

then

for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done

then

sudo chroot /mnt

then

grub-install /dev/sda

then

update-grub

then hit Ctrl+D to exit the chroot environment.

Now reboot … did Mint 18 boot ?

9

No boot again with these commands. :frowning:

I get an error… something/something about hd0, press any key to continue … then after a few seconds it changes to an output, ending - not syncing: VFS unable to mount root fs on unknown-block (0,0)

I had this the last time I posted (Meltdown and Spectre post) and you altered the last command from ‘update-grub’ to … 'update-initramfs -uk all… and I’ve tried this again but, unfortunately, with the same result.

As I said, this has happened a couple of times since my original post and either/or of your previous instructions worked fine - but not this time. The OS performs beautifully ordinarily, it’s just the updating that screws things up. From memory, I may have ticked the middle (let me choose?) option at install but I never let the level 5 updates install. When up and running, can I change that option to ‘just keep my computer safe’ or can it only be done at the installation stage?

I am willing to re-install from fresh if necessary but there’s no guarantee that this fault won’t re-occur - plus the added hassle of getting everything off and on to the drive every time. Is there a utility or terminal script I could run that would indicate where the fault lies? Researching ‘kernel panic’ throws up many causes, one of the most prevalent seems to be about ‘ram timeout’ or some such which stalls the boot process. Can this be increased in any way?

Thanks again for your time.

Rich

10

Hi - I’ve bitten the bullet and re-installed the OS (downgraded to Mint 18.1) as I was just going round in circles with Mint 18.3. :frowning:

I’ll mark this thread as abandoned and start a new thread regarding M18.1 configuration.

Thanks for your help so far.
Rich