Reinstall F34 to fix brightness issue without deleting files

Hi,

I installed F33 last year and encountered the brightness issues like so many (brightness could not be set using brightness keys). After upgrading to F34, the issue has persisted. However, when I run vanilla F34 from a live USB stick, the issue does not occur. Because of this, I assume that I have unknowingly changed some default settings on F33 while trying to fix the error (also see this question).

Is there a way I could reinstall F34 (to reset the default settings) without losing my data? E.g., only reinstall root and boot and leave home untouched? Would that even change something?
Also, my harddrive is encrypted (I don’t know if that’s relevant or not).

I would first try creating a new user and logging in with that user to see if the issue persists. If it doesn’t, you will know the issue is in the config in /home and reinstalling while preserving home won’t help.

To answer your question more directly, it would help to see lsblk -n name,type,fstype,size,mountpoint and findmnt --real

Unfortunately, the issue persists with a new user.

Here’s the output:

$ lsblk -n name,type,fstype,size,mountpoint
lsblk: name,type,fstype,size,mountpoint: not a block device

and

$ findmnt --real
TARGET                                       SOURCE         FSTYPE  OPTIONS
/                                            /dev/mapper/luks-188804e4-39c7-4449-afa7-f639a06e7d5e[/root]
│                                                           btrfs   rw,relatime,
├─/run/user/1000/doc                         portal         fuse.po rw,nosuid,no
├─/boot                                      /dev/nvme0n1p6 ext4    rw,relatime,
│ └─/boot/efi                                /dev/nvme0n1p1 vfat    rw,relatime,
├─/home                                      /dev/mapper/luks-188804e4-39c7-4449-afa7-f639a06e7d5e[/home]
│                                                           btrfs   rw,relatime,
├─/var/lib/snapd/snap/core18/1997            /dev/loop1     squashf ro,nodev,rel
├─/var/lib/snapd/snap/discord/122            /dev/loop3     squashf ro,nodev,rel
├─/var/lib/snapd/snap/discord/121            /dev/loop2     squashf ro,nodev,rel
├─/var/lib/snapd/snap/snapd/11402            /dev/loop7     squashf ro,nodev,rel
├─/var/lib/snapd/snap/core18/1988            /dev/loop0     squashf ro,nodev,rel
├─/var/lib/snapd/snap/gtk-common-themes/1514 /dev/loop5     squashf ro,nodev,rel
├─/var/lib/snapd/snap/gtk-common-themes/1515 /dev/loop6     squashf ro,nodev,rel
├─/var/lib/snapd/snap/gnome-3-28-1804/145    /dev/loop4     squashf ro,nodev,rel
└─/var/lib/snapd/snap/snapd/11588            /dev/loop8     squashf ro,nodev,rel

oops that was supposed to -o not -n. That is OK though, I think I have what I need from the findmnt output.

It looks like you have btrfs on luks. I don’t think it is going to be one-click easy to reuse your home subvolume but you can definitely do it.

If you use the blivet partitioning gui in the installer you can unlock your luks volume and then switch to the btrfs section of the window. From there, you can create subvolumes by hand.

There are a lot of ways to do this. I would have it ignore your existing home subvolume and create a new one instead. After you boot into the new system for the first time you could then go into /etc/fstab and replace the brtfs subvolume for /home with the old one you saved.

Here’s the output from the updated command:

$ lsblk -o name,type,fstype,size,mountpoint
NAME         TYPE  FSTYPE        SIZE MOUNTPOINT
loop0        loop  squashfs     55.4M /var/lib/snapd/snap/core18/1997
loop1        loop  squashfs     55.5M /var/lib/snapd/snap/core18/1988
loop2        loop  squashfs     76.7M /var/lib/snapd/snap/discord/122
loop3        loop  squashfs    162.9M /var/lib/snapd/snap/gnome-3-28-1804/145
loop4        loop  squashfs     75.7M /var/lib/snapd/snap/discord/121
loop5        loop  squashfs     64.8M /var/lib/snapd/snap/gtk-common-themes/1514
loop6        loop  squashfs     65.1M /var/lib/snapd/snap/gtk-common-themes/1515
loop7        loop  squashfs     32.3M /var/lib/snapd/snap/snapd/11402
loop8        loop  squashfs     32.3M /var/lib/snapd/snap/snapd/11588
zram0        disk                  8G [SWAP]
nvme0n1      disk              931.5G 
├─nvme0n1p1  part  vfat          100M /boot/efi
├─nvme0n1p2  part                 16M 
├─nvme0n1p3  part  ntfs          275G 
├─nvme0n1p4  part  ext4            1G 
├─nvme0n1p5  part  ntfs          507M 
├─nvme0n1p6  part  ext4            1G /boot
└─nvme0n1p7  part  crypto_LUKS 653.9G 
  └─luks-188804e4-39c7-4449-afa7-f639a06e7d5e
             crypt btrfs       653.9G /home

There are a lot of ways to do this. I would have it ignore your existing home subvolume and create a new one instead. After you boot into the new system for the first time you could then go into /etc/fstab and replace the brtfs subvolume for /home with the old one you saved.

Okay, I am trying to understand what I’ll be doing here. So basically I reinstall Fedora, create a new /home while keeping the old one and then swapping these after installation? In what way could that solve the brightness problem, though?

1 Like

I have no idea if or how that will solve your issue but you asked this:

Personally, I never reinstall to solve issues. However, many people prefer that approach so I was just trying to answer your question. :smile:

Right, my bad :sweat_smile:. Yeah I totally agree with your opinion, however I don’t know how to solve the issue and reinstalling is the only “fix” that I know and that will work…