Re: Kernel panic (SOLVED)

Hi All

Mint 18.2 refuses to boot after a general update (via Update Manager). After a similar issue a while ago I stopped adding new kernels but this time I recall a ‘Linux Headers for development’ being included and wonder if this has caused the problem? The boot hangs with …Kernel panic - not syncing: unable to mount root fs on unknown-block (0,0).

I’ve tried other (older) kernels from the ‘Advanced’ list in Grub but get the same result.

Mint 17 works ok (it’s on a separate drive) and this is where I’m typing this post from. From 17, doing a ‘sudo update-grub’ has no effect.

From 17’s menu (Computer) I can see all my data etc in M18 so it’s all there, I just can’t boot to it.

Any help greatly appreciated!

Rich

PS: It was all working fine up to last evening which is when I did the update before closing down for the night, so it must be something in there that’s caused the issue. There’s been no messing about inside the box or moving of the computer - just the software update.

Can you post the output from:

sudo fdisk -l

and

sudo blkid

and

mount

from Mint 17

Hi Mark - I’m having to get this info via my M18 install disk as now neither M17 or M18 will boot. What I’ve tried so far -

I disconnected M17 (sda) and ran my boot repair disk on M18 (sdb) - both to repair Grub and MBR. It didn’t work - on boot it hung on ‘Grub rescue’.

I then disconnected M18, reconnected M17 and tried to boot it but that hung on ‘Grub rescue’ also. Trying boot repair and MBR repair on M17 has also failed and I’m still stuck at ‘Grub rescue’.

If it helps - when M18 first failed to boot it had a long list of kernels under ‘advanced’, each of which I tried to boot from but none worked. M17 booted ok at this stage but after trying the repairs, neither distro boots! Could it be that the partition containing the kernels has become overloaded? I know that Mint doesn’t automatically discard old kernels and this can sometimes cause issues?

Thanks for the help.

Rich

BTW - currently only Mint 17 disk is connected.

I needed both disks attached, preferably to the same ports they were originally connected to.

Ok, will repost shortly :wink:

Here you go - 3rd time lucky??

mint@mint ~ $ sudo fdisk -l
Disk /dev/ram0: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram1: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram2: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram3: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram4: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram5: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram6: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram7: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram8: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram9: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram10: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram11: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram12: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram13: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram14: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/ram15: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/loop0: 1.7 GiB, 1757536256 bytes, 3432688 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 980991 978944 478M 83 Linux
/dev/sda2 983038 312580095 311597058 148.6G 5 Extended
/dev/sda5 983040 152638097 151655058 72.3G 83 Linux
/dev/sda6 304693248 312580095 7886848 3.8G 82 Linux swap / Solaris

Disk /dev/sdb: 37.3 GiB, 40020664320 bytes, 78165360 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: 0x7ad54111

Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 976895 974848 476M 83 Linux
/dev/sdb2 978942 78163967 77185026 36.8G 5 Extended
/dev/sdb5 * 978944 70352895 69373952 33.1G 83 Linux
/dev/sdb6 70354944 78163967 7809024 3.7G 82 Linux swap / Solaris
mint@mint

mint@mint ~ $ sudo blkid
/dev/sda1: UUID=“bd41cb59-1633-4957-8b92-e85530ad0662” TYPE=“ext4” PARTUUID=“0001ba51-01”
/dev/sda5: UUID=“fd7a3f3e-5d95-48cb-ab1b-0a7415cfd185” TYPE=“ext4” PARTUUID=“0001ba51-05”
/dev/sdb1: UUID=“e5fdbb08-9250-489a-9e9a-d83de51b2f45” TYPE=“ext4” PARTUUID=“7ad54111-01”
/dev/sdb5: UUID=“b5f3259f-385a-4768-b6de-a27a60a03468” TYPE=“ext4” PTTYPE=“dos” PARTUUID=“7ad54111-05”
/dev/sr0: UUID=“2016-12-14-02-09-46-00” LABEL=“Linux Mint 18.1 Cinnamon 64-bit” TYPE=“iso9660” PTUUID=“42c22cba” PTTYPE=“dos”
/dev/loop0: TYPE=“squashfs”
/dev/sda6: UUID=“eed0839a-eded-443d-91b6-f1c239008fe0” TYPE=“swap” PARTUUID=“0001ba51-06”
/dev/sdb6: UUID=“7878d4b2-294f-4d21-974c-7929419f617a” TYPE=“swap” PARTUUID=“7ad54111-06”
mint@mint ~ $

