update-grub error {cannot find device for /} is /dev mounted ?

Xen list at xenhideout.nl
Tue Aug 15 07:46:16 UTC 2017


Sreyan Chakravarty schreef op 14-08-2017 19:45:

> I have followed the instructions from this video-:
> 
> https://www.youtube.com/watch?v=F0b4I89LY5E

I am definitely not going to watch an 18 minute video to find out what 
you've done or didn't do ;-).

Your /boot is on a separate disk, I assume your boot is not encrypted 
and that Grub is going to read your boot files just fine without an 
additional setup like the mail I had written you.

I mean a separate partition.

I mean why don't you just mention what you've done? You really think 
everyone who wants to answer is going to spend 18 minutes watching that 
video?

The encrypted setup you seem to have seems to be completely standard.

The cryptswap thing you say you have might be bugged though.

That is to say that a "cryptswap" is meant to be encrypted _by itself_ 
using its own /etc/crypttab line and _re-encrypted_ every time your 
system boots, that means new keys are being generated just for that 
session. When you have your swap inside the encrypted LVM _THIS IS 
UNNECESSARY_ ;-) but yeah the installer botches that up I guess.

Sorry.

You can completely remove the cryptswap line from your /etc/crypttab, 
and you can make sure to create a swap partition on your 
/dev/ubuntu/swap using mkswap /dev/ubuntu/swap.

Then make sure that your /etc/fstab reflects this. You have no need for 
an encrypted swap (it is already encrypted).

But since the system does not boot, you are not even there yet.

Do it anyway: remove cryptswap from /etc/crypttab and change fstab to 
reflect your /dev/ubuntu/swap partition (LVM volume) after creating a 
swap filesystem on it using mkswap /dev/ubuntu/swap.

But this @ issue you have is probably the only problem for 
grub-mkconfig.

Grub-mkconfig is going to look probably simply for the presence of Linux 
systems on available devices; therefore it is not going to care whether 
you are doing so on LVM after it has been opened.

You didn't mention this but I assume you have unlocked manually now (if 
you need to go back) your LUKS using:

cryptsetup open /dev/sda6 sda6_crypt

or similar.

*I DO NOT KNOW* why the @ comes and I have NEVER used UEFI so I cannot 
help you.

I have had many different kinds of encrypted systems and botched up a 
lot. I have had two systems with a *completely* encrypted /boot and also 
systems with an open /boot.

Grub-mkconfig has never had any problem with anything. If you go back to 
your system after booting the live environment, you will have to:

- unlock LUKS
- mount your /dev/ubuntu/root again

But there really shouldn't be an @ directory as far as I am concerned 
unless you are using BTRFS or something and it is doing something 
strange?

I am not interested in such complications.

Ask the video creator for help, you know ;-).

Regards.

ps. yes I am interested in helping you but with experience until 16.04 
and also Debian 8 I have not run into such issues. Regards.




More information about the ubuntu-users mailing list