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