Changed the external SSD to internal and viz versa.
While I can boot with the external now build internal F38, the booting from the internal where is now external not works.
I get OK on
Reached target basic.target - Basic system.
Then it waits a moment an i get a lot of errors.
My guess is that i do have a problem with /etc/fstab:
#
# /etc/fstab
# Created by anaconda on Thu Mar 31 13:10:33 2022
#
# 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=fb7xxxxx-xxxx-xxxx-xxxx-abcdefghijk4 / btrfs subvol=root00,compress=zstd:1 0 0
UUID=69xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /boot ext4 defaults 1 2
UUID=AAAA-DDDD /boot/efi vfat umask=0077,shortname=winnt 0 2
UUID=fb7xxxxx-xxxx-xxxx-xxxx-abcdefghijk4 /home btrfs subvol=home00,compress=zstd:1 0 0
It is a F37 while I get this errors for all 3 boot options 6.2 + 6.3 kernels
While with the rescue entry of F36 I can boot and I do see the mounted folders.
Yes. It will try to update whatever initramfs is currently booted. It probably cannot update the rescue initramfs (and you wouldn’t want to). You would either need to do it while the drive is running from the external connection (and booted from the normal kernel) or you could provide two additional parameters to indicate which initramfs to update.
So if you don’t want to move your drive back to the external connection temporarily to make the change, you could run something like sudo dracut --force --no-hostonly /boot/initramfs-1.2.3-000.fc38.x86_64.img 1.2.3-000.fc38.x86_64 while booted from the rescue kernel that currently works with the internal connection.
That will only affect future kernel installs. So another way you could fix it would be to update your kernel while that configuration file is in place. Then when you boot with the new kernel, it should work.
As far as I know, the initramfs is generated for the specific hardware you have. Since you moved the SSD from the outside to the inside, the hardware changed from USB to NVMe, and the specific initramfs no longer worked.
According to the man page of dracut
-H, --hostonly
Host-only mode: Install only what is needed for booting the local host instead of a generic host and generate host-specific configuration.
Warning
If chrooted to another root other than the real root device, use "--fstab" and provide a valid /etc/fstab.
-N, --no-hostonly
Disable host-only mode.
So the fix basically is that you generated a general purpose initramfs that works with all configurations.
Yeah, it’s not new. The hostonly optimization has been part of Dracut for a very long time. Sometimes you can get away without disabling hostonly if your hardware happens to be using very generic drivers that are included in the kernel by default. I think people might be hitting this problem more because there are getting to be more different kinds of hardware that require specialized drivers (e.g. nvme wasn’t all that common in recent history).
Be aware that disabling hostonly permanently (by adding that config file under /etc/dracut.conf.d) causes your initramfs to be larger which slows down your system boot time and maybe adds a little extra wear to your SSD. It shouldn’t be required to disable hostonly permanently if you are only moving your hard drive one time. Just do it for the kernel that you are using at the time of the move. Future kernels will include whatever drivers are currently being used when they are installed.
I normally not use that the kernel modules automatically get created. But I was playing around with Virtualbox and I guess this caused the more specific kernel.
But now I know on what I have to watch next thime.