Feature idea: package an installer image as a grub entry before F8.

[Will Woods]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070605/5afa1bf6/attachment.sig>