mint@mint ~ $ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1008396k,nr_inodes=252099,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=204696k,mode=755)
/dev/sr0 on /cdrom type iso9660 (ro,noatime)
/dev/loop0 on /rofs type squashfs (ro,noatime)
/cow on / type overlay (rw,relatime,lowerdir=//filesystem.squashfs,upperdir=/cow/upper,workdir=/cow/work)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (rw,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb,release_agent=/run/cgmanager/agents/cgm-release-agent.hugetlb)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event,release_agent=/run/cgmanager/agents/cgm-release-agent.perf_event)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset,clone_children)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids,release_agent=/run/cgmanager/agents/cgm-release-agent.pids)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
cgmfs on /run/cgmanager/fs type tmpfs (rw,relatime,size=100k,mode=755)
tmpfs on /run/user/999 type tmpfs (rw,nosuid,nodev,relatime,size=204696k,mode=700,uid=999,gid=999)
gvfsd-fuse on /run/user/999/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=999,group_id=999)
/dev/sdb5 on /media/mint/b5f3259f-385a-4768-b6de-a27a60a03468 type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)
mint@mint

I hope this is now correct? I’ve no idea what happened last time - perhaps a bad connection?

I’ve checked with GParted and the disks show as they should and ‘Computer’ shows all data present and correct on both disks - phew!!

Did you have a separate /boot and/or /home partition in Mint 17 ?

I’m trying to figure out why you have 2 Linux partitions on the M17 drive.

Way back, when I’d finally settled on Mint as our main distro I configured the hdd (IIRC as per your guidance) with a small, initial boot partition and a swap area. This was to get over an issue with the installation failing due to the boot files not being found on a large-sized disk. (From memory, a BIOS problem?) This config worked fine, so when I added the smaller disk as a trial for Mint 18, I set it up exactly the same way and this worked fine too - up until the ‘kernel panic’! Initially, there was a bit of a faff with Grub not ‘seeing’ the correct partition but you sorted that too, many thanks!

I did ask about the fact that, somehow, the M18 boot files had been put on sdb5 (where they are on sda1 in M17) and whether they should be re-installed to the boot partition, but you advised to leave well alone! Now, I’m wondering, has the boot partition on M17 (sda1) become ‘overloaded’ with kernels? This must be the place that Grub goes to as M17 is the 1st on the list for boot? Or am I way off the mark?

Looking from the install disk, in GParted and ‘Computer’, all appears fine with the data but booting to it is the problem, suggesting it is Grub and/or the MBR that has become corrupted?

It’s my intention to wipe M17 from the large hdd and install M18 on it as the main distro now that I’m confident that M18 works in 64bit on this box. The small hdd would then be set up as data storage only but before I do that, I need to get at some important emails and get those saved. I should be able to rescue the other stuff ok, but watch this space!

Any further advice would be most welcome!

Rich

So where do you want to go from here ?

M17 would probably be the easier fix … just reinstalling GRUB

M18 (as it failed during updates) may be somewhat harder … but if you’re planning on reinstalling from scratch anyway, wouldn’t it be simpler to just boot a LiveUSB and copy off anything you need to keep ?

As a first step, I’d like to get M17 repaired please, as my missus has some ancestry stuff on there she’s desperate to save. I’ve tried to copy some stuff off already (from the install disk) with limited success - some files copied ok but others threw up permission errors… and I don’t know how to access the emails from the install disk. Hopefully, with M17 reinstated, copying off should be more straightforward.

If we can get grub back on M17 - would a ‘grub-update’ not find M18 anyway, as it did before?

I realise this is a rigmarole but it just happened that 17 got put on 1st - long before I decided to change to the 64bit version. I read that most 32bit software support would eventually cease so thought it prudent to update things now, rather than later.

Much appreciate your efforts on my behalf!

Rich

