On Wed, 2006-09-20 at 11:53 -0400, David Zeuthen wrote:
On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote:
> How do you plan on performing upgrades when the live cd gets a install
> to hard disk feature?
Well, I've written about that in the README.fedora file. Lemme
cut'n'paste so people can rip it apart. It's basically just a braindump,
I haven't written code for this just yet (patches welcome!).
So.. my plan basically just involves running 'yum -y update' in the
chroot you install to. Not sure we need any UI, some progress feedback
would be nice, not sure if yum can do that already. Seth?
Specifically this means that once you boot into the installed OS all
updates will have been applied. Clearly this requires network
connectivity but such is life. I also expect that it's feasible to do
Right; we certainly can't fit all Fedora Core packages on one LiveCD,
since a LiveCD is obviously only _one_ CD. So you'd never be able to
upgrade off packages from a CD. Furthermore with Extras its highly
likely that people have packages from Extras, and that doesn't fit on a
CD either.
About the only reasons you might _ever_ want to update from a LiveCD are
(a) to test your hardware with the new kernel, and to (b) see what new
apps and features are around, before you actually do the update. I
don't see what is all that useful about doing the actual update from
from the LiveCD itself though, versus rebooting and running a small tool
to pull down new .repo files and doing the equivalent of 'yum update'
which other tools already do for us.
What's the use-case here for update from a LiveCD anyway? Why?
Dan
e.g weekly livecd respins we in four months ppl downloading the
"FC6
Desktop" livecd will already get the updates minus perhaps a week. But
they'll be able to update.
> - Can probably start writing the scripts and UI that will wrap libraries
> from gnome-diskutil. Suggest this script
> This script should
> - take some parameters
> --target-partition=/dev/sda1
> --install-bootloader-at-mbr=true|false
> --fs-label=LabelToUseForFS
> [--swap-device=/dev/sda2]
> --i18n=da_DK.UTF-8
> --root-passwd (probably safer to pass it on stdin)
> - verify that target partition given is large enough
> - dd the ext3 fs over to the target partition
> - resize2fs the fs
> - mount this at /mnt/target
> - delete files specific to livecd; that is
> - /mnt/target/etc/udev/rules.d/00-livecd.rules
> - /mnt/target/etc/init.d/livecd
> - /mnt/target/etc/rc5.d/livecd
> - (TODO: keep this list in sync with script and with what junk
> we put in the pristine ext3 fs.)
> - rewrite /mnt/target/etc/sysconfig/i18n
> - rewrite /mnt/target/etc/fstab (if no swap device is given use
> a swap file on the target fs. No, Swap Files Are Not Evil(tm),
> get over it :-)
> - run /sbin/mkinitrd in the /mnt/target chroot
> - set the root password
> - touch a file on /mnt/target so firstboot is run (TODO: need to
> either put firstboot on the live cd or make firstboot redundant.)
> - write /mnt/target/boot/grub/grub.conf
> - run /sbin/grub-install from /mnt/target/ chroot
> - run 'yum update' in the /mnt/target chroot if we have network
> connectivity. This is to update the installed OS with the latest
> security / feature patches etc. etc.
> - probably need to include yum-updatesd but disable at livecd usage
> since the install system will need it
> Also
> - script should be invoked via a D-BUS system bus service so the
> GUI bits for doing the install become trivial
> - provide reasonable progress feedback / error reporting
> - need to write this tool with paranoia in mind; we're talking about
> messing with people's data here
Cheers,
David