On Fri, Apr 13, 2001 at 11:46:43PM -0700, Ross Harvey wrote:
> Delivered-To: netbsd-users@netbsd.org
> Date: Fri, 13 Apr 2001 23:46:43 -0700 (PDT)
> From: Ross Harvey <ross@ghs.com>
> To: netbsd-users@netbsd.org, smb@research.att.com
> Subject: Re: making bootable rescue CD?
> Precedence: list
> 
> > From: Steve Bellovin <smb@research.att.com>
> >
> > I decided it would be good to have a bootable rescue CD -- one that had 
> > all of /bin, /usr/bin, etc.  I wrote a script that created the file 
> > system image that I wanted, then -- following the instructions in the 
> > bootable CD How-To -- I ran mkhybrid.  Here I ran into my first 
> > problem:  I needed a boot image.  My attempt to compile from source
> > failed (no, I don't know why), so I picked up boot-big.fs from from the 
> > 1.5 distribution tree on ftp.netbsd.org.  And it did indeed produce a 
> > mostly-usable CD.  But...
> >
> > I was rather surprised, when it booted, to find myself in sysinst.  I 
> > assume that this is some attribute of boot-big -- is there a way to 
> > make that not happen?  I also found that root was /dev/mcd0a, which 
> > isn't what I wanted -- I wanted /dev/cd0a to be root, so that /bin, /
> > usr/share/man, etc., would be where they should be.  (I bypassed that 
> > operationally via 'mount -t cd9660 /dev/cd0a /mnt' and 'chroot /mnt'.)
> 
> When we build boot images, the kernel we put on it has an internal
> ramdisk filesystem, the idea being, it doesn't depend on anything
> external. You ended up with this ramdisk root and in sysinst because of
> 
> 	src/distrib/i386/floppies/ramdisk-big/*, calling sysinst is:
> 	src/distrib/i386/floppies/ramdisk-big/dot.profile
> 
> and because of the MEMORY_DISK* options in:
> 
> 	sys/arch/i386/conf/INSTALL
> 
> (If you look carefully at your rescue FS, I think you will see that every
> /bin and /usr/bin program has the same inode number, thanks to a remarkably
> evil hack known as crunchgen(1).  And if you were on NetBSD/alpha, you
> could boot from a kernel DIRECTLY on the CD filesystem, but that's not
> netbsd, it's because the firmware is different. Since you mentioned
> "boot-big", I guess you are on i386. Anyway, you wanted something else...)
> 
> If you just type 'boot -as' at the 386 boot monitor, then the standard
> install kernel (off your boot-big) will ask for its root (tell it cd0a, of
> course) and it will stop in single user.
> 
> The INSTALL kernel makes a fine rescue kernel, but if you want to depend
> on the CD, then your existing kernel binary or GENERIC should work fine,
> maybe better.  If you want the root mount to happen automatically, cp your
> kernel or GENERIC config to, say, WHATEVER_CD, and patch it like so:
> 
>     -config         netbsd  root on ? type ?
>     +config         netbsd  root on cd0a type cd9660
> 
> Now you need to make a filesystem, put the kernel on it, and run
> installboot(8) to make it bootable. You can do this with either a vnd(4)
> like src/distrib/i386/* does, or you can use a real floppy. You might test the
> floppy by itself before burning any CD's, if it can't boot as a floppy it
> can't boot on a CD.
> 
> > My next problem is that I would like to have /tmp as an mfs file 
> > system.  But where can I mount it?  I may not have a /dev/wd0b (and, in 
> > fact, I did not when I test-booted the disk on a laptop that has only a
> > n EvilOS2000 partition).  /dev/cd0a is busy, and there is no disk label 
> > on /dev/cd0d, for example.
> 
> You seem to already be aware that it only wants a disk to reuse the label,
> as any label will do. So do the mount the "pure" way with mount_mfs -T.
> 
> If you want to do anything really fancy, consider a custom hack to init(8).
> It shouldn't be necessary, but as an example see code for booting off a
> MSDOS filesystem. No device nodes, but we need /dev/tty, /dev/wd*, etc.  We
> can't even do console I/O without device nodes. What to do? The answer is:
> it mounts an mfs and runs MAKEDEV from within init(8). Kind of cute.
> 
> // ross@netbsd.org

There seems to be some good ideas here. If anyone is succesful with this approach or another this would be a good thing to add to the FAQ in my opinion.