Migrate root filesystem to new drive / partition

Hello All,

I need a quick bit of help. I’ve migrated my /root and /home directory off a BTRFS partition to and EXT4 partition, because, for some strange reason … BTRFS always fail! … However, now that the EXT4 has the /home and /root directory, it won’t boot.

I have updated grub2.conf and fstab to use the new drive UUID, but I can’t figure out how to update the initramfs, since …

the OS in the /root directory is 6.8.4-100.fc38.x86_64 and

the LiveCD I have is using 6.2.9-300.fc38.x86_64.


I don’t understand the directions as listed in this document


FStab is pretty generic

UUID=[ ### ] / ext4 defaults 01

UUID=[ ### ] /home ext4 defaults 01


The old FStab had

UUID=[ ### ] / btrfs subvol=root,compress=zstd:1 0 0

UUID=[ ### ] /home btrfs subvol=home,compress=zstd:1 0 0


set kernelopts="root=UUID=[ ### ] ro


modprobe.blacklist=nouveau nvidia-drm.modeset=1

video=HDMI-0:D video=VGA-1-1:d "


Have I missed something?

Do I need to run dracut --kver 6.8.4-100.fc38.x86_64

Do I need to issue a chroot command? And, if so where in the directory tree?

Should I give up the ghost and just start over? Much time will be lost in reconfiguring the OS.

Thoughts and prayers

Boot a Fedora live session and set up a chroot as explained here:
The GRUB2 Bootloader – Installation and Configuration :: Fedora Docs

Then you can regenerate all initramfs inside the chroot:

sudo dracut -f --regenerate-all

In attempting to follow the directions provided above, I found that …

sda1 … contains grub

sda2 … contains home and root

So, I’m not sure how to adjust the mount commands to connect to root, plus the liveuser is not found in /dev/mapper

[root@localhost-live /]# ls /dev/mapper
control live-base live-rw
[root@localhost-live /]# ls /dev/mapper/live-base
[root@localhost-live /]# ls /dev/mapper/live-rw

mount /dev/sda2/root /mnt

mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
mount -o bind /dev /mnt/dev
mount --bind /run /mnt/run

Or should I issue

mount /dev/sda2 /mnt
mount -t root root /mnt/root

mount -t proc proc /mnt/root/proc
mount -t sysfs sys /mnt/root/sys
mount -o bind /dev /mnt/root/dev
mount --bind /run /mnt/root/run

That looks wrong, check the output:

sudo umount /mnt; sudo mount /dev/sda2 /mnt; ls -a -l /mnt

[root@localhost-live /]# mount /dev/sda2 /mnt

[root@localhost-live /]# ls -al /mnt
total 32
drwxr-xr-x. 5 root root 4096 May 3 19:06 .
dr-xr-xr-x. 19 root root 4096 May 3 02:15 …
drwxr-xr-x. 3 root root 4096 Jan 18 2023 home
drwx------. 2 root root 16384 May 2 12:49 lost+found
dr-xr-xr-x. 21 root root 4096 Apr 9 12:36 root

[root@localhost-live /]#

You need to rearrange and merge the contents under the top level since Ext4 doesn’t support subvolumes.

or, just thinking out loud here, another option would be to create 2 partitions for root and home, to seperate them.

But I understand your point. They either need to be in seperate partitions or merged.

I guess merging them would be easier, at this point.

1 Like

Ok, I decided to create 2 new partitions, one for root and one for home.

I was able to issue the mount command(s) successfully and chroot properly

I issued … dracut -f --regenerate-all … and then exited chroot, and dismounted all the mounts, even made sure they were all dismounted by issuing … mount and lsblk -l … commands.

When I rebooted, the system still failed to boot. While taking a picture of the issue, I apparently timed out grub, and it told me it’s looking for the old UUID for the BTRfs partition. =(

I restarted wtih liveCD and when back through all the commands again. Even making sure that grub.cfg and fstab were correct. I listed out the dates and times of the images on the grub partition (sda1) and they still point to dates in the past.

When I issues … dracut … without the force parameter, it definitely complained that it would not replace the 3 initramfs that I had.

I used lsinitrd /boot/initramfs-6.8.4-100.fc38.x86_64.img to interrogate the files in the file, which seem correct, but I don’t see an fstab, just an fstab.empty file with 0 bytes in it.

So, I’m at a loss where it’s getting the old UUID from.

I’m thinking that I need to issue dracut with different parameters?

#Since UUID’s changed, you will need to run grub2’s list and update commands
#make sure fstab lists the correct UUIDs
cat /etc/fstab

#Use Grub to list the boot environments in the system
grub2-editenv - list

if you are still in chroot this shoudl list something like …

grub2-editenv - list


otherwise it will list something like


Now issue the update command … 1 of the 2 will work.

grub2-mkconfig -o /boot/grub2/grub.cfg

#now confirm that the grub command actually updated the configuration file
cd /boot/loader/entries
ls -al

All entries should have today’s date

cat a6a84281584b4fb69829b970ecb6d26b-6.8.4-100.fc38.x86_64.conf

title Fedora Linux (6.8.4-100.fc38.x86_64) 38 (MATE-Compiz)
version 6.8.4-100.fc38.x86_64
linux /vmlinuz-6.8.4-100.fc38.x86_64
initrd /initramfs-6.8.4-100.fc38.x86_64.img
options root=UUID=6bec82ae-4d47-4704-adfa-fd51dab23cc8 ro video=HDMI-0:D video=VGA-1-1:d
grub_users $grub_users
grub_arg --unrestricted
grub_class fedora

I got the OS to boot from the partition, but alas, there are lots of errors. I tried capturing them with my phone, in video mode. I’ll have to review and post about what it’s capturing, if I can read it.

It appears that the JournlCtrl Service can’t start due to a machine-id mismatch between the etc and dbus directories …

/etc/machine-id … a6a84281584b4fb69829b970ecb6d26b

/var/lib/dbus/machine-id … 91624014fabd4490833c060fef83f27d

Supposedly the solution is to delete both files and let them be recreated at boot, or issue

systemd-firstboot --root=/mnt --setup-machine-id



though I don’t know if those commands can be issued in a chroot?

I saw that when I did an ls -al … the dbus is a symlink to the etc/machine-id.

So, it must be something else causing the Journal to fail?! =(

I checked the journal, wondering if it caught anything … insert laugh emoji here … the journal isn’t working, why would it capture anything =_)

Though, it does beg the question, is there a startup log somewhere I could look at?

I know windows used to have one, back in the day.

I tested different machine IDs in a VM and it boots, so your problem is somewhere else.
Try using permissive SELinux mode and perform a complete filesystem relabeling:

sudo touch /.autorelabel
sudo fixfiles -F onboot

Vlad, thanks for testing that.

I’m looking at capturing the boot messages up and until Journal starts. They scroll by too fast for my phone to capture.

It looks like these logs are in /var/log/dmesg and bootlogd

Thought, I’m not sure how to get this utility installed, if it’s not already there.

It looks like dmesg comes with liveCD F38, but when I checked /var/log … there are no logs past 2024-04-29, when the went down initially. =(

Incorrect SELinux labels is a plausible cause of this kind of issue.

1 Like

found the boot.log in var/log … I was expecting a log with a date stamp in the file name.

Found where the systemd-journald.service failed to start, and it tells me to run systemctl status systemd-journald.service for details.

There is no further information about why Journal is failing. Maybe in another log?

Ok, went back into chroot

SELinux status: disabled


cat /etc/selinux/config

 # This file controls the state of SELinux on the system.
 #    grubby --update-kernel ALL --args selinux=0

 # To revert back to SELinux enabled:
 #    grubby --update-kernel ALL --remove-args selinux


extraneous comments removed for brevity

fixfiles onboot
System will relabel on next boot

is the SELinux Config file where I change the status to permissive or through grubby? or both?

PS … noted that touch /.autorelabel and fixfiles the NOT the same?

If the system doesn’t recover after a fix files, I’ll try a autorelabel. Or, I may still issue it if I get the system up and running.

Great News … she finally booted into the User Desktop

Initially there were a lot of failures, and grub dropped into it’s console, and just as I was about to issue a journal -ax or -xb … I forget the parameter, the system rebooted and up came the desktop =)

SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33


debating issuing touch /.autorelabel

I doubt it would hurt


1 Like