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:
# 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.
I do need some input to proceed.
It sounds a lot like “I have fedora installed on an External SSD, boots externally but not when placed internally”. Did you try running
sudo dracut --force --no-hostonly while the system was working on the external connection?
The external ssd is now internal and it works. I have the problem with the one I had internally and is now connected over usb3 external.
I was reading your answer there and I did the
hostonly.conf in the
No success so far. The recovery image is F36 and this works it has the
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-0-rescue-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxyy root=UUID=fbxxxxxx-zzzz-yyyy-aaaa-ddddddddddd ro rootflags=subvol=root00 rhgb quiet
I booted with the rescue image F36 and gave an error when I was running the command.
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.
Changing back the HD into the computer and execute
sudo dracut --force --no-hostonly
Solved the boot problem.
Is this a security feature? Is this new?
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
Host-only mode: Install only what is needed for booting the local host instead of a generic host and generate host-specific configuration.
If chrooted to another root other than the real root device, use "--fstab" and provide a valid /etc/fstab.
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.
Thanks @glb for your fast help.
Oposite, I had this F37 inside of the computer and now it works over usb on a sata dock.
Thanks also for the clarifications.