Mike Gerdts wrote: > On 9/7/06, Casper.Dik at sun.com <Casper.Dik at sun.com> wrote: >> Originally, both ran the miniroot from disk but this required the >> realmode >> drivers for bootstrapping (loading bits from all over the place until the >> disk/net device driver was loaded). > > Last time I looked closely at a Red Hat installer, the text mode > installer was available in a few MB and resided in RAM. This was in > the days when a Compaq DL360 with 128 MB was a pretty decent box. If > you wanted GUI, you could use the bits in the few MB of text mode to > provide higher level functionality by mounting the tools from NFS, CD, > local hard drive, etc. A key tool used to make this possible is > busybox - essentially one executable that knows how to be a shell and > 50 or so other commands via multiple hard links in /bin. >
Yeah, busybox is very nice for constrained environments. > The last time I looked at the compressed UFS image shipped as part of > newboot (with S10U1), it seemed as though very little fat had been > trimmed. Certainly there was no effort analagous to the approach > taken by busybox. I also noticed functionality that had been removed > without removing the corresponding binaries and reclaiming of space. > I don't think there's a lot of fat on there, as we've had to look at CD space issues fairly regularly, but if you're seeing things that could be removed and aren't, we'd be happy to know about it. Some of it would have to do with how we construct the miniroot, though; we aren't necessarily striving for absolute minimization, but trying to balance it with maintainability of the construction process and limiting the amount of extra testing required, so you might find that we have the complete contents of some package on there even though we don't necessarily need every portion of it. I'm not particularly excited about applying something like busybox, though, because then we're presenting packages with a fundamentally different environment than they have on the installed system, with all the problems attendant to that. > By using the BIOS to read a mini root that has drivers required to > access common network devices, block devices, file systems, keyboards, > and text-mode displays, the bits could be in place to read things like > the X server and complicated install logic from installation media > without pulling it all into a ramdisk. Maybe this approach is already > being taken, but it is not being communicated. > The reason we pull some things onto ramdisk rather than having unpacked versions on the CD has completely to do with the requirement to get a functional system onto CD1 (meaning that it can continue installing itself from additional media after rebooting to the bits that CD1 lays down on the disk), which is a fundamental assumption in the current install architecture. If we add in a compressed filesystem such as ZFS or Moinak's compressed lofs driver that we're currently using on the live DVD prototype we could do things a little bit differently. Dave
