On Sat, Feb 3, 2018 at 5:53 PM, Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> wrote: > On 3 February 2018 at 22:55, Richard Shaw <hobbes1069@xxxxxxxxx> wrote: >> >> Any news on the cause? I'm waiting to update until this is figured out... > > > Still don't see any update about the issue. > It is really pain in the a*s that Linux still has no good support to handle > such cases like it is on for example on Solaris where is possible to > generate using zfs snapshots and cloning separated BEs (boot environments) > on each upgrade or even new package install which adds to grub menu new boot > entry which allows preserve 100% state from before any packages operations. It's not a Linux limitation, the infrastructure is there. SUSE has had state preserving rollbacks for several years. Their Btrfs patches for GRUB, which I think are now upstream so we might also have them, discover Btrfs snapshots made by snapper before and after every package change, and build menu entries for each snapshot. Pick one, and you get a read only one time rollback to the chosen snapshot. Fedora repo does have both snapper and a dnf snapper plugin that'll take snapshots of rootfs before any dnf update, and it's possible to use snapper to rollback - I've only ever done it with a Btrfs rootfs but I think snapper also supports LVM thinly provisioned volumes and snapshots. The gotcha compared to what SUSE folks are doing is, on Fedora it's possible (likely) to get a disconnect between the kernels located in /boot vs the modules installed on the rolledback rootfs, because /boot is not snapshot along with rootfs on Fedora since they're separate file systems. So that'll inevitably snare things unless you manually 'cp -a --reflink' copy the latest modules dir from a current tree into a rolledback tree. And the reason for this is the Fedora installer enforces /boot being on a plain ext4 or XFS volume, it can't be on Btrfs due to a now 6+ year old grubby bug that causes grubby to not update grub.cfg if /boot is a Btrfs subvolume. > Just checked a bit dnf documentation and seems that dnf supports rollback > operation. However as long as Fedora repo holds only latest versions of the > each package I'm only curious how it is handled as rpm no longer supports > repackage and rollback operations (?). I've never tried doing rollbacks from dnf itself. If I need to rollback, I just pick one I'm doing to rollback to, update the fstab inside that snapshot to reflect the correct snapshot/subvolume name used by the subvol= mount option, reboot, and then I manually edit the boot entry's rootflags=subvol= parameter to reflect the name of the snapshot I want to boot. Done, I've rolled back. Of course you've just rolled back everything except home. So even your journal log is rolledback on Fedora since it's located in the root subvolume, whereas on SUSE they've got one of the longest fstabs mankind has imagined, in order to carve out with a scalpel exactly what is and is not subject to rollbacks. > > Can someone share some details how to use dnf rollback and/or is it now > supported by Fedora rawhide? > Issues like this one with crashing gnome may happen always an no one should > be bashing anyone for such faults as rawhide is devel by definition however > details about how system needs to be prepared to handle rollback using dnf > are quite important. I'm seeing it in Fedora 27. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
