On Fri, 2007-06-01 at 15:25 -0400, seth vidal wrote: > On Fri, 2007-06-01 at 14:13 -0400, Will Woods wrote: > > Oh definitely. In fact, that's the main reason *I* care about this > > feature. Live-ish upgrades would be a cool feature and save our users > > some time, but making system upgrades easier to script is the icing on > > the cake for me. > > > > But how do we get around all the mess? Items like: > > - ext3->ext4 conversion > - lvm format changes > - dev->udev > - etc. etc. Dude, I'm well aware of the issues involved. I said "Live-ish" because I know Debian-style live upgrades aren't possible - which is why we don't support them. However, I believe we can improve the upgrade process to the point where the single-command, fire-and-forget upgrade is possible. That's what people are really asking for when they ask for "Live upgrades". Obviously you're going to have to reboot at some point to get into the newly-upgraded system, so I don't really think people care if you reboot *before* upgrading the kernel or *after*, so long as it's minimally interactive. Okay, so. The upgrade process currently goes something like this: 0. boot into installer 1. download new repo info 2. download all new packages 3. upgrade all new packages 4. reboot into new system Debian just ignores step 0, and runs with the old kernel and live filesystems. Bad mojo. I'm not at all suggesting that we do that. The problems I'm trying to solve are related but separate: 1. It could be easier to get to step 0. Currently you need to to burn a DVD or boot.iso/rescue CD or manually munge grub.conf to boot into the installer. 2. Step 2 (necessarily) takes a long time, so network upgrades spend most of their time stuck in the installer waiting for packages to download. To tackle the first problem, we just need a simple script that will grab the kernel/initrd from media or a mirror and munge your pre-existing grub.conf (trivial using grubby) to boot into it. Furthermore this tool could ask a couple questions about where you're installing from - the amount of information needed for an upgrade is minimal. If we gather this before booting into the installer, we can do a fully-automatic upgrade. As for the second problem, what I'm proposing is a simple re-ordering of a couple of the steps: 1. download new repo info 2. download all new packages 0. boot into installer 3. upgrade all new packages 4. reboot into new system So now we spend a minimal amount of time in the installer, *and* the upgrade is fully automatic, *and* we're still doing upgrades The Right Way. Does this sound like a reasonable plan of attack? -w
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
