On Feb 3, 2014, at 8:44 AM, Jorge Fábregas <jorge.fabregas@xxxxxxxxx> wrote:
> On 01/30/2014 09:02 PM, Jorge Fábregas wrote:
>> Now, here's the thing. I wanted to permanently run off these snapshots
>> so I wanted to delete the parent "subvolumes" for these snapshots (e.g.
>> "commit" the snapshot) by doing:
>>
>> # mount -o subvolid=5 /dev/vda3 /mnt
>> # btrfs subvolume delete /mnt/root
>> Delete subvolume '/mnt/root'
>> ERROR: cannot delete '/mnt/root' - Device or resource busy
>
> Well, I found out you can rename the subvolumes and not only that; you
> can also rename them ("move" them) while they're being used. This is
> what I'm doing when I want to rollback my system to the previous state:
>
> 1) Modify GRUB2: Change "rootflags=subvol=root/yum_*" accordingly & reboot
It seems to me that there will be some error message in the log as the (stale) fstab tries to do a rw mount of a different subvol on top of the one specified by rootflags=. Or maybe it succeeds silently, I haven't recently tested this scenario.
>
> Since I used the default setup for btrfs, Anaconda created a /boot of
> its own (ext4). (I presume a btrfs /boot is not ready yet).
Yes, I mentioned this in the monolithic post I just sent. It's ready except for a grubby bug.
> This
> creates some time paradox issues when I want to run "yum upgrade" again:
>
> - yum wants to install a kernel that I already have (the one I'm
> currently running with)
> - yum wants to remove the oldest kernel (which it already removed on
> previous existence)
Yes I mention this in the long email also. I think /boot simply needs to be snapshot and rolled back in parity with a rootfs snapshot: either by making /boot a directory within the rootfs subvolume; or if boot and root are separate then they need to always be snapshot and rolled back together. OpenSUSE does the former (/boot is a directory not a subvolume), and since they make /boot/grub2/<arch> a subvolume, it's excluded from the rootfs snapshot.
That brings up a point of possible confusion. A snapshot of a subvolume only snapshots that FS tree, it does not recursively snapshot any subvolumes contained within subvolumes.
> All of this due to the fact that I restored the previous RPM database
> when I rollbacked my system.
Yes.
> There is more to this yum-plugin/btrfs/rollback than meets the eye :(
The main issue you've run into is /boot is newer than rootfs, because it too wasn't rolled back when rootfs was.
There probably should be some sane limitation (by default, of course users can modify this) on system snapshot and rollbacks. I think it makes sense to have a max of five system states: current, previous, previous 2, previous 3, original. The original would be "as-installed" so that you could go back to a totally clean system, or, very cool, you can create a derivative installation without installing ;-) Just fork off the originally installed system, and create a whole new system.
Chris Murphy
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
