I have a Notebook with an older installation of Fedora (Fedora 35). It’s installed on an internal m.2 nvme SSD.
Now I have removed that internal SSD and pur it into an external USB C enclosure. The laptop is still able to boot from it, but it goes into emergency mode complaining about LUKS having trouble finding the UUIDs.
How do I configure that Fedora installation so that I can boot it from both the internal m.2 slot and the USB-C port?
Thank you very much in advance. : )
This may be an issue with the initramfs image. Relocating the device from the internal M.2 slot to an external USB device means that now a usb driver must be part of the initramfs image so what is loaded into memory in the early stages of the boot matches what is on the device (including drivers to reach it). Luks is very specific in that it expects no changes for security reasons.
If you are able to boot and actually reach the os on the device when it is usb connected then one may fix that relatively simply with chroot and dracut. I cannot provide details however. I would suggest this may be solved by doing a live image boot then the chroot method.
Thank you, I have an Ubuntu 22 live USB stick and looking at lsblk, I can see the SSD has 4 partitions.
sdb 8:16 0 476.9G 0 disk
├─sdb1 8:17 0 600M 0 part
├─sdb2 8:18 0 1G 0 part
├─sdb3 8:19 0 32G 0 part
└─sdb4 8:20 0 443.4G 0 part
Not sure what sdb1 and sdb2 are. But I’d think sdb3 is my swap partition and sdb4 my home partition maybe? (Not sure if I even have a dedicated home partition.)
I guess only sdb3 and sdb4 are encrypted?
ubuntu@ubuntu:~$ sudo cryptsetup luksUUID /dev/sdb1
ubuntu@ubuntu:~$ sudo cryptsetup luksUUID /dev/sdb2
ubuntu@ubuntu:~$ sudo cryptsetup luksUUID /dev/sdb3
bf2fb83c-dd05-4847-bb12-05490c07348f
ubuntu@ubuntu:~$ sudo cryptsetup luksUUID /dev/sdb4
0edd6643-6088-4a73-b75b-7b35add41591
ubuntu@ubuntu:~$
You mentioned chroot and dracut. If I go that route, could you also please give me instructions on how to change it back in case it doesn’t work or I need to boot it from the internal slot again? : )
The messgae I got while booting was this btw:
Warning: /dev/disk/by-uuid/xxxxxxx does not exist
Warning: crypto LUKS UUID yyyyyyyyy not found
Warning: crypto LUKS UUID zzzzzzzzz not found
Generating "/run/initramfs/rdsosreport.txt"
Entering energency mode....
One would need to verify file system type with lsblk -f which gives a bit of information including UUIDs and file system type for each partition. If you have sdb3 as swap then I would venture that sdb1 is /boot/efi, sdb2 is /boot, sdb3 is swap, and sdb4 is btrfs with both / and /home.
With lsblk -f I get
sdb
├─sdb1
│ vfat FAT32 CA04-1C1C
├─sdb2
│ ext4 1.0 fc8a3952-bfec-45c0-99fd-47582a6bb79a
├─sdb3
│ crypto 2 bf2fb83c-dd05-4847-bb12-05490c07348f
└─sdb4
crypto 2 0edd6643-6088-4a73-b75b-7b35add41591
Would this be the way to do it?
sudo mkdir /mnt/ssd
sudo mount /dev/sdb4 /mnt/ssd/
sudo mount /dev/sdb2 /mnt/ssd/boot
sudo mount /dev/sdb1 /mnt/ssd/boot/efi
#sudo mount /dev/sdb3 ?
sudo mount --bind /dev /mnt/ssd/dev
sudo mount --bind /proc /mnt/ssd/proc
sudo mount --bind /sys /mnt/ssd/sys
sudo chroot /mnt/ssd
update-initramfs -u
update-grub
Not quite. One needs to have the network configured before continuing since things may need downloaded when going forward.
first one would need to unlock sdb4. I do not use luks but I beleve the cryptsetup command would achieve that.
Then since there are two subvolumes root and home one would need to then mount each subvolume similarly to how it is done in /etc/fstab
One needs root permissions for everything else so one may use su to gain that, followed by
mount -t btrfs -o subvol=root,compress=zstd:1 UUID=0edd6643-6088-4a73-b75b-7b35add41591 /mnt/ssd
mount -t btrfs -o subvol=home,compress=zstd:1 UUID=0edd6643-6088-4a73-b75b-7b35add41591 /mnt/ssd/home
mount /dev/sdb2 /mnt/ssd/boot
mount /dev/sdb1 /mnt/ssd/boot/efi
Then one can mount all the needed pieces with
for dir in proc run dev sys ; do mount -o bind /$dir /mnt/ssd/$dir ; done
At this point one could use chroot /mnt/ssd to enter the chroot environment.
Note though that if using the live usb to do this one would probably be booted with the 5.2.9 kernel which likely would not exist on the installed system at this time so it would need to be installed before attempting to use dracut and creating the initramfs image. dnf install kernel-5.2.9 should install the needed pieces and at the same time create an initramfs for that kernel as it is installed.
Now one should be able to boot the system to the newly installed kernel properly, though it is likely another step would be required to boot to a later kernel.
The Ubuntu version appears to 22.04.3 LTS with kernel 6.2.0:
uname -a
Linux ubuntu 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 13 16:27:29 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
The boot partition contains the following files:
config-5.19.16-100.fc35.x86_64
config-6.0.11-100.fc35.x86_64
config-6.0.12-100.fc35.x86_64
efi
elf-memtest86+-5.31
extlinux
grub2
initramfs-0-rescue-23fe5e6240d648149a42f88161d50ad4.img
initramfs-5.19.16-100.fc35.x86_64.img
initramfs-6.0.11-100.fc35.x86_64.img
initramfs-6.0.12-100.fc35.x86_64.img
loader
lost+found
memtest86+-5.31
symvers-5.19.16-100.fc35.x86_64.gz
symvers-6.0.11-100.fc35.x86_64.gz
symvers-6.0.12-100.fc35.x86_64.gz
System.map-5.19.16-100.fc35.x86_64
System.map-6.0.11-100.fc35.x86_64
System.map-6.0.12-100.fc35.x86_64
vmlinuz-0-rescue-23fe5e6240d648149a42f88161d50ad4
vmlinuz-5.19.16-100.fc35.x86_64
.vmlinuz-5.19.16-100.fc35.x86_64.hmac
vmlinuz-6.0.11-100.fc35.x86_64
.vmlinuz-6.0.11-100.fc35.x86_64.hmac
vmlinuz-6.0.12-100.fc35.x86_64
.vmlinuz-6.0.12-100.fc35.x86_64.hmac
So I’d assume that version of Fedora has kernel 6.0.12, 6.0.11 and 5.19.16.
I’ll put the SSD back into the internal m.2 slot and boot it, and then try to update to that kernel version.
Actually, since you have F35 installed you will not be able to install the noted kernel. That kernel was the release version when F38 was released. F35 has been EOL for almost a full year
Unfortunately, since you are using a version of fedora that is way past EOL recovery is not as easy as it would be were you using a current fedora release.
I would now, since I see you are actually on F35 and that the tag above is not an error, suggest that you put the device back into the proper location. Then upgrade fedora to a currently supported version before you once again try to move it out to a usb device.
It may actually be easier to simply put the device in the usb adapter as it is then do a new clean install on that device instead of trying to work around in the way I already described.
I upgraded that SSD to Fedora 36, then 37 and finally 38 now, but I was struggling to install kernel 6.2.0. That version does not appear to be in the repositories.
The closest thing I could find was this: kernel-6.2.0-63.fc38 | Build Info | koji
So I downloaded and installed:
I’m now back to the SSD in the external USB adapter and booted into Ubuntu again.
I found that I just had to click sdb4 in the UI, then it asked for the password and dcrypted+mounted the subvolumes at
/media/ubuntu/master-volume/root
and
/media/ubuntu/master-volume/home
So I tried to symlink it:
root@ubuntu:/mnt# ln -s /media/ubuntu/master-volume/root ssd
root@ubuntu:/mnt# ln -s /media/ubuntu/master-volume/home ssd/home
Which was probably a dumb idea because I don’t know what “home” was on the root partition before I turned it into a symlink…
Then I just used mount --bind:
root@ubuntu:/mnt# mount --bind /media/ubuntu/master-volume/root /mnt/ssd
root@ubuntu:/mnt# mount --bind /media/ubuntu/master-volume/home /mnt/ssd/home
root@ubuntu:/mnt# mount /dev/sdb2 /mnt/ssd/boot
root@ubuntu:/mnt# mount /dev/sdb1 /mnt/ssd/boot/efi
root@ubuntu:/mnt# for dir in proc run dev sys ; do mount -o bind /$dir /mnt/ssd/$dir ; done
Then I chrooted into the directory and checked fstab:
root@ubuntu:/mnt# chroot /mnt/ssd
[root@ubuntu /]# cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Wed May 5 18:33:08 2021
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=a982c387-371f-4d9b-b7fa-ce20011e192f / btrfs subvol=root,compress=zstd:1,x-systemd.device-timeout=0 0 0
UUID=fc8a3952-bfec-45c0-99fd-47582a6bb79a /boot ext4 defaults 1 2
UUID=CA04-1C1C /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=a982c387-371f-4d9b-b7fa-ce20011e192f /home btrfs subvol=home,compress=zstd:1,x-systemd.device-timeout=0 0 0
/dev/mapper/luks-bf2fb83c-dd05-4847-bb12-05490c07348f none swap defaults,x-systemd.device-timeout=0 0 0
I also found crypttab. Not sure it this is relevant as well:
[root@ubuntu /]# cat /etc/crypttab
luks-0edd6643-6088-4a73-b75b-7b35add41591 UUID=0edd6643-6088-4a73-b75b-7b35add41591 none discard
luks-bf2fb83c-dd05-4847-bb12-05490c07348f UUID=bf2fb83c-dd05-4847-bb12-05490c07348f none discard
Now I’m thinking about replacing the UUIDs in those files with the correct ones and then maybe running dracut --regenerate-all? What about the kernel parameters btw? The UUIDs are in there as well:
rd.driver.pre=vfio-pci kvm.ignore_msrs=1 i915.enable_gvt=1 intel_iommu=on amd_iommu=on iommu=1 preempt=full resume=/dev/mapper/luks-bf2fb83c-dd05-4847-bb12-05490c07348f rd.luks.uuid=luks-0edd6643-6088-4a73-b75b-7b35add41591 rd.luks.uuid=luks-bf2fb83c-dd05-4847-bb12-05490c07348f rhgb quiet
Can I just edit /etc/default/grub and then run sudo grub2-mkconfig -o $(readlink -f /etc/grub2-efi.cfg)?
But especially regarding the dracut command I’m a bit worried about not being able to revert to the old state where it can boot from the internal m.2 slot.
sudo grub2-mkconfig -o /etc/grub2-efi.cfg works as does using the file name /etc/grub2-efi.cfg points to: sudo grub2-mkconfig -o /boot/grub2/grub.cfg
One does not need the extra steps of using readlink for that.
What makes you believe the entry in /etc/fstab is in error? Did this not already boot normally before you relocated the drive to the usb? If it did then the uuid should not have changed at all. What you see in /etc/crypttab reveals both the bare UUID and the luks version of that uuid, which also is mapped to the equivalent device shown in /dev/mapper and the UUID used in /etc/fstab.
Well, when I try to boot from that SSD, I still get those warnings
Warning: /dev/disk/by-uuid/a982c387-371f-4d9b-b7fa-ce20011e192f does not exist
Warning: crypto LUKS UUID 0edd6643-6088-4a73-b75b-7b35add41591 not found
Warning: crypto LUKS UUID bf2fb83c-dd05-4847-bb12-05490c07348f not found
Generating "/run/initramfs/rdsosreport.txt"
Entering energency mode....
That’s why I was thinking that I might have to manually update them in fstab and crypttab as well as in the kernel parameters.
But I guess I misunderstood those warnings and the UUIDs didn’t change at all?
Do you think I just need to run dracut --regenerate-all or something else?
Edit:
I now created backups of sdb1 and sdb2. So hopefully I will be able to restore the old configuration, in case things go wrong:
sudo dd if=/dev/sdb1 of=./sdb1.img
sudo dd if=/dev/sdb2 of=./sdb2.img
It worked! Thank you so much! : )
I just ran dracut --regenerate-all --force as well as grub2-mkconfig -o $(readlink -f /etc/grub2-efi.cfg) in the in the chroot and now I can boot it without any problems from the external USB C adapter. : )
[root@ubuntu /]# dracut --regenerate-all --force
[root@ubuntu /]# grub2-mkconfig -o $(readlink -f /etc/grub2-efi.cfg)
Generating grub configuration file ...
Found Alpine Linux v3.14 on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Debian GNU/Linux 10 (buster) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Debian GNU/Linux 10 (buster) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Ubuntu 20.04.3 LTS on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Debian GNU/Linux 10 (buster) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Ubuntu 18.04.6 LTS on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Alpine Linux v3.13 on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Alpine Linux v3.10 on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Debian GNU/Linux 10 (buster) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Red Hat Enterprise Linux 8.1 (Ootpa) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Ubuntu 18.04.4 LTS on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Debian GNU/Linux 10 (buster) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Red Hat Enterprise Linux 8.6 (Ootpa) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Ubuntu 20.04.3 LTS on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found CentOS Linux 8 on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Ubuntu 22.04.1 LTS on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Debian GNU/Linux 9 (stretch) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Ubuntu 20.04.4 LTS on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Debian GNU/Linux 9 (stretch) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Debian GNU/Linux 11 (bullseye) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Alpine Linux v3.17 on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Debian GNU/Linux 10 (buster) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Found Debian GNU/Linux 12 (bookworm) on /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591
Adding boot menu entry for UEFI Firmware Settings ...
done
I checked dmesg for any errors after booting and I noticed this line:
[ 15.250541] BTRFS info (device dm-0): bdev /dev/mapper/luks-0edd6643-6088-4a73-b75b-7b35add41591 errs: wr 0, rd 0, flush 0, corrupt 16194, gen 0
Is that anything I need to worry about?
Does it boot now?
Yes, any file system errors should probably be fixed since it potentially could lead to more serious errors. With btrfs the errors are not the same as bad blocks. It is a file system error and not hardware error that the system automatically manages.
Yes, it boots now and after successfully booting, I ran dmesg to make sure everything works as expected. That’s when I noticed this btrfs message.