"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.
(1st September 2016, 18:31)Pliny.D.Elder Wrote: [ -> ]"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!
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.
Quote: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.
(2nd September 2016, 7:26)AJSlye Wrote: [ -> ]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.
Quote: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?
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.
(2nd September 2016, 16:22)AJSlye Wrote: [ -> ]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.
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.
(15th September 2016, 22:51)jdevney Wrote: [ -> ]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
(18th September 2016, 3:41)dbyentzen Wrote: [ -> ] (15th September 2016, 22:51)jdevney Wrote: [ -> ]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.