Hi all,

After the recent Plasma 5.6.5 update, my system no longer boots up properly.

It reaches the graphical screen where it usually asks for the password to decrypt the hard-drive, and goes to a black screen with white text which says :

Code: Select all

[ 1.154526] nouveau 0000:01:00.0: gr: failed to load fecs_inst

BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) _


Any ideas,

Thanks

Hi,

to get more information about the problem, please try to start using the recovery option.

* Power on the machine
* Hold "shift" key pressed, grub will show up
* Select advanced options for Ubuntu, from there start Ubuntu in recovery mode

This way the kernel will start with verbose messages. Please take a note of all "unusual" messages (errors, warnings and messages relaiting rootfs, dm-crypt or volume manager).

In case recovery shows up, try running grub recovery.

A wild guess about the origin of the issue: Last time I ran dist-upgrade, grub-theme-breeze didn't install properly; I removed it using dpkg and re-installed it. Maybe the installation of this package failed for you as well and left you with an inconsistent bootloader. In that case, booting to a recovery shell, for example using the installation cd, and manually removing and reinstalling this package in your system might do the trick. But as I said: Just a guess.

Best regards,
Martin

Hi Martin - thank-you for your reply.

Interestingly since the 5.6.5 update, the grub menu now appears automatically on boot-up (w/o pressing shift) - which it was not doing prior.

On booting in recovery mode, the last bunch of messages are :

Code: Select all

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.

Begin: Running /scripts/local-block ... done. <<< this line repeats about 15 times in a row

done.
Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
  - Check rootdelay= (did the system wait long enough?)
  - Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mapper/neon--vg-root does not exist. Dropping to a shell!

BusyBox v1.22.1 (Ubuntu 1:1.22.0-15ubuntu1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) _


Hopefully no typos in the above.

I won't get a chance to look into this further until the weekend, but will report back.

Thanks again.

Ah, those details confirm my suspicion.

ALERT! /dev/mapper/neon--vg-root does not exist. Dropping to a shell!

That indicates incomplete and/or broken grub configuration.

Depending how good you are using the shell I recommend using some installation media (Kubuntu, Ubuntu or Neon installation cd or usb pendrive) to fix it.

You can also google "ubuntu fix grub live cd" or something, there are a couple of howtos and even live cds for fixing grub.

Something like this should help you (warning: a lot of shell hands on and no warranty):