If we can get grub back on M17 - would a 'grub-update' not find M18 anyway, as it did before?

Quite possibly, but it sounded like more than GRUB was broken in M18

Anyway, attach just the M17 drive … preferably on the SATA-1 port.

Boot to a LiveUSB

Open a terminal and run these commands in sequence:

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.

Close the terminal

Shut down the PC

Remove the LiveUSB stick

Boot the PC

Hopefully you’ll be back in Mint 17 … If you are let me know and we’ll move on to attempting to fix Mint 18

Fantastic! Took all of 5 minutes! I can’t thank you enough…

Oddly, though - when it booted and the Grub screen flashed up it listed Ubuntu… and I’d used the M18 install disk as the medium ??? ???

Still, what the heck! Merry Christmas!

Ok, stage 2 when you’re ready, please! (Shakes head ;D)

Add the M18 drive back in … making sure it’s on SATA-2 … so the M17 drive stays as the first hard drive.

Boot, and you should be back in Mint 17

Open a terminal and run:

sudo update-grub

and post the output back here.

All good up to here - now the output

~ $ sudo update-grub
[sudo] password for richard:
Generating grub configuration file …
Found linux image: /boot/vmlinuz-3.13.0-24-generic
Found initrd image: /boot/initrd.img-3.13.0-24-generic
Found memtest86+ image: /memtest86+.elf
Found memtest86+ image: /memtest86+.bin
No volume groups found
Found Linux Mint 18.2 Sonya (18.2) on /dev/sdb5
done

And good to here - I’ll now reboot and see if M18 fires up and report back.

Update: Grub now lists M17 and M18 in the correct order and correct syntax (no mention of Ubuntu)

M17 boots ok. M18 doesn’t boot and hangs at ‘kernel panic’ as before.

Will Mint 18 boot if you select an earlier kernel ?

Well I’ll be a … :o

All failed except this one - 4.8.0-53, which booted slowly (showed a tty login screen twice and the NVidia screen, weirdly) but booted successfully.

Here’s what I got from the Terminal

richard@richard-OEM ~ $ uname -r
4.8.0-53-generic

and

richard@richard-OEM ~ $ dpkg -l | grep linux-image
ii linux-image-4.10.0-33-generic 4.10.0-33.37~16.04.1 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii linux-image-4.10.0-35-generic 4.10.0-35.39~16.04.1 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii linux-image-4.10.0-37-generic 4.10.0-37.41~16.04.1 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii linux-image-4.4.0-53-generic 4.4.0-53.74 amd64 Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii linux-image-4.4.0-93-generic 4.4.0-93.116 amd64 Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii linux-image-4.8.0-53-generic 4.8.0-53.56~16.04.1 amd64 Linux kernel image for version 4.8.0 on 64 bit x86 SMP
ii linux-image-extra-4.10.0-33-generic 4.10.0-33.37~16.04.1 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii linux-image-extra-4.10.0-35-generic 4.10.0-35.39~16.04.1 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii linux-image-extra-4.10.0-37-generic 4.10.0-37.41~16.04.1 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii linux-image-extra-4.4.0-53-generic 4.4.0-53.74 amd64 Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii linux-image-extra-4.4.0-93-generic 4.4.0-93.116 amd64 Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii linux-image-extra-4.8.0-53-generic 4.8.0-53.56~16.04.1 amd64 Linux kernel extra modules for version 4.8.0 on 64 bit x86 SMP
richard@richard-OEM ~ $

Is it possible to clean up this list, just leaving 4.8.0-53?

I can manage for now if needs be as long as I can get in to M18 - as soon as I’ve copied off the data, I’ll be starting afresh anyway.

Yes, boot into the working 4.8.0-53 kernel and post the output from:

dpkg -l | grep 4.4.0

and:

dpkg -l | grep 4.10.0

Can you please remember to surround your terminal output with CODE tags when posting … TIA :slight_smile:


