I crashed my system during a dnf update and reinstalled my boot and root partitions. My home directory was preserved without reformatting, and I can see all my data in the home directory. However, none of the apps I had installed or any previous configurations of my user were preserved.
Is there a way to resync my new gnome environment with my home directory data, or am I going to have to install and configure apps one by one?
In fact, I tried to reinstall Google Chrome and received a popup warning me that
The profile appears to be in use by another Google Chrome process (xxxx) on another computer (fedora)…
which is definitely telling. I should also mention my gnome keyboard shortcuts have been preserved.
The home folder was preserved. What I don’t understand is how the same partition /dev/dm-0, can be mounted on / and /home. 1) How is /home preserved if both are using the same partition/fs dm-0? 2) Does fedora (or btrfs) have this configuration hardcoded so that OS knows to treat the dm-0 fs mounted on /home as separate from the same being mounted on /?
Finally, if mounting from a live boot USB, would I simply mount the same partition on / and /home and it’ll work like magic? I’m assuming after mounting these volumes, I would chroot into the root folder like /mnt/myrescue/root folder (which is where etc is located) and NOT chroot into /mnt/myrescue.
Are you using BTRFS? If so then the default install creates one btrfs volume then inside that volume creates 2 subvolumes /root (mounted at /) and /home (mounted at /home). It shows with fdisk -l and lsblk -f as the same partition. It also shows in /etc/fstab with the same UUID but in the options shows the subvolume difference.
Thank you @computersavvy ! It’s starting to make a bit more sense. Mounting would’ve made recovery much faster, but I wasn’t able to set the mounts and fstab properly. And none of the online guides mention any of this. So if i was to live boot into linux to try and recover a partition that won’t boot, I would:
decrypt my luks partition and get the UUID from lsblk
make sure the fstab conf has the UUID for each mount point mapped to the correct subvolume in the fs to be rescued
mount the unencrypted partition to both points, like mount /dev/mapper/my-decrypted-dr / and mount /dev/mapper/my-decrypted-dr /home
This is where I’m less certain…
4) chroot into the root folder, NOT / like chroot ./my-rescue-dir/root
5) run rpm or dnf tasks to clean and fix
Is this correct?
Also, is it possible to only reformat a subvolume in btrfs because seems so.
open a terminal window and since all the remaining commands will require root provileges, do su -
find out the details on your installed drive partitions with lsblk -f
This should show a btrfs partition complete with the UUID. Since it is not mounted it may not show more detail, but rest assured that there are likely 2 subvolumes in that partition.
Mount the root file system from that btrfs file system with something like mount -t btrfs -o subvol=root,compress=zstd:1 <UUID> /mnt
Mount the additional required tempfs file systems with
`for dir in proc sys run dev ; do mount -o bind /$dir /mnt/$dir ; done
now chroot to the system with chroot /mnt
Finish mounting all the required file systems with mount -a
At this point you should be in the installed OS environment and can to anything needed as root.
Note that I did not mention how to unlock the encrypted file system – I don’t use one.
I also did not mention anything about repairing a file system (fsck or similar) which MUST be done without having the file system mounted and active.
In the chroot environment you will be using the kernel booted from the live media so some things may not function 100% as expected.
BTRFS is not my area of expertise so I am not fully versed on what to do there. man btrfs has a lot of info.
I was implying root privileges, but thanks for the definitive explanation. My drive is encrypted so I’d use the cryptsetup luksopen utility to get it into a usable state.
#4 was the missing piece, so I see how you define the subvolume during mount. The confusion I have with this structure is that /root/etc typically contains the fstab file with the subvolume mapping configurations, but how /home would access that file given that /root and /home reside at the same file level.
Also, get #5. However, what’s left to mount with #7?
They are at the same level. Both are subvolumes of the btrfs partition. Thus they are treated as separate partitions/volumes for mounting.
/home does not access anything. Once you have done steps 1-5 and do the chroot in step 6 the /mnt which existed in the live media no longer exists. At this point /etc is exactly that: /etc in the chroot environment. Since / is already mounted (in step 4) the call to mount -a (in step 7) uses /etc/fstab to mount the remaining files systems that are identified there.
/home, /boot, and /boot/efi are not yet mounted. Step 7 uses the entries in /etc/fstab to mount them.
You can certainly do all those mounts before doing the chroot if you choose. I find it simpler to allow the fstab file to control it rather than doing so manually. (one single command rather than three separate commands that each may fail due to a typo or skipping a step)
If you are trying to do any form of system upgrades within the chroot environment it is strongly encouraged that /boot and /boot/efi be mounted. If not then upgrades that affect any of the boot files or configs may fail or have unexpected issues. /boot and /boot/efi are critical file systems for the OS. Mounting of /home is not required mostly, but for consistency of structure I mount it.
What makes you say that?
If you used the proper UUID and options it is already mounted and does not get remounted.
Perhaps root subvol mapping is specified in my fstab for completeness, but it seems redundant as mount -t btrfs -o subvol=root,compress=zstd:1 <UUID> /mntis a prequisite to all other actions when chroot-ing in.
But it is exactly the same in /etc/fstab, except for the ordering of the attributes when mounting from command line. When one uses mount -a it reads /etc/fstab and mounts anything in that file that is not already mounted. Thus the root file system is (always) skipped when doing that command in the chroot environment.
When initially booting a system it is mounted with the attributes in the fstab file. Thus the options are not redundant nor is the root file system ever overlaid when using mount -a. One must understand how the mount command performs.
In plain english the mount -a command mounts (or attempts to mount) all file systems listed in /etc/fstab that are not already mounted.