recent desktop backgrounds

So first I was like:
I hate everything about this except when it fucking works
And then I actually started looking at code and I was like:
how the fuck did I get here whose code is this
So then I was like:
this is too fucking broken to fix starting the fuck over
And then:
coffee
But then:
we learned a valuable lesson today
So then there was:
debugging will continue until morale improves
And now it’s like:
I'm pretty sure that I'm helping

please don't make me do this again

Advertisements

fedup: a little background

A short history of upgrade tools

In the beginning, the Installer was all. If you wanted to upgrade a Red Hat / Fedora system you downloaded the CD images, burned them all to CDs, and sat around swapping disks in and out until your system was upgraded. What fun!

Five years ago I was a QA guy, doing lots and lots of upgrade testing like this. Eventually, after burning a couple thousand CDs, I had this idea: hey, it’d be cool if you could upgrade your system by running some command that would set everything up for you and do the upgrade, without having to download all these ISOs and burn them to CDs. A small pile of gross hacks later, it turned out it was actually possible… and thus PreUpgrade was born.

Fast-forward to last year: I’m now actually a developer on the Installer team. We’re in the middle of basically completely rewriting everything and we keep bumping into weirdo corner cases for Upgrades. And we had this idea: hey, it’d be cool if someone rewrote PreUpgrade so it wasn’t a pile of gross hacks, and instead it was just a separate thing that did upgrades. And then we wouldn’t need to deal with a lot of special if upgrade: ... cases all over the place. Hooray!

And so it was decided. So the new installer doesn’t handle upgrades. At all. Something new is required. And that something is..

Fedora Upgrader – “fedup” for short

The premise is simple: There’s a frontend bit that sets up your system for the upgrade (downloads packages, sets up kernel & initrd, modifies bootloader entries, etc.). That’s fedup. And then there’s the “upgrader image” – the thing that fedup downloads to actually run the upgrade. That’s fedup-dracut. As the name implies, it’s just a regular dracut-built initramfs, with some extra bits and pieces thrown in.

The process works something like this:

fedup

  1. downloads packages and kernel + upgrade.img from the new release
  2. sets up some directories and files so fedup-dracut knows what to do
  3. sets up the bootloader config so it will boot the new kernel + upgrade.img
  4. reboots

fedup-dracut

  1. starts the system and finds your root partition (like normal boot)
  2. enters your old system and sets up the disks (like normal boot)
  3. systemd trickery: If the files that fedup set up are present, we return to fedup-dracut and run special dracut hooks:
    1. upgrade-pre: for pre-upgrade migration tasks (nothing here yet)
    2. upgrade: for the actual upgrade (via system-upgrade-fedora)
    3. upgrade-post: for cleanup etc. (we save the journal to /var/log/upgrade.journal, and write /var/log/upgrade.log for those of you who don’t like the journal)
  4. reboots back to your newly-upgraded system

Part of the goal was to make the process distro-neutral. Other than system-upgrade-fedora, none of this is really Fedora-specific. The upgrade framework itself (the dracut hooks and the systemd trickery) should apply to any distro using systemd and dracut.

The details are a bit vague here because the design isn’t finalized. The current (working prototype) design involves bind-mounts and doing systemctl switch-root twice, which has caused us a bunch of problems. We’ve got some workarounds for this for Fedora 18 Beta but the design will likely change a little between now and Final.