• Boot the live desktop
• Open a shell. Run "sudo su" to become root.
• Run "blkid". It will scan your disks and tell you about their meaning. There should be at least one like with TYPE="crypto_LUKS".
• If there is only one TYPE="crypto_LUKS" line: the path at the beginning of the line is the device name, for example /dev/sda5
• If there is more than one (unusual for default installations) you need to identify the main one, you can try the following lines for each of the devices.
• Now you have to open the crypted device (example): cryptsetup open /dev/sda5 sda5_crypt
• Hint: The third argument (sda5_crypt) in my example is a label for the device you can chose freely. I recommend that you label it the same way I did in the example since that's the way it's usually labeled by default.
• You should be asked your decryption passphrase. Enter it. Afterwards you can access the partitions.
• Run "lvs" to list all available logical volumes.
• If none are listed and you have multiple encrypted disks, try also opening another one of them.
• Otherweise, if none are listed, maybe you need to manually activate the lvm volume group. run: "vgchange -a y neon-vg" and look again at the output of "lvs"
• Now you should be able to mount your root volume: mount /dev/mapper/neon--vg-root /mnt
• Find out your boot partition, if needed (for example by using "cfdisk /dev/sda"). Let's assume its /dev/sda1. Mount your boot partition (example): "mount /dev/sda1 /mnt/boot"
• Now you need to mount some paths from the live system to be able to work within your normal system:
• mount --bind /dev /mnt/dev
• mount --bind /dev/pts /mnt/dev/pts
• mount /sys -t sysfs /mnt/sys
• mount /proc -t proc /mnt/proc
• If everything worked well, you can now open your installed system and fix the grub bootloader:
• chroot /mnt
• You operate now within your installed system. Do the following:
• update-grub
• update-initramfs -u
• grub-install /dev/sda
• If you are done fixing grub (with whatever commands you desire), type exit to leave chroot and unmount /mnt/dev/pts, /mnt/dev, /mnt/proc, /mnt/sys, /mnt/boot and /mnt. If it doesn't work, don't bother, shouldn't be a problem.
• Try rebooting and see if booting works again.
• If not, repeat the steps until "chroot /mnt" and try the following:
• apt -f install
• (to look if there is unfinished installation or configuration. If there is not, the call should exit without doing anything.)
• apt purge grub-theme-breeze
• apt install grub-theme-breeze
• (in case that's the problem)
• If that still doesn't work (reboot), you can also try to entirely re-install the bootloader:
• apt purge grub*
• apt install grub-pc

As I said, no warrenties, just hope that helps you out since those steps help me out frequently. Best do a google research as mentioned before as well, there are a number of tutorials on fixing this kind of issue.

Best regards,
Martin

Many thanks for your reply Martin.

Unfortunately working through your suggestions I get a number of errors.

For example :

Code: Select all

update-grub
/usr/sbin/grub-mkconfig: 250: /usr/sbin/grub-mkconfig: cannot create /boot/grub/grub.cfg.new: Directory nonexistent

grub-install /dev/sda
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.


I'm working through these, but have been unsuccessful so far.
I also get unusual errors during the process - for example losing ethernet connection.
I looked at other sources as you suggested, also unsuccessfully.

I'll keep trying for a bit longer, but may resort to a reinstall to see if the problem recurs.

Thanks again for your time & advice.

Ah, I assumed you have a classic MBR/BIOS based installation, but oviously you are using UEFI based bootloading.

Code: Select all

update-grub
/usr/sbin/grub-mkconfig: 250: /usr/sbin/grub-mkconfig: cannot create /boot/grub/grub.cfg.new: Directory nonexistent

That means, that parts of your system are not mounted properly (or that grub is **** up pretty bad). After mounting your root filesystem in the way described before in the live system, have a look at

/mnt/etc/fstab

this file usually lists all the filesystems that are mounted by default on your system and where they are supposed to be mounted. Probably your boot (and EFI system) filesystem hasn't been mounted successfully.

For the format of fstab see this manpage. The first column lists the device, the second one where it is supposed to be mounted (don't forget to prepend /mnt when mounting it in the livesystem before running chroot /mnt).

If the file lists UUID="" or LABEL="" entries instead of filesystem paths, you can find out the devices name using "blkid".

Code: Select all

grub-install /dev/sda
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.

This means, that you have to mount the EFI directory as well. You can find out the device name for your efi directory using the method described before (blkid / cfdisk), look out for the partition EFI System (filesystem vfat) and mount it to /mnt/boot/EFI.

I'll keep trying for a bit longer, but may resort to a reinstall to see if the problem recurs.

Sounds reasonable. As I've read here before, the installation system of Neon is not yet fully finished, especially when dealing with EFI and EFI Secure Boot installation. I'm pretty sure that will be fixed soon and is just a temporary issue, after all this fork is pretty young.

I for my part upgraded my existing Kubuntu 16.04 installation to Neon (user edition) by adding it's repository, so I wasn't affected by these issues.

Thanks again for your time & advice.

Sorry I couln't help you to resolve your issues. I hope you at least got some interesting insight into the systems by trying to fix this problem.

Best regards,
Martin

Hi Cymaphore,

I followed your explanation carefully. I have the exact same problem with my kde neon user edition. I have a classic MBR/BIOS based installation with full disk encryption.
But when I reboot, the problem is still the same. I'd like to entirely re-install the bootloader but when I do

Code: Select all

apt install ...

My chroot does not have internet access whereas my laptop is connected and I can browse the web.
What command should I run to enable internet in chroot?

Many thanks for all your great explanation.
Best

Hi,

jinformatique wrote:My chroot does not have internet access whereas my laptop is connected and I can browse the web.
What command should I run to enable internet in chroot?

That's most likely because the system in chroot doesn't know about the nameservers. These are configured in the file /etc/resolv.conf ... If you compare it to /mnt/etc/resolv.conf you should see the difference.

This should do the trick:

Code: Select all

sudo cp /etc/resolv.conf /mnt/etc/

If not, you can also manually place your local dns server (usually the IP of your router, something like 192.168.1.1 or so) in /mnt/etc/resolv.conf

Code: Select all

nameserver 192.168.1.1
# (or whatever)

Then chroot should be able to normally access the internet.

Best regards,
Martin

Hi,

The steps given in this topic did not help me out. I'm writing here to share my recent experience as a user with KDE neon and tell you how much I'm currently sad and disappointed

Remember full disk encryption is something I can not live without and i'm not willing to sacrifice for my laptop use.
So since June I started using live iso to install KDE neon with full disk encryption. I made the upgrade to Plasma 5.7. When booting up it did not display the input field to unlock the hard drive. So I went here to try to follow the steps to recover it but it did not work. I made a backup up of all my data and did a full reinstallation of KDE Neon iso file with plasma 5.7 (in July). Then I waited a bit an made the upgrade to plasma 5.7.2 with apt-get upgrade or apt-get dist-upgrade. Again same thing happened with the boot up, it was broken.

So I'd like to challenge all the KDE developer to use full disk encryption on their desktop or laptop and tell me how many hours did they loose because of this bug!

Many thanks, KDE is awesome!

Hi,

Same bug again and again, after having it with 5.7.2, then 5.7.3, then 5.7.4, now with 5.7.5.

Hi jinformatiquek,

I recently had a similar problem, the discussion about that is at viewtopic.php?f=309&t=136107. As mentioned in the thread, I was able to save my installation by restoring lvm2 that apt autoremove had erroneously removed, perhaps your issue could be the same?

It seems lvm2 is missing in the upgrade. Doing "apt install lvm2" worked for me.

I got help from here:
viewtopic.php?f=309&t=136107&p=364501#p364501

Happy it helped And lots of thanks to Cymaphore for step by step directions on how to mount an encrypted partition with a live USB stick!

Unfortunately I've had the same bug reappear with the latest update.

Running KDE Neon 5.8.1.

For what it's worth, I am certain that I didn't do any autoremove commands with this install.
I only updated via Discover.

I thought a came across a registered KDE bug related to this yesterday, but can't seem to find it now.