Date: Sun, 5 Apr 2009 22:14:03 +0200 From: David Naylor <naylor.b.david@gmail.com> To: Travis Daygale <anti_spamsys@yahoo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: compiling root filesystem into kernel (preferably tmpfs root filesystem) Message-ID: <200904052214.08866.naylor.b.david@gmail.com> In-Reply-To: <313500.27821.qm@web37106.mail.mud.yahoo.com> References: <313500.27821.qm@web37106.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1333544.9sYBSKDk9c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 04 April 2009 21:52:14 Travis Daygale wrote: > In both the loader and kernel compiling doc, I see snippets of information > like this: #Make space in the kernel for a root filesystem on a md > device.options MD_ROOT_SIZE=3D10 boot_dfltrootInstructs the kernel to mou= nt > the statically compiled-in root file system. Yes, you can compile a fs image into the kernel. This however will be stat= ic=20 and if you want editing then will need to use unionfs with mdmfs. tmpfs=20 cannot be used for this as it does not yet (to my knowledge) support unionf= s. =20 > My question is, how does one compile a root filesystem into the FreeBSD > kernel? =A0 Personally I wouldn't recommend taking the approach you want to do. There = is=20 simply an easier way. Just load the fs image as a kernel module (sort of).= =20 You get the same effect with more flexibility. (I'll explain below). > When mounted, I want this root filesystem to run entirely in=20 > memory with no other backing store (not even a readonly flash disc nor > other backing media such as DVD/CD).=20 This is do-able. I've created a CD that ejects it self when loaded=20 completely. (I thought it was cool :-)) > The standard FreeBSD DVD install disc=20 > uses just such a root? =A0(Though seems to rely heavily on the rescue > binaries being on a read only filesystem backed by the install DVD?)=20 Can't comment, haven't used the FreeBSD CD/DVD's for years (since 6.0) > I'm=20 > still trying to reverse engineer how that was done, without much luck. Is > there a place/documentation I should be finding? =A0PicoBSD, NanoBSD, NFS > root diskless systems... all tantalizing close, but not the same thing > (read only roots backed by media other than memory). The root filesystem > I'm wanting would presumably be in some conceptual sense similar to > initramfs in Linux land, if that helps explain what I'm trying to achieve= =2E =20 I'll give you a quick tutorial below (if you need further help please let m= e=20 know). > =A0In fact I have a Linux distribution which consists of a single giant > kernel image and when boot, runs entirely in memory, the kernel in fact > can't read filesystems other than tmpfs because no filesystems are compil= ed > in. =A0 I think you are getting some concepts confused here. =20 > It appears all of this won't be possible in FreeBSD (looks like ufs is=20 > required) but it appears I can get close to this. Indeed, I'd love a way > for the root filesystem in FreeBSD to be of type tmpfs, again similar to > what is possible on the Linux side, though I'm much less concerned with t= he > type of filesystem (it just needs to be compiled into the FreeBSD kernel > and needs to be a memory backed filesystem when it mounts, no other backi= ng > store). Thanks in advance! Ok, onto my explanation: my understanding is that you want to have some typ= e=20 of FreeBSD based system that is loaded completely into RAM. Once loaded (a= t=20 boot time) this system should have no reliance on any medium (other than=20 RAM). This system, once loaded, should behave the same as if it were backe= d=20 by a hard drive (except the statefullness after reboots). i.e. the=20 filesystem should be editable. =20 This is of course very possible. =20 STAGE 1: The filesystem In order to have the system in memory one needs a delivery method. As=20 mentioned before this is achieved using a MD device. =20 MD's can have three types of backing, a vnode (aka file, on a CD/DVD or har= d=20 drive), or memory (purely in memory, AFAIK no swapping out) and swap (same = as=20 memory except my get swapped out). Ignoring the subtle difference between= =20 memory and swap, swap is better. Technically the forth is preload but this= =20 is the same as memory but done by the loader. See md(4) for further detail= s. =20 Now, MD just imitates a hard drive, one still needs the data to put there. = =20 Any filesystem will suite this purpose. My preference is UFS but ISO9660=20 works just as easily (other options are not so easy but still do-able). =20 Now, to create the filesystem, just install your system into a folder. e.g. # su - # mkdir /tmp/world # cd src; make world kernel distribution DESTDIR=3D/tmp/world # cp /path/to/packages /tmp/world/tmp # chroot /tmp/world sh -c 'cd /tmp ; pkg_add *' # rm -rf /tmp/world/tmp/* # cat > /tmp/world/etc/fstab < _EOF proc /proc procfs rw 0 0 tmpfs /tmp tmpfs rw 0 0 _EOF * Now, edit /tmp/world as you require to make it work as you want (the easi= est=20 way is to create a Flash stick [as per my script], edit the system live and= =20 then copy all changes across). * STAGE 2: The filesystem image *** For UFS *** # makefs /tmp/world.ufs /tmp/world # MDDEV=3D$(mdconfig -a -t vnode /tmp/world.ufs) # tunefs -L ROOTFS /dev/$MDDEV # mdconfig -d -u $MDDEV *** For CD9660 *** # mkisofs -quiet -sysid=20 =46REEBSD -rock -untranslated-filenames -max-iso9660-filenames -iso-level=20 4 -volid DragonBSD -o $WORKDIR/DragonBSD.iso -volid=20 DragonBSD -o /tmp/world.iso /tmp/world Now, since these images are often much larger then required I prefer to=20 compress them. This allows more programs to be added to the image and it=20 takes up less memory during runtime (not to mention faster load times). =20 [I assume UFS option, do the appropriate for CD9660 option] # mkuzip -s 8192 -o /tmp/world.uzip /tmp/world.ufs STAGE 3: Loading the filesystem image Now you have an image that can be loaded on boot, to do so add the followin= g=20 to loader.conf # cd /path/to/boot/system/image # cat >> boot/loader.conf < _EOF rootfs_load=3D"YES" rootfs_type=3D"mfs_root" rootfs_name=3D"/boot/world.uzip" _EOF # cp /tmp/world.uzip boot/ Now, to inform the system that you want it to boot off the memory system # cat >> boot/loader.conf < _EOF vfs.root.mountfrom=3D"ufs:/dev/ufs/ROOTFS" _EOF STAGE 4: Making the Live System editable Now, to make the whole system editable (everything) is quite the challenge = and=20 requires a change in the way the previous stages are done. The concept is= =20 simple though. First: Because the filesystem was compressed (using mkuzip), it cannot be written = to. =20 If the system were not compressed and extra space was allocated to the UFS= =20 image then it can be editable. Even the extra size at load time can be=20 compensated for (since loader supports compressed modules [both gzip and=20 bzip2] however you will be running the full image uncompressed in memory. = It=20 is faster but much more expensive. Just to give you an idea, I have gotten= a=20 700MB system to boot and run off a mini CD (210MB) and a system with 512MB = of=20 RAM, using the compressed approach with everything editable :-). =20 To do this approach requires some changes to stage 2. Basically, after=20 completing the approach for UFS image do the following # EXTRA_SIZE=3D32 # SIZE=3D$(($(du -m /tmp/world.ufs) + EXTRA_SIZE)) # dd if=3D/dev/zero of=3D/tmp/world.ufs count=3D$SIZE bs=3D1m # NB, use ze= ro to allow=20 for compression # MDDEV=3D$(mdconfig -a -t vnode /tmp/world.ufs) # newfs -L ROOTFS -o space /dev/$MDDEV # mkdir /tmp/btstrp # mount /dev/$MDDEV /tmp/btstrp # (cd /tmp/world; tar -cf - .) | (cd /tmp/btstrp; tar -xf -) # umount /tmp/btstrp # mdconfig -d -u $MDDEV Next, DO NOT compress the image with mkuzip, instead do: # gzip -9 /tmp/world.ufs This requires either geom_uzip loaded or compiled into the kernel. and, instead of the first part of stage 3 do # cd /path/to/boot/system/image # cat >> boot/loader.conf < _EOF rootfs_load=3D"YES" rootfs_type=3D"mfs_root" rootfs_name=3D"/boot/world.ufs" _EOF # cp /tmp/world.ufs.gz boot/ NOTE: this approach cannot be done using cd9660. The second approach, the one I prefer requires a double boot image (one ins= ide=20 the other), where the one acts as a boot strap, mdconfig and mount's the=20 embedded second image, creates a editable fs using mdmfs and unionfs it ove= r=20 the second image. =20 This is done through using # cat >> boot/loader.conf < _EOF init_script=3D"/chroot.sh" init_chroot=3D"/base" where /chroot.sh basically does: mount -o ro /dev/$(mdconfig -a -t vnode -o readonly -f /world.uzip).uzip /b= ase mdmfs -s 32m md /tmp mount -t unionfs -o noatime -o copymode=3Dtransparent /tmp/base It would be very nice to add unionfs support to tmpfs but not yet :-(. The= =20 second approach I have not described fully, it is quite a bit more involved= =20 than the first but has great benefits, memory wise. If you want more detai= ls=20 about this approach please let me know. =20 I've created a set of scripts that are designed to create LiveCD/DVD/Flash = of=20 =46reeBSD. There are three cd9660 images that it produces: 1) CD backed live system (using compressed ufs image) 2) Memory backed live system (using compressed ufs image) 3) CD backed live system (no compression). And one Flash memory based image: 1) Flash based memory (using compressed ufs image and perpetual state overl= ay)=20 [similar to option 1 above except the changes are permanent). =20 If you would like access to these scripts please let me know and I will gla= dly=20 forward them to you. Also if you have any questions or want further=20 clarification please ask. =20 Regards, David Disclaimer: The commands may be incorrect but the procedure has been tried = and=20 tested. =20 --nextPart1333544.9sYBSKDk9c Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAknZERAACgkQUaaFgP9pFrLsjgCfd0nMbBs0SL1F9re/ygjZnggM TWQAn2ZyOWhyz0SsyRoOTlG/oeYzFrNS =if6I -----END PGP SIGNATURE----- --nextPart1333544.9sYBSKDk9c--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200904052214.08866.naylor.b.david>