Installed Rawhide with btrfs; dnf system update to v40 has errors ; re-install from Live USB without affecting a non-root subvolume?

[Philip Rhoades]

People,

A while ago I was in a hurry to start using F40 (Sway) and installed 
Rawhide from a live usb to get started.

Everything went pretty well and I had minimal problems up until after 
f40 was release.  However now, when I tried to do a:

dnf system upgrade download --releasever=40

I get a lot of errors - trying to do "dnf --erase" the problem rpms ends 
up making the problem worse.

So, if I try to reinstall from the current f40 live usb - can I do that 
without touching the backup subvolume? ie:

/dev/nvme0n1p3    btrfs   1,951,850,496     464,659,184   1,486,438,224  
  24% /
/dev/nvme0n1p3    btrfs   1,951,850,496     464,659,184   1,486,438,224  
  24% /backup

For decades I have just been using a separate partition for /home with 
ext[2|3|4] and this was conveniently not touched if I did a custom 
install to upgrade - I want to do something similar for this backup 
subvolume.

Thanks,

Phil.

[George N. White III]

On Mon, Jun 3, 2024 at 4:43 PM Philip Rhoades via users <
[e-mail]> wrote:
> People,
>
> A while ago I was in a hurry to start using F40 (Sway) and installed
> Rawhide from a live usb to get started.
>
> Everything went pretty well and I had minimal problems up until after
> f40 was release.  However now, when I tried to do a:
>
> dnf system upgrade download --releasever=40
>
> I get a lot of errors - trying to do "dnf --erase" the problem rpms ends
> up making the problem worse.

You need to tell us what errors you encounter. Are they filesystem
problems,
package conflicts, etc.?
> So, if I try to reinstall from the current f40 live usb - can I do that
> without touching the backup subvolume? ie:
>
> /dev/nvme0n1p3    btrfs   1,951,850,496     464,659,184   1,486,438,224
>   24% /
> /dev/nvme0n1p3    btrfs   1,951,850,496     464,659,184   1,486,438,224
>   24% /backup
>
> Unlike earlier filesystems, btrfs doesn't silently ignore bitrot.  Corrupt

btrfs filesystems
are often a result of hardware faults.

For decades I have just been using a separate partition for /home with
> ext[2|3|4] and this was conveniently not touched if I did a custom
> install to upgrade - I want to do something similar for this backup
> subvolume.

I would never consider a btrfs subvolume a suitable location for a backup.
The btrfs
snapshots provide a way to go back in time after data are lost due to a
software
glitch or command-line typo.  Using a subvolume, when the drive fails, both
the original
and backups may be lost.   If a drive is close to failure,  a linux install
often pushes
it over the edge (due to amount of activity), so I like to make sure
backups are good before
an upgrade or install.

[Philip Rhoades]

George,

On 2024-06-04 09:37, George N. White III wrote:
> On Mon, Jun 3, 2024 at 4:43 PM Philip Rhoades via users
>  wrote:
> > People,
> >
> > A while ago I was in a hurry to start using F40 (Sway) and installed
> >
> > Rawhide from a live usb to get started.
> >
> > Everything went pretty well and I had minimal problems up until
> > after
> > f40 was release.  However now, when I tried to do a:
> >
> > dnf system upgrade download --releasever=40
> >
> > I get a lot of errors - trying to do "dnf --erase" the problem rpms
> > ends
> > up making the problem worse.
>
> You need to tell us what errors you encounter. Are they filesystem
> problems,
> package conflicts, etc.?

I think it will be too much to sort out the errors . .
> > So, if I try to reinstall from the current f40 live usb - can I do
> > that
> > without touching the backup subvolume? ie:
> >
> > /dev/nvme0n1p3    btrfs   1,951,850,496     464,659,184
> > 1,486,438,224
> > 24% /
> > /dev/nvme0n1p3    btrfs   1,951,850,496     464,659,184
> > 1,486,438,224
> > 24% /backup
>
> Unlike earlier filesystems, btrfs doesn't silently ignore bitrot.
> Corrupt btrfs filesystems
> are often a result of hardware faults.

Hmm . . not good . . this is a new card at least . .
> > For decades I have just been using a separate partition for /home
> > with
> > ext[2|3|4] and this was conveniently not touched if I did a custom
> > install to upgrade - I want to do something similar for this backup
> > subvolume.
>
> I would never consider a btrfs subvolume a suitable location for a
> backup.  The btrfs
> snapshots provide a way to go back in time after data are lost due to
> a software
> glitch or command-line typo.  Using a subvolume, when the drive fails,
> both the original
> and backups may be lost.   If a drive is close to failure,  a linux
> install often pushes
> it over the edge (due to amount of activity), so I like to make sure
> backups are good before
> an upgrade or install.

OK - things to think about (thanks for that!) - but my immediate 
question has not been answered - is it actually possible to re-install 
from a Live-USB while preserving what is in the /backup subvolume - like 
I used to do with the ext4 /home partition or will the zubvolume get 
zapped?

Thanks,

Phil.

[Chris Murphy]

On Mon, Jun 3, 2024, at 3:42 PM, Philip Rhoades via users wrote:
> So, if I try to reinstall from the current f40 live usb - can I do that 
> without touching the backup subvolume? ie:
>
> /dev/nvme0n1p3    btrfs   1,951,850,496     464,659,184   1,486,438,224  
>   24% /
> /dev/nvme0n1p3    btrfs   1,951,850,496     464,659,184   1,486,438,224  
>   24% /backup

Yes. You need to do a custom installation. This is not official documentation, it's intended for Fedora QA purposes, it has macros that show Rawhide versions because - well it's for testing :D so you just stick with the version you have, and adapt it for your usecase.

https://fedoraproject.org/wiki/QA:Testcase_partitioning_custom_btrfs_preserv...

It sounds like you would just create a new root mountpoint, thus a new root subvolume, and not create a /home mountpoint. You can optionally click on the existing backup subvolume and then assign it a mountpoint /backup to have the installer do this for you and add it to fstab. Or you can do it post-install yourself.

Note that unless you explicitly delete the current (broken?) root in the intstaller, it will live on. And you also won't be able to navigate to it from /  - you can either mount the top level of the file system and delete it, or you can delete directly by subvolume ID without mounting the top level, see man btrfs subvolume

If you have questions find me (cmurf) on matrix https://matrix.to/#/#fedora:fedoraproject.org