#193 Using Btrfs to Upgrade Fedora
Closed: published 9 months ago by rlengland. Opened 10 months ago by rlengland.

Sequel to https://fedoramagazine.org/use-lvm-upgrade-fedora/ but for Btrfs

It is considerably easier to use btrfs snapshots for a fallback instead of LVM in case system-upgrade goes south. (As indeed it did when upgrading my OG Pinebook.) It might not even need the “experts only” disclaimer. In the simplest form, you create a subvol snapshot and do a normal system-upgrade. To fallback, edit the grub entry for the previous kernel to use the snapshot. I could cover cloning the default grub entry with grubby for the fallback, but probably just exhort readers to practice editing grub entries at boot time.

https://discussion.fedoraproject.org/t/article-proposal-using-btrfs-to-upgrade-fedora/81258


Metadata Update from @rlengland:
- Issue tagged with: article, needs-image

10 months ago

Metadata Update from @rlengland:
- Issue assigned to sdgathman

10 months ago

The new title is: Use Btrfs to Upgrade Fedora with Easy Fallback
https://fedoramagazine.org/?p=38259&preview=true&preview_id=38259

It's not really a "rollback" since both systems are active until you delete the snapshot subvolume.

Inline code style is very ugly. I forget what the workaround for that was in Wordpress.
https://fedoramagazine.org/?p=38259&preview=1&_ppp=bb19c30ec2

Metadata Update from @rlengland:
- Custom field preview-link adjusted to https://fedoramagazine.org/?p=38259&preview=true&preview_id=38259

10 months ago

The "preformatted" style you have used is the recommended format for code. There are some options available in the left column under "Block" when the preformatted section is selected. But they are only color for text and background and the typography.

Inline code style is not recommended.

The article looks like it is nearing or has reached completion. Are you ready for us to review it?

Yes, I believe it is ready for review. I even added an appropriate image.

The "preformatted" style you have used is the recommended format for code. There are some options available in the left column under "Block" when the preformatted section is selected. But they are only color for text and background and the typography.

Inline code style is not recommended.

The article looks like it is nearing or has reached completion. Are you ready for us to review it?

yes

Now that kernel-6.2.12 works for f38, maybe I should modify/remove the part about actually using the fallback?

The image is from flikr: https://live.staticflickr.com/3779/20155029206_2aef891f6c_b.jpg
I haven't found the license details for flikr.

The image is from flikr: https://live.staticflickr.com/3779/20155029206_2aef891f6c_b.jpg
I haven't found the license details for flikr.

The license is important. If you cannot find it, we won't be able to use that image. The aspect ratio might be a problem for that particular image anyway. The image needs to be 1890x800. We usually recommend that people get images from unsplash.com because we know that their licenses are OK for use on Fedora Magazine.

Ah, this picture is CC by-nc-sa https://creativecommons.org/licenses/by-nc-sa/2.0/
Is that ok for Fedora? How does attribution work? Caption? Link back to flikr from the image?

Now that kernel-6.2.12 works for f38, maybe I should modify/remove the part about actually using the fallback?

I'm not sure I understand the question. But it might be good to get @chrismurphy to review this article. He has mentioned some ideas about making Fedora Linux's dnf automatically do this sort of thing as part of a normal upgrade. It might be good to make sure we aren't recommending anything that could cause problems for future Fedora Linux releases.

Ah, this picture is CC by-nc-sa https://creativecommons.org/licenses/by-nc-sa/2.0/
Is that ok for Fedora? How does attribution work? Caption? Link back to flikr from the image?

That license looks OK to me. Just be sure you credit the original author and mention any cropping or other alterations you make to it in the caption.

I have that stuff on the media library, but the post preview does not have the caption or alt text or description. Media library: https://www.flickr.com/photos/brenejohn/20155029206/

There is a special control in the right-hand sidebar for adding the cover image. If you use that to add the cover image, then it should display properly.

Did that - still no attribution visible on the article preview.

I'll take a look ...

It won't let me edit it while you have it open. I'll try again later. 🙂

Great. Lower resolution, not just cropped. But the link to flikr should make that obvious.

I haven't read the preview so I might significantly misunderstand, but this sounds something like this dual boot test station concept I've drafted. The gotcha is not snapshots or rollbacks, but what if you do completely ordinary things like grub2-mkconfig (even without a flag) and it stomps on all your boot loader snippets? That sort of real world scenario that's difficult to imagine in advance.

Currently grub2-mkconfig and grubby have no concept for shared BLS snippets in /boot/loader/entries the assumption is all BLS entries are 100% owned by the running Fedora - which is obviously flawed per the specification itself. And it can strip out the kernel command line in all the snippets in favor of the one in /etc/kernel/cmdline.

So you just have to be aware "there be dragons".

If you ask grubby to --update-kernel=ALL it does that literally.

Thanks @chrismurphy! That's exactly the sort of insight I was hoping you would have. 🙂

This article just has the user edit at boot time on the grub menu if they need to use the fallback. So there is no deviation from standard system-update procedure other than making the snapshot subvolume. That's why I did not include a disclaimer. No editing of grub entries on disk is required to use the technique outlined.

If you do decide to use grubby, etc then other articles cover that, and yes there are things to watch out for - but that is not part of this article.

