Re: installing core udebs
Sat, Feb 24, 2001 at 10:45:22PM +1100 wrote:
> Im not exactly sure what the current plan is for getting the core udebs
> on the boot disk, but how does this sound.
What is wrong/limiting with the current way that d-i boot floppies are being
created?
-udeb dependancies are resolved by apt
-udebs are unpacked into the host at time of boot disk creation, a user can
choose which udebs to include at that time fairly easily
-a root filesystem capable of bringing up the network is created, that is the
initrd.
Joey and Erik recently discussed a new boot sequence that hasn't been
implemented which shares some of the good points of what you propose here:
http://lists.debian.org/debian-boot-0102/msg00404.html
I see your point about the initrd being isolated from anything else on the
system, admittedly the current system doesn't provide for that level of
isolation. I don't, however, see that we need the isolation. The boot sequence
will basically be handled by rootskel, which shouldn't need to be messed with
once we settle on something.
My only concern is that creating the root filesystem in this way adds more
complexity and I don't (yet) see the gain.
David
P.S. I just installed the hurd on one of my boxes, fun!
>
> Use an initramdisk, linuxrc is a static version of busybox with the
> following features.
> #define BB_CHROOT
> #define BB_DPKG
> #define BB_GUNZIP
> #define BB_INSMOD
> #define BB_LINUXRC_DI // This a custom initrd for the debian installer
> (more below)
> #define BB_MKSWAP
> #define BB_MOUNT
> #define BB_RM // This is needed for BB_DPKG (i need to document it)
> #define BB_SWAPONOFF
> #define BB_TAR
>
> Compiled statically against uClibc these features come to about 80KB
> (44KB after gzip -9)
>
> The purpose of this busybox based linuxrc program is to setup the root
> filesystem on the shm filesystem (or ramfs if we still want to go that
> way).
>
> Its still at planning stage, but im thinking of the following steps.
>
> 1) mount procfs under /proc
> 2) mount shm under /dev/shm, (if we use devfs this is done
> automatically)
> 3) load any kernel modules found in the initrd filesystem
> 4) mount the filesystem of the boot medium (e.g. /dev/fd0)
> 5) search for, unpack and insert any core kernel_module*.udebs found
> here.
> 6) scan /proc for a list of storage devices
> 7) try and automount detected storage device partitions
> 8) create swap file or swap partition and use it. //PROBLEM, lowmem
> machines a) with no existing partitions and only one drive, or b) with
> partitions but no space will have problems past this point
> 9) search mountable partitions for *udebs
> 10) install found udebs under /dev/shm
> 11) pivot_root to /dev/shm
> 12) finish initrc and continue with a normal busybox init based in
> /dev/shm.
>
> If we do this then the boot medium could look something like
>
> /dev/fd0 is formated with cramfs (maybe vfat as an alternative?),
> contains
> /initrd.tar.gz (contains the initrc image)
> /bzImage (the boot kernel)
> /kernel-modules*udeb (kernel modules that need to be installed to create
> a swap partition, i.e. fs, scsi or ide modules)
> /rootskel*udeb
> /cdebconf*udeb
> /busybox*udeb
> /libc*udeb
> ....
> other core udebs
> ....
>
> the initrd.tar.gz
> The fileystem driver to suit this fs must be statically compiled into
> the kernel
> If the filesystem on the boot medium is a module it must be contained in
> here.
> /linuxrc /* static against uClibc */
> /dev
> /proc
> not much else
>
>
> To prepare the boot disk we just need to copy a kernel, initrd and a
> bunch of udebs onto a disk, easy for end users to make custom disks.
>
> This setup would mean that the initrd would be isolated from anything
> else in the system, once it was working it wouldnt need much maintanance
> at all.
>
> If we had updates for core udebs they could be placed on seperate medium
> (hdd, floppy) and dpkg could install them rather than older version of
> the udebs that may be on a crusty old cd.
>
> The custom linuxrc wouldnt take mushc work, it would be mostly just
> combining the functionality from other busybox applets.
>
> It would work for machines with low mem.
>
> How does it sound for a plan ?
>
>
> Glenn
>
>
> --
> To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: