On Sun, 11 Aug 2002, Ray Olszewski wrote: > So, if this line does actually work the same way as LILO, that entry passes > to the kernel the instruction to use /lsh as init. You need to supply a > full path relative to root, and since you've told it to use /dev/fd0 as /, > this is the full path. > > The complicating factor here is that you are doing a two-step boot using > initrd. What I don't know is how append= arguments interact with the initrd > boot procedure. Perhaps someone else will be able to address this. > > Sorry I can't tell you more. > > Oh well, just one more thing -- the "initrd=initrd.img" argument tells the > kernel to look for a file called "initrd.img" on the boot device and use it > as part of the boot/init process. I'm assuming that when you said you > copied "initrd.msg" to the floppy, you meant to write "initrd.img". If I've > assumed wrong, then try adding the file initrd.img to the floppy. > > PS -- I notice after sending this message that you'd misaddressed the Cc:. > I'm resending it with the list correctly copied. > > At 04:08 PM 8/11/02 -0400, Haines Brown wrote: > >Olszewski on Sun, 11 Aug 2002 07:34:51 -0700) Subject: Re: boot floppy > >(mkbootdisk) BCC: [EMAIL PROTECTED] References: > ><5.1.0.14.1.20020811072603.0208e950@celine> > >--text follows this line-- > >Ray, > > > >Thanks, but no progress yet. I used dd to copy to an unmounted > >ext2-formatted floppy the files created by mkbootdisk: boot.msg, > >initrd.msg, ldlinux.sys, syslinux.cfg, and vmlinuz. I also copied lsh
You can't do this and expect it to work. Well, you could, if you really know what you are doing. If you want to make a rescue floppy yourself, the easiest way is to make a filesystem on the floppy and mount it. mkinitrd mounts a file on a loop device, IIRC. You could do something similar if you must use dd on a raw floppy. vmlinuz, being the last file copied to the floppy, overwrites the other files, unless you used options to dd you didn't tell us about. > >(Little Shell, which I can run and get a "C" type prompt). The > >syslinux.cfg files was edited as follows: > > > >label linux > > kernel vmlinuz > > append initrd=initrd.img root=/dev/fd0 init=/lsh > > > >I stuck the diskette into a (SCSI) Windows machine, and after the > >machine's SCCI BIOS loaded, the diskette is accessed and I get: > > > >Loading....................................................... > >Unpacking. Loading kernel > > > >Hoever, instead of starting lsh, it simply resets the machine and I'm > >in a boot loop. The kernel starts with a floppy bootloader, but there is no command line for it to read, so it attempts to mount the device that was on / when the kernel was compiled (you can change it with rdev) If you installed the kernel source, <linux>/Documentation/ has some good doco in initrd.txt and ramdisk.txt. > > > >Since runing ./lsh does lead to a prompt, I assume that binary is > >workable. Therefore, something may be wrong with the script > >above. I don't understand init, but why the forward slash in > >init=/lsh? You need an absolute path for init. The easiest way to make a rescue disk is to use the -r option of lilo. I guess maybe we can try if the lilo micro-howto is any use. > > > >Haines Brown > > -- > -------------------------------------------"Never tell me the odds!"-------- > Ray Olszewski -- Han Solo > Palo Alto, California, USA [EMAIL PROTECTED] > ------------------------------------------------------------------------------- Lawson ---oops---
lilo micro-howto version 0.0.6 <[EMAIL PROTECTED]> 29 February 2000 Use, distribute or change at your own risk. The definitive doco for lilo is the README file that comes with the lilo source. Usually there is also a copy in /usr/doc[s]/lilo*/README. It is long, boring, and very complete, really an excellent piece of technical writing. It and man bash are good reasons to be grateful less has a string search capability. If you don't have the README, I urge you to install the lilo source to get it. It really is fine doco. I can't think how to say it any better. To do anything at all fancy with lilo, what you must understand is that lilo.conf must describe the files you need to boot each image = and/or other = in terms of the devices and filesystem(s) _as they are at the time you run the lilo installer /sbin/lilo._ This includes the files named in image =, map =, initrd =, and install =, (you only need an initrd if you have to load a driver module to mount /, say if / is on a SCSI device and you use a modular kernel) and applies to making a good reliable lilo boot floppy as well: to make a lilo boot floppy you must [make a filesytem on the floppy] mount it, and copy your image, initrd, and /boot/boot.b files to files on the floppy that will be named in image =, initrd =, and install = parameters. You don't create the file named in map =, you just name the place where lilo will put its map file, so it can store a physical pointer to it in boot.b, likewise the boot sector itself must know where boot.b will be. Of course, you can make a lilo boot floppy by just copying a premade image to a floppy, but someone has to have done the work of installing lilo the right way, or it won't work. If you can understand that, you can do anything you like with lilo. As a side note, if lilo is installed into a partition boot record (boot = <partition device name>), another lilo installed in another partition or in the MBR can boot that linux partition as an other = OS instead of an image. You might find that an easier way to manage multiple linux partitions. PAY ATTENTION to the messages when running lilo. Any message other than Added <label> [*] is probably an abort message, and probably means lilo did not do anything. Look it up in the README. If it is a fatal error, you have to fix it and rerun lilo before you can expect a successful boot. Credit Richard Adams <[EMAIL PROTECTED]> for reminding me: If you have both IDE and SCSI drives on your machine, lilo has no way to tell which the BIOS thinks is first, and will guess the IDE. If the BIOS is set so the SCSI drives are first, you must tell lilo: disk = /dev/sda bios = 0x80 disk = /dev/hda bios = 0x81 This is an example only. Please use your own good sense. Pretty please? Pretty please with maple syrup? I have had reports that BIOS's that let you boot from other than the first hd act as if whichever hd was booted is the first hd, and has to be addressed as 0x80. In that case, if you boot FI /dev/hdb with the BIOS to start lilo, you will have to tell lilo disk = /dev/hdb bios = 0x80 Generally, I think this is a bad idea, but you may have some reason to do it, so you may as well know about it.