richard@richard-OEM ~ $ dpkg -l | grep 4.4.0
ii  linux-headers-4.4.0-53                      4.4.0-53.74                                  all          Header files related to Linux kernel version 4.4.0
ii  linux-headers-4.4.0-53-generic              4.4.0-53.74                                  amd64        Linux kernel headers for version 4.4.0 on 64 bit x86 SMP
ii  linux-headers-4.4.0-93                      4.4.0-93.116                                 all          Header files related to Linux kernel version 4.4.0
ii  linux-headers-4.4.0-93-generic              4.4.0-93.116                                 amd64        Linux kernel headers for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-4.4.0-53-generic                4.4.0-53.74                                  amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-4.4.0-93-generic                4.4.0-93.116                                 amd64        Linux kernel image for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-extra-4.4.0-53-generic          4.4.0-53.74                                  amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii  linux-image-extra-4.4.0-93-generic          4.4.0-93.116                                 amd64        Linux kernel extra modules for version 4.4.0 on 64 bit x86 SMP
ii  linux-libc-dev:amd64                        4.4.0-103.126                                amd64        Linux Kernel Headers for development
richard@richard-OEM ~ $ 

richard@richard-OEM ~ $ dpkg -l | grep 4.10.0
ii  linux-headers-4.10.0-33                     4.10.0-33.37~16.04.1                         all          Header files related to Linux kernel version 4.10.0
ii  linux-headers-4.10.0-33-generic             4.10.0-33.37~16.04.1                         amd64        Linux kernel headers for version 4.10.0 on 64 bit x86 SMP
ii  linux-headers-4.10.0-35                     4.10.0-35.39~16.04.1                         all          Header files related to Linux kernel version 4.10.0
ii  linux-headers-4.10.0-35-generic             4.10.0-35.39~16.04.1                         amd64        Linux kernel headers for version 4.10.0 on 64 bit x86 SMP
ii  linux-headers-4.10.0-37                     4.10.0-37.41~16.04.1                         all          Header files related to Linux kernel version 4.10.0
ii  linux-headers-4.10.0-37-generic             4.10.0-37.41~16.04.1                         amd64        Linux kernel headers for version 4.10.0 on 64 bit x86 SMP
ii  linux-image-4.10.0-33-generic               4.10.0-33.37~16.04.1                         amd64        Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii  linux-image-4.10.0-35-generic               4.10.0-35.39~16.04.1                         amd64        Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii  linux-image-4.10.0-37-generic               4.10.0-37.41~16.04.1                         amd64        Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii  linux-image-extra-4.10.0-33-generic         4.10.0-33.37~16.04.1                         amd64        Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii  linux-image-extra-4.10.0-35-generic         4.10.0-35.39~16.04.1                         amd64        Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii  linux-image-extra-4.10.0-37-generic         4.10.0-37.41~16.04.1                         amd64        Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
richard@richard-OEM ~ $ 

Is this correct? I don’t recall ever doing this before…

That’s spot on … it not only keeps the forum neater, but more importantly it keeps the output text formatting intact.

Anyway, make sure you’re booted to the 4.8.0-53 kernel and run this long command to remove all the others:

sudo apt-get remove --purge linux-headers-4.4.0-53  linux-headers-4.4.0-53-generic linux-headers-4.4.0-93 linux-headers-4.4.0-93-generic linux-image-4.4.0-53-generic linux-image-4.4.0-93-generic linux-image-extra-4.4.0-53-generic linux-image-extra-4.4.0-93-generic linux-headers-4.10.0-33 linux-headers-4.10.0-33-generic linux-headers-4.10.0-35 linux-headers-4.10.0-35-generic linux-headers-4.10.0-37 linux-headers-4.10.0-37-generic linux-image-4.10.0-33-generic linux-image-4.10.0-35-generic linux-image-4.10.0-37-generic linux-image-extra-4.10.0-33-generic linux-image-extra-4.10.0-35-generic linux-image-extra-4.10.0-37-generic

Hi Mark and thanks again for your invaluable help! All is ok for the moment so I’ll mark this as solved.

I’ll now crack on and back up all my data in preparation to installing a fresh version of M18 on to sda. (At some point later, I’d like to make sdb a data disk also)

If it’s ok with you, I’ll come back with a new post about manually partitioning the drive? I think having a separate ‘home’ partition, as well as ‘boot’, ‘/’ and ‘swap’ might be the way to go with the new arrangement but would appreciate guidance before I begin. :wink:

Thanks again and have a great Christmas!

Rich