Unable to Boot after Update and Full-Upgrade including kernel 4.4.0-36-generic

[Pliny.D.Elder]

"My only disappoint here is that I didn't learn what the problem was and how to prevent/correct it".
Yeah would have been useful.
I always keep a usb with boot-repair burned on it. Has saved me many a time.
https://sourceforge.net/projects/boot-repair-cd/
Good look with your next install.

[dbyentzen]

"My only disappoint here is that I didn't learn what the problem was and how to prevent/correct it".
Yeah would have been useful.
I always keep a usb with boot-repair burned on it. Has saved me many a time.
https://sourceforge.net/projects/boot-repair-cd/
Good look with your next install.

Yup! Learned a lesson here--also a bit disappointed in that this was the first problem in five years that I wasn't able to fix.  I'll be loading boot-repair on a usb soon! I'm also considering, in addition to regular backups, Cloning my system from time to time---any thoughts or experience with this?

Fresh install with 4.4.0-36-generic is working without problems!  

Thanks for the help!

[Pliny.D.Elder]

I would recommend Clonezilla
http://clonezilla.org/downloads.php
I used it for windows with no problems.
There are plenty of guides on the net for using with gnu/linux.
It's really simple once you have backed up a few times.
Here's some others.
http://www.tecmint.com/linux-disk-cloning-tools/
http://www.howtogeek.com/206491/how-to-r...ous-state/

[AJSlye]

May I suggest that if your having trouble with drivers after the update, you might want to leave the default settings in the update manager (mintupdate). By default anything with a 4 or 5 level is not selected for update, this includes the kernel and xorg drivers.

Level 4:
Unsafe packages. Updates classified as level 4 could have a potential negative affect on system stability. Deselected by default for safety and visibility.

Level 5: Dangerous packages. Updates classified as level 5 can have a negative affect on system stability depending on the system hardware and specifications. Also deselected for safety and visibility.
Although there are users who claim that level 4 and level 5 updates disrupt their systems when it comes to stability, there are plenty of users who select level 4 and level 5 for updating and not having any problems with their system after updating.

[dbyentzen]

May I suggest that if your having trouble with drivers after the update, you might want to leave the default settings in the update manager (mintupdate). By default anything with a 4 or 5 level is not selected for update, this includes the kernel and xorg drivers.

Level 4:
Unsafe packages. Updates classified as level 4 could have a potential negative affect on system stability. Deselected by default for safety and visibility.

Level 5: Dangerous packages. Updates classified as level 5 can have a negative affect on system stability depending on the system hardware and specifications. Also deselected for safety and visibility.
Although there are users who claim that level 4 and level 5 updates disrupt their systems when it comes to stability, there are plenty of users who select level 4 and level 5 for updating and not having any problems with their system after updating.

Until I encountered this problem I universally updated using sudo apt update && sudo apt full-upgrade in the terminal and ignored the update manager. For the sake of productivity, I'll let the update manager do its job--while I enjoy installing & configuring I no longer have the spare time to do it frequently.

Edit--Does this mean that Maui 1 will not received kernel & xorg driver updates at all? Or only when they have been thoroughly tested?

[AJSlye]

Maui 1 is based on Neon which is based on Ubuntu 16.04 LTS.
The point is to have a stable LTS base with a rolling DE and Applications (AKA semi-rolling).
Since the base is an LTS I would assume the kernel and Xorg would be coming from the there as those are both core components.

[dbyentzen]

Maui 1 is based on Neon which is based on Ubuntu 16.04 LTS.
The point is to have a stable LTS base with a rolling DE and Applications (AKA semi-rolling).
Since the base is an LTS I would assume the kernel and Xorg would be coming from the there as those are both core components.

OK, thanks for your reply. The concept of a stable LTS base with a (semi)rolling DE/applications is highly appealing! I'll let the update manager perform its task; at this point I need stability and production but do enjoy the latest of KDE.

[jdevney]

Hi all,

I'm enjoying Maui, but almost had to wipe my installation like the OP.

The upgrade to 4.4.0-36-generic prevented my booting into my LUKS encrypted root partition. I just exited to the busybox ash shell.

Reverting to 4.4.0-34-generic resolved the problem.

Is anyone aware of issues with this kernel and encrypted filesystems?

Cheers, JD.

[dbyentzen]

Hi all,

I'm enjoying Maui, but almost had to wipe my installation like the OP.

The upgrade to 4.4.0-36-generic prevented my booting into my LUKS encrypted root partition. I just exited to the busybox ash shell.

Reverting to 4.4.0-34-generic resolved the problem.

Is anyone aware of issues with this kernel and encrypted filesystems?

Cheers, JD.

Hi JD, 
I encountered the same problem and after a lot of searching on Google and Ubuntu Forums I was not able to achieve a solution. I use full disk encryption(FDE) and never considered this as contributing to the problem. In the end, I did a fresh install and decided not to update/upgrade via terminal but only use the update manager(advice from Maui's dev team). I hope in the future this problem will be resolved.

Best,
David

[jdevney]

Hi all,

I'm enjoying Maui, but almost had to wipe my installation like the OP.

The upgrade to 4.4.0-36-generic prevented my booting into my LUKS encrypted root partition. I just exited to the busybox ash shell.

Reverting to 4.4.0-34-generic resolved the problem.

Is anyone aware of issues with this kernel and encrypted filesystems?

Cheers, JD.

Hi JD, 
I encountered the same problem and after a lot of searching on Google and Ubuntu Forums I was not able to achieve a solution. I use full disk encryption(FDE) and never considered this as contributing to the problem. In the end, I did a fresh install and decided not to update/upgrade via terminal but only use the update manager(advice from Maui's dev team). I hope in the future this problem will be resolved.

Best,
David

Thanks David,

I've done some digging and think I've found the problem: the initial ramdisk isn't compiled with all the required libraries for lvm & crypt.

Using this page: https://wiki.debian.org/InitramfsDebug it's possible to identify the libraries compiled into initramfs. I compared the two versions 0-34 & 0-36. Turns out that in Maui 4.4.0-36 it's missing some crucial ones relating to lvm & crypt. So basically it can't get past the ramdisk initialisation phase as the root filesystem can't be mounted from disk (I'm using lvm & encrypted partitions).

I was assuming that the kernel would be the same as that supplied by ubuntu 16.04 LTS. I guess the Maui build team compile their own kernel and enable/disable stuff as required.

I tried copying a new 4.4.0-36 initrd from kubuntu, but after booting with the kubuntu plymouth screen, this also dropped to the busybox shell - likely for different reasons though.

I've now reconfigured grub to boot from 4.4.0-34 so I'm all good again.

Cheers, JD.