Isn't there a concern with rolling back to a snapshot that doesn't have the /lib/modules/<kernel-version> that matches the kernel being booted though? The ESP and the booted system being out-of-sync still seems like something you might have to be careful of.

Isn't there a concern with rolling back to a snapshot that doesn't have the /lib/modules/<kernel-version> that matches the kernel being booted though? The ESP and the booted system being out-of-sync still seems like something you might have to be careful of.

For the immediate rollback - no. In fact, the danger is not that /lib/modules entry will be removed in the snapshot, but that the f38 system will eventually delete the f36 kernels from /boot when the kernel is updated. By then, there will be several kernels under your belt in f38. You could flag a kernel version as "don't remove" in dnf.conf, if you want the f36 snapshot to be bootable for a longer time.

... the f38 system will eventually delete the f36 kernels from /boot when the kernel is updated. By then, there will be several kernels under your belt in f38. You could flag a kernel version as "don't remove" in dnf.conf, if you want the f36 snapshot to be bootable for a longer time.

Still, the above might be a good thing to note in your article to prevent people mistakenly thinking they have an easily restoreable "backup" that they can go back to at any future time. That, or tell them they should delete the snapshot once they are comfortable that the upgrade is working properly to save space and "because it won't work after the corresponding kernels are removed from the ESP by future updates".

Looked at ways to protect a kernel version. keep= is gone for dnf. exclude= doesn't notice version. protected_packages does not look at version.

  1. Set installonly_limit=0 and manually remove old kernels. (Simple, but tedious and ugly.)
  2. back up files in /boot and /boot/loader/entries matching f36 version to preserve, dnf remove that version, restore files in /boot (always a good idea to have a backup of all of /boot which you can access from live media or rescue image). (A little complex for this otherwise simple article.)
  3. ?

A third option might be to detail how someone actually could restore the contents of the ESP from the snapshot of the rootfs. They would have to acquire a "chroot" environment somehow (either by setting a breakpoint in the initramfs boot phase or by using a separate boot image and mounting things). Then they would need to run the kernel-install script with the right parameters. It might also require some manual cleanup of the snippets in the ESP. It is a bit involved, but it can be done. It might be good to have that sort of rescue procedure documented somewhere anyway.

I added an "Expiration" section and suggested options 1 and 2.
https://fedoramagazine.org/?p=38259&preview=1&_ppp=392a0d822d

Should I change status, or do editors do that?

I already changed the status to "review". Oddly though, pagure didn't leave a metadata update notification.

From applying the article to several more laptops, I have an additional suggestion. Just before "dnf system-upgrade reboot", make another snapshot of root called, say root.dl. This takes little additional space as all but downloaded packages are shared with f36 snap. BUT, if you stupidly did not have enough free space for the upgrade, then you don't have to download the entire 4.8G of packages again.

Metadata Update from @sdgathman:
- Assignee reset
- Issue untagged with: article, needs-image

9 months ago

Huh. What does that Metadata Update from [me] mean? Assignee reset; Issue untagged

Metadata Update from @rlengland:
- Issue assigned to sdgathman
- Issue tagged with: article

9 months ago

@sdgathman It appears that the meta data (items in the right column in the ticket) were modified and both the "Assignee" and "Tags" were changed. The "Tags" must be set to "article" and I've reset it. I'm not certain what changed the "Assignee" but it is set to you. You can see these changes listed in the comment thread in the ticket. The metadata is really for the editors to use to track the status of the ticket so changes there by the authors should not be needed.

Have you made the changes you are proposing to the article?

I did not make any changes, and have no idea why it changed metadata in my name. I don't even have the article open in any tabs. I was waiting for insns if you wanted me to make the change.

Metadata Update from @sdgathman:
- Issue untagged with: article

9 months ago

So apparently, adding a comment to pagure updates the metadata for the article.

Yeah. Pagure can be a little buggy sometimes. Go ahead and make any revisions to your article that you like. The schedule is booked until mid next week anyway, so you have plenty of time to get revisions in before your article will go out.

Thanks!

Metadata Update from @glb:
- Custom field publish adjusted to 2023-05-12

9 months ago

Issue tagged with: article

9 months ago

Ok, I added a note about running out of space and dnf getting confused by btrfs block sharing. Let me know if it is not clear enough.

https://fedoramagazine.org/?p=38259&preview=1&_ppp=0fe61b83a2

Metadata Update from @glb:
- Custom field editor adjusted to glb

9 months ago

Metadata Update from @glb:
- Custom field image-editor adjusted to sdgathman

9 months ago

@sdgathman: Sorry I put the editing on this one off to the very last minute. I've made an editing pass on your article. You can make any further changes you like to it before it is published at 08:00 UTC (~7 hours from now). I expect to be up late tonight and I'll hit the schedule button at around 05:00 UTC or 06:00 UTC to give you as much of a chance as possible to make further revisions before this goes out. Once I hit the schedule button, it will become readonly for you and you will have to request that an editor make further updates.

https://fedoramagazine.org/?p=38259&preview=true&preview_id=38259

Thanks!

Issue status updated to: Closed (was: Open)
Issue close_status updated to: published

9 months ago

Login to comment on this ticket.

Metadata
Boards 1
articles Status: published