Practical boot sequence modifications

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

How about some practical booting hacks?  LiveCDs are smarter than live
installs (i.e. if you pull a Radeon out and drop in a GeForce 2, X will
start complaining that 'radeon' is the wrong driver on an installed
system and refuse to start); and USB booting is a nice alternative to
LiveCDing.

I particularly have two boot hacks I'd like to see.

 - Configure X properly

   If you install Ubuntu with a Radeon, X will have the 'radeon' driver
used; this is because it detects that i.e. Radeon 9200 is supported by
the 'radeon' driver with full 3D acceleration.  If you then pull the
Radeon and switch to a GeForce 2, X will no longer start because Ubuntu
does not recognize at boot that 'nv' or 'nvidia' needs to be used.

   There are 2 solutions here.  First, you could have X reconfigured
each boot on hardware change, as with LiveCDs.  The other solution is to
submit a patch to the Xorg project to fall back to Vesa on such
failures-- a solution that may be more robust, as the user can be
queried for reconfigurations in a graphical environment.  In either
case, manual tweaks to xorg.conf will likely be lost.

 - Boot from disk images

  Booting from USB media is not impossible; however, it is difficult to
boot off a disk image.  A few modifications to an initrd and some kernel
hackery would make booting from a disk image possible.

  The simplest way would be to place the kernel with the disk image,
allowing a boot loader to pass "root_image=/linux/root_image" or such to
the kernel (i.e. /linux/boot/vmlinuz-2.6.12).  The linuxrc script would
read /proc/cmdline and search each mountable device and partition for
the file.  Then that file would be mapped with the device mapper and
used as the root hard disk; the system would boot appropriately and bind
mount /media/host_disk/linux/boot to /boot.

  A more advanced method would be to find a way to pass such information
to the boot loader in a chainload sequence, and simply boot the disk
image.  While this would be more self-contained and leave the initrd and
kernel inside the disk image, it would ultimately behave the same.

  This would be useful for placing a disk image on an iPod and having a
full Linux system in it.  As the iPod should not be haphazardly
reformatted or repartitioned, this approach becomes the most sane;
throwing syslinux or grub at partition 2 should be safe, as it will boot
from that if USB'd up to an x86.  The same concepts would work for FAT
formated USB flash and hard drives, to lesser necessity.


- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDsc8xhDd4aOud5P8RArrnAJwPyl7eg1RxazAQVmIzzmH+VpcIOACfeIho
Efebschgxp67MSNa70Wx/Eg=
=TYcf
-----END PGP SIGNATURE-----