I updated my Latitude 7306 to its latest BIOS version, and it stopped booting. I can put in my encryption password, which it accepts, and then after a while I get:
ERROR: device '/dev/mapper/luks-c5a6… ' not found.
mount: /new_root: no filesystem type specified.
ls /dev/mapper from the rescue menu gives only one result:
I booted from a USB stick, and can see my system files from there. I tried chrooting and rebuilding
grub.cfg and running
mkinitcpio but it didn’t work anything.
I checked and ‘encrypt’ is in HOOKS in
Does anyone know how to fix it?
It is an unlikely cause - because it did work before,
but check the order of the hooks, check that the ‘
encrypt’ hook in
/etc/mkinitcpio.conf comes after ‘
block’ and before ‘
fsck’ and ‘
You would need to open the encrypted container to do that.
How did you do that?
Using a live system, you’d still have to open/decrypt the encrypted container
to be able to mount and then access the filesystem wthin it
which is on /dev/mapper/some_name
The manjaro-chroot script can not handle this situation as far as I know.
I can’t check the veracity of this my statement right now - this is just how I remember it.
chroot "by hand’ is needed
mount the filesystem(s)
then the chroot procedure
after having had a look …
manjaro-chroot might be able to handle the situation, but not fully automatically as in the usually recommended:
Thanks for the help.
The hooks seem to be in the right order:
HOOKS="base udev autodetect modconf block keyboard keymap encrypt filesystems fsck"
What I did was:
Boot the a Manjaro KDE Minimal USB.
Click ‘root’ in Devices.
Right-click / Open terminal.
sudo arch-chroot .
sudo arch-chroot .
… and this last step then didn’t work, I’d guess?
Although it’s not letting me install
arch-install-scripts this time (perhaps
manjaro-chroot is sufficient?).
On the live system,
/dev/mapper/luks-c5a6... seems to be there, just not when booting.
It did work.
How do you know?
… because it doesn’t seem like it did …
of course it is - you opened it, you saw it …
I suppose maybe it didn’t work. It didn’t throw any major errors, though.
It should give you a distinct prompt
and you can verify by listing the files, moving around in directories, trying to open/edit /etc/default/grub for instance
looking into /home/your_username will show you your files …
but you are restricted to that terminal
the gui filemanager doesn’t help you there
Yes, it gives the prompt and I can do things there. That is where I ran
grub-mkconfig -o /boot/grub/grub.cfg and
… and the device name in /etc/default/grub
matches the name of the disk when you list it with
Maybe you just need to reconfigure some settings in your bios after you updated it …?
lsblk -f lists it as
`-luks-c5a6d8b4-7a04-4fa6-8d99-e1a6a1b24239 320.8G 26% /
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash cryptdevice=UUID=c5a6d8b4-7a04-4fa6-8d99-e1a6a1b24239:luks-c5a6d8b4-7a04-4fa6-8d99-e1a6a1b24239 root=/dev/mapper/luks-c5a6d8b4-7a04-4fa6-8d99-e1a6a1b24239 udev.log_priority=3"
so I think they match (
luks- is missing from some of the ones in
/etc/default/grub but I assume that doesn’t matter).
I will have a look in the BIOS and see if there is anything that looks like it might work.
It seems to be working now. I first thought it was a BIOS option, but I changed it back to check and it still works. I tried rebuilding Grub and initramfs again to check if there were errors, and did it slightly differently the second time, so maybe that was it? I’m not sure.
Thank you very much indeed for all your help, anyway!
now I’m curious
although it never should have stopped working anyway
… one of those things that usually remain a mystery
I think the only two differences were:
manjaro-chroot instead of
mkinitcpio -P instead of
mkinitcpio -p linux515
Perhaps just doing it twice helped, like
pdflatex, although I doubt it!