From owner-freebsd-doc Thu Dec 16 17:52:44 1999 Delivered-To: freebsd-doc@freebsd.org Received: from blaubaer.kn-bremen.de (blaubaer.kn-bremen.de [195.37.179.254]) by hub.freebsd.org (Postfix) with ESMTP id C87D41574D for ; Thu, 16 Dec 1999 17:52:25 -0800 (PST) (envelope-from nox@saturn.kn-bremen.de) Received: from saturn.kn-bremen.de (uucp@localhost) by blaubaer.kn-bremen.de (8.9.1/8.9.1) with UUCP id CAA16891 for freebsd-doc@FreeBSD.ORG; Fri, 17 Dec 1999 02:49:32 +0100 Received: (from nox@localhost) by saturn.kn-bremen.de (8.9.3/8.8.5) id CAA00999 for freebsd-doc@FreeBSD.ORG; Fri, 17 Dec 1999 02:35:48 +0100 (CET) From: Juergen Lock Date: Fri, 17 Dec 1999 02:35:47 +0100 To: freebsd-doc@FreeBSD.ORG Subject: faq entry about booting an existing system from floppy Message-ID: <19991217023547.A748@saturn.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.7i Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As a followup to the `easyboot far into disk' thread on -stable, here is that faq entry about the subject. I haven't done FreeBSD docs before so there may easily be something wrong with this... I'm not subscribed to -doc (should i?) so please Cc any comments to me. And my ooold TeX installation apparently needs an update so i was only able to look at the html output. Index: book.sgml =================================================================== RCS file: /home/cvs/cvs/doc/en_US.ISO_8859-1/books/faq/book.sgml,v retrieving revision 1.25 diff -u -u -r1.25 book.sgml --- book.sgml 1999/11/25 09:08:54 1.25 +++ book.sgml 1999/12/17 00:33:38 @@ -1473,6 +1473,7 @@ + I get a ``panic: cant mount root'' error when rebooting the system after installation. This error comes from confusion between the boot block's and the @@ -1527,6 +1528,226 @@ + + + +How do I boot an existing FreeBSD system +from a floppy/CDROM, for example when only the kernel or loader is +damaged, something has killed the boot manager or the slice +with the root filesystem despite all warnings ended up on a too +high position on its disk to be accessible for the BIOS? + +This method works with the three-stage loader thats now in +3.x, not sure about -current. You should be able to boot older +systems in this way too if you make a custom boot floppy with your +older kernel. This _may_ also help as a workaround if you have a +``geometry'' problem but i don't have such systems to test. +You can do it ``manually'' with just the installation +kern.flp for the version of the system you +use, or you can make a custom floppy and put your own kernel on it +and have it boot automagically. And if the box in question doesn't +have a floppy drive or you just want to boot a little faster, you +could even put that image on a CD... If the root disk is invisible +to the BIOS, like when its on a supported but BIOS-less SCSI +controller you need a small patch to the loader (see +this message +in the mailing list archive, you can replace the loader on the +floppy just like you can replace the kernel), or if you make a +new kernel you could also use the "-a" boot flag +but then you'd still have to be at the console for every boot to +type the root device to the kernel. (If you wonder why the BOOTMFS +kernel on the original kern.flp doesn't work +with "-a": for some reason it has + +config kernel root on wd0 + + +instead of something like + +config kernel swap generic + + +which would be needed to allow the "-a" flag to work. and of course +if you do use this you can omit the "lsdev" and "set rootdev" parts +below.) + +First the ``manual'' method: + + + Boot the floppy as usual, but leave it in the +drive when it asks for the mfsroot.flp (ignoring +the error), the mfsroot image would only be in the way for what +you will be doing. + + + When the Booting ... in x seconds... +countdown comes up interrupt it (like, hit the space bar) to get at the +loader's +prompt. Now find out its idea about where the partition with the +root filesystem is: do a + disk0s4a:> lsdev +and note the hard disk partition with ends with `a' (not the one +on disk0 which is the floppy). If there is more than one disk with +a `a' partition the root filesystem is usually the first, but not +necessarily. (If you have a backup of the +/etc/fstab look there, otherwise its most +likely a fresh install and you should know. :) If the BIOS didn't +see the root disk at all either fiddle with the hardware/BIOS until +it does (if its a SCSI disk sometimes changing the ID to 0 helps) +or see the comments about the patched loader or the "boot -a" +flag above. + + + Type + disk0s4a:> set rootdev= +followed by the loader's name for the slice with the root you just +noted above, with a trailing `:' (important). If you use the +patched loader and the root is on a disk the BIOS didn't see you +have to guess this value (numbering starts above the last disk +the BIOS saw, with the patched loader you can also just use 0 for +the disk number if you set the root_disk_unit +variable too, see below. The slice number you have to know or +check with sysinstall, well actually you can also omit it but then +you may find you have to take it out of the root entry in the +fstab too before you'll be able to go +multi user.) And if the BIOS didn't see the disk you also have +to set the new root_disk_type variable, like + disk0s4a:> set root_disk_type=da +if its a SCSI disk or + disk0s4a:> set root_disk_type=wd +if its IDE. +After that (in most cases, see below) you will be ready to do the + disk0s4a:> boot, +optionally followed by any of the usual flags listed in the +boot(8) +manpage. Like "-c" to invoke userconfig (actually as you will be +booting the installation kernel (BOOTMFS) it will ask about that +itself anyway, unless you have already replaced the kernel on the +floppy), remember any userconfig script that you or sysinstall +might have created is obviously now unavailable. If the disk(s) +have been moved from another system/controller/channel/SCSI ID +order you may also want "-s" to be able to fix the +fstab before going multi-user. Of course, +usually you'd then end up in single user anyway when the mount of +one of the moved filesystems fails, but if there is more than one +disk and you're especially lucky it may end up just mounting things +wrong instead... Also use this ("-s") when you test this with a +kernel on the floppy that belongs to a newer version than the +installed system (like, when you want to make a boot floppy for an +old system that didn't yet have the three-stage loader), it should(!) +still be able to run the /bin/sh but other +things will most likely fail. In this case don't go multi user +but run /sbin/reboot, or just hit reset at +the prompt for the shell (which won't cause an fsck run as nothing +has been mounted read/write yet), and then go on preparing a custom +boot floppy with your older kernel. (If you don't have another +system around to do it on try it in single user mode, or use +sysinstall's Fixit mode.) + + +If the boot fails with a ``cannot mount root'' panic +(and you didn't use the "-a" boot flag to type the root device +directly to the kernel in which case it was just wrong) then +you have been bitten by the problem described in the previous entry. Find the kernel's +idea of the numbering of the disk with the root on it (thats the +first digit after its da for SCSI or +wd for IDE device name, you can again check +the / line in /etc/fstab, +and these are also the names that sysinstall uses when you select +disk(s).) Then try the above again, only this time adding a + disk0s4a:> set root_disk_unit= +followed by this number before the final + disk0s4a:> boot +command. +Now for the custom boot floppy: + + +dd the +kern.flp image to another (formatted) floppy, +then mount it (no options needed, its plain vanilla ufs). +If you want to use a different kernel than the BOOTMFS on the floppy +(which is a bit limited as it needs all the possible devices and +there isn't too much space on a floppy) then copy it to somewhere +like /tmp and if its been built with +-g strip the debug symbols: + &prompt.root; strip -g /tmp/kernel +btw you should still be able to do debug crashdumps then, the debug +symbols are only needed in the copy of the kernel you give to the +debugger. Finally gzip it and copy it over the one on the mounted +floppy. + + +Edit the floppy's boot/loader.rc: +take out anything having to do with the mfsroot image, and +replace it with the set rootdev and any +set root_disk_type and/or +set root_disk_unit commands you just used above. +If you need a userconfig script then put that on the floppy too +and add a load -t userconfig_script command +with its filename. Btw the userconfig settings of the running +kernel can also be retrieved with +kget(8) +so if you are going to use the running kernel and its settings +on the floppy you can generate it that way too. + + + u(n)mount the floppy, flip its write protect +tab just in case, reboot, and try it out. + + +And if you do have to make a boot CD: A good candidate is +probably the ``live fs'' one, then you have it right there should +you need the ``Fixit'' mode. (Just boot with the original +install floppy pair and select Fixit and CD then. Well you could +probably also use the boot.flp image as your +boot floppy image if you replace the kernel and copy the mfsroot +image from the mfsroot.flp and then set rootdev +back to disk0 and load the mfsroot image by hand +to get to sysinstall... Of course if you don't have a 2.88M floppy +drive you'd have to use a +vn device +to prepare it then. And possibly build a new kernel first as vn +isn't in BOOTMFS or GENERIC.) +But first (if the machine doesn't already have two floppy +drives) you need to know if the BIOS maps the (real) floppy +as drive B: when booting a CD because that will change the +loader's numbering of the disks... (well unless you use the +patched loader and have both root_disk_type and +root_disk_unit set in which case the loader's +numbering doesn't matter anymore.) If you don't know you can boot +any recent FreeBSD installation CD and look at the loader's startup +messages. (And if you don't have one you could take just the +boot.flp image and make a bootable CD from +that...) If the BIOS does map the floppy as B: then you'll have +to adjust the rootdev value in the +loader.rc of the floppy image that will go on +the CD, all hard disks will be numbered one higher for the loader +then. +To create a bootable CD (image) use +mkisofs +with the "-b" and "-c" flags (and probably also "-R" for Rockridge. +mkisofs is +in +ports, if you prefer you can also use it with a GUI frontend +like gcombust, also in ports). +What you then use to actually write the CD doesn't really +matter, as long as it can be told to take an already prepared +.iso image file instead of creating the +filesystem itself. (``Other'' OSes usually haven't heared about +unix-like file permissions and don't know how to create a CD +filesystem with Rockridge extensions, which you want at least for +the live fs one.) Of course you _can_ do it on FreeBSD too, see +for example the cdrecord +and gcombust +ports, or try the wormcontrol +stuff if you're one of the unlucky ones whose CD writer isn't +SCSI. -- Juergen Lock (remove dot foo from address to reply) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message