Can I restore gnome configuration/apps after root reinstall of Fedora 37? (home unformatted)

Ask Fedora Ask in English
,
1

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.

2

You just have to reinstall the apps, their configs are in the home dir.

3
  • If using a separate home partition/subvolume, verify it is properly mounted.
  • Make sure your user name matches the old one and the name of your home directory.
  • Take ownership of the home directory in case the UID/GID has changed:
sudo chown -R $(id -u):$(id -g) ~
4

unfortunately, a lot of programs installed at the root level have been lost like kubectl and docker

5

It looks properly mounted. Please lmk if something seems off.

[xyz@fedora ~]$ lsblk
NAME                                      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
zram0                                     252:0    0     8G  0 disk  [SWAP]
nvme0n1                                   259:0    0 238.5G  0 disk  
├─nvme0n1p1                               259:1    0   600M  0 part  /boot/efi
├─nvme0n1p2                               259:2    0     1G  0 part  /boot
└─nvme0n1p3                               259:3    0 236.9G  0 part  
  └─luks-45379e9b-14e6-469e-a6d1-4d70e1de6bdc
                                          253:0    0 236.9G  0 crypt /home
                                                                     /
[xyz@fedora ~]$ df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  4.0M     0  4.0M   0% /dev
tmpfs          tmpfs     7.7G     0  7.7G   0% /dev/shm
tmpfs          tmpfs     3.1G  2.5M  3.1G   1% /run
/dev/dm-0      btrfs     237G   21G  217G   9% /
tmpfs          tmpfs     7.7G   16K  7.7G   1% /tmp
/dev/dm-0      btrfs     237G   21G  217G   9% /home
/dev/nvme0n1p2 ext4      974M  277M  630M  31% /boot
/dev/nvme0n1p1 vfat      599M   18M  582M   3% /boot/efi
tmpfs          tmpfs     1.6G  136K  1.6G   1% /run/user/1000
6

So, you have freshly reinstalled? Then, you need to install programs you want to use that are not part of the default installation. For docker, you can follow Docker and Fedora 35 - Fedora Magazine. kubernetes is in Fedora’s repo, see kubernetes | Package Info | koji.

When working with containers, please also read and consider Using containers (Docker/Podman) :: Fedora Docs and Docker and Fedora 37: Migrating to Podman - Fedora Magazine.

looks good to me.

1 Like
7

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.

8

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.

9

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:

  1. decrypt my luks partition and get the UUID from lsblk
  2. make sure the fstab conf has the UUID for each mount point mapped to the correct subvolume in the fs to be rescued
  3. 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.

10

Not quite.

  1. boot to the live media.
  2. open a terminal window and since all the remaining commands will require root provileges, do su -
  3. 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.
  4. Mount the root file system from that btrfs file system with something like
    mount -t btrfs -o subvol=root,compress=zstd:1 <UUID> /mnt
  5. Mount the additional required tempfs file systems with
    `for dir in proc sys run dev ; do mount -o bind /$dir /mnt/$dir ; done
  6. now chroot to the system with chroot /mnt
  7. 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.

1 Like
11
1 Like
12

Amazing thanks

13

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?

Once again, appreciate the amazing walk-through.

1 Like
14

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.

15

The last of my questions…
Are /boot and /boot/efi useful at this stage, where the root is already up and running? It also looks like subvol root gets remapped in the fstab for some reason.

Also, you can manually mount home after root with mount -t btrfs -o subvol=home,compress=zstd:1 <UUID> /mnt/home right?

Many thanks for all the insight.

16

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.

1 Like
17

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.

18

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.