I installed Slackware 13.37 directly onto a USB flash drive. I already knew from previous experience that because the USB flash drive is /dev/sdg the LILO install would not be put on there correctly until I edit /etc/lilo.conf. I proceeded to let the lilo installer do what it will, which wrote on the /dev/sda MBR. I subsequently restored the MBR on /dev/sda from a backup I made before starting this (and in fact did this for the first 6GB which included the /boot partition). I then mounted the one partition on the flash drive, edited /etc/lilo.conf within there to change "boot = /dev/sda" to "boot = /dev/sdg". I did "chroot /mnt/sdg1 /sbin/lilo" and it seemed to install the MBR correctly. I rebooted and selected the USB flash drive and it came up OK. I rebooted and selected the hard drive and it came up OK (once with the USB drive present and once without).

I duplicated the USB flash drive to another just like it (the original one has a red color and the duplicate has a green color but they are exactly identical number of cylinders). I then modified a couple files on the green one to change the static IP address and the hostname. The duplicate booted up OK, too.

Now I moved to another machine of the same model. It also has Slackware 13.37 on its /dev/sda like the first machine does. I verified all is well by booting the hard drive, and it is OK. Now I boot from the red USB flash drive, and it comes up OK. Then I boot from the green USB flash drive and I get the error message "LILO - Timestamp mismatch".

Google searching found (among others):

http://www.nylug.org/pipermail/nylug...il/012199.html

which suggests that the timestamps on the bootloader stages are not as expected.

This doesn't exactly seem right. The first issue is why does it only affect the green duplicate and not the red original? I did not touch any files in /boot at all. I did not reformat or anything. It was originally a raw sector copy, so all the LILO parts should be exactly identical. So even if LILO was using bits of the hard drive, which is certainly a different hard drive on this separately installed second machine, if it's going to fail, it should fail for both flash drives, or not fail for both flash drives.

I'm getting to the point of hating LILO as much as I hate GRUB. I guess it's time to look at EXTLINUX or SYSLINUX (but I don't want to set up a FAT partition). I'm not switching to GRUB. That would just be inviting a whole other set of issues.

Anyone have an idea what LILO is doing here? Is there a way to make sure that LILO is accessing the flash drive ONLY (because these flash drives are supposed to be self contained rescue tools)?

Does 'lilo -r /mnt/sdg1' make a difference?

I don't have the means to test this setup right now, since it's done. I re-ran lilo on the duplicate, from the 2nd machine, using exactly the command I previously gave, and that fixed it (I haven't tested if I can now make a duplicate of that and work in the 1st machine since I don't have yet another USB flash drive of that size).

What I'm looking for is a way to guarantee things will work right which I can do when I originally set up LILO on an alternate device. And I'm still not sure that booting these USB flash drives does not involve reading something (like maybe the loader stage 2 or the sector index table) from the hard drive. In theory, the BIOS should have assigned drive index 0x80 to the USB device for the duration of booting. So every access to 0x80 by LILO should read the USB flash drive. But why it works on one machine and not on another (the hard drives are NOT sector duplicates, so they would have different files with different timestamps) suggests something it is getting something from the hard drive.

Unfortunately, these machines are mass produced compact boxes that make getting inside difficult. So unplugging the hard drive is not an easy option.

I find that both GRUB and LILO do "silly" things that I think a boot loader should not be trying to do. I do understand the complications involved between how the BIOS maps devices and how the OS does, and that this complicates systems where different OSes need to boot from different devices. I really don't need any of that, so all the jumbled I/O LILO does is not something I really need. But GRUB isn't any better. I ultimately need a simple boot loader that just loads everything from the one BIOS selected device at 0x80 and can't operate any other way.

This is one glitch in installing Slackware to other than /dev/sda. It still sets up LILO as if the install target device will be /dev/sda when it runs (and it might be if the objective involves switching devices around after install), yet it writes the MBR to /dev/sda on the current system. I'm not sure anyone can possibly get LILO to always work right for all the common scenarios.

Maybe this weekend I will have another look at EXTLINUX and see if the documentation has improved since the last time I looked at it. Otherwise, I might have to move forward to writing new sane bootloader.

Anyway, it isn't hard to work around this. I just need something that will boot, then I can chroot into the USB flash drive and re-run "lilo" and fix it. But, IMHO, boot loaders should strive to look for ways to bring the system up, not look for excuses to refuse to do so.

In case you don't know these...

http://www.plop.at/en/bootmanager.html
http://unetbootin.sourceforge.net/

HTH

The workaround was not hard. I had other things to do booting from (other USB memory sticks, and other DVDs). The concern is that LILO has a history of issues like this. I believe it is due to all the pieces it needs to do booting with, and since these pieces can easily be mangled, it has to do checksums more. And hence there can be excessive failure modes due to its excessive checking.

The problem I'm trying to solve is NOT "what to do if it fails" since I can deal with that. Instead, the problem to be solved is "how to set up LILO so this cannot ever happen" (assuming nothing comes in and modifies stuff after the fact). Simply taking a memory stick with a bootable system to another machine should NOT fail (for same types of machines). Simply making a raw sector duplicate of a memory stick and booting the copy should NOT fail.

The fact that device identification under Linux doesn't jive well with device identification under BIOS, is, of course, a major complicating factor for any boot loader. The simple case is still "load the kernel from the same device the boot loader came from" which will be device index 0x80 in BIOS calls. So a boot loader that just uses 0x80 solves that.

BTW, I have found unetbootin to be a frequent failure. One way to avoid a lot of these failures is to wipe off the target memory stick before using unetbootin. Wipe it to all raw binary zero, then make a new partition table and format a new FAT filesystem.

But this project is not about morphing a bootable CD/DVD into a bootable USB flash drive.

Plop's license is a show stopper.

I don't need a fancy boot system or boot manager. I need pure basics that will boot just the one OS it is connected to, which for now is only Linux. If a different boot loader is needed for possible future use of BSD, that's fine. I would just use whichever boot loader is needed. The boot loader only needs to boot the OS on the same device. I don't need for it to boot other OSes on other devices. Having a separate tool with a universal boot loader that can find OSes on other devices and boot them is fine and I could use one. But that isn't this project.

Tools that can build the IMAGE of a bootable flash drive, given a kernel and maybe an initrd/initramfs image or file tree, and include a root filesystem as a separate partition, is the ultimate goal. Since LILO wants to know the sectors where the files for the kernel and initrd/initramfs images are, that cannot be in the root filesystem. So if LILO is the boot loader for such a tool, it would have to build a separate filesystem in a separate partition as part of building the part of the image that preceeds the root filesystem.

The tools for LILO and GRUB are oriented around running their own program to store the bootloader onto the device. This project involves building an image which is later dd'd or copied, in whole, as raw, onto the target whole device. So I need to avoid running those tool commands, since they don't really know how to store the bootloader into a file.

Right now I'm dabbling with various pieces of the project without yet doing the whole thing. This is so I can collect all the issues as a "big picture" and make some decisions. It looks like GRUB and LILO won't be the bootloaders of choice. SYSLINUX or EXTLINUX might be. But that decision has not been made yet. Writying my own bootloader is not ruled out, yet, either.

Aha. Updates on further developments would be appreciated .

A subset of SYSLINUX looks like it might be usable for this. I will dig into SYSLINUX this weekend and try it out for regular booting, built from the latest released source.

What I ultimately want is a way to have a device, like a USB flash drive, where I can completely wipe off and replace the entire root filesystem, and it will always still boot up. Now, should it have the kernel and initrd in the root filesystem? If the answer to that is yes, then LILO has to be ruled out because actually running the lilo command to rebuild the map is not always an option, and even when it is, it does not always work right due to complexities that are more prevalent today than when LILO was designed, like where that USB flash drive is addressed (I'll leave the flaws of USB design for another thread). GRUB is very oriented around running their tools, and GRUB2 just made things worse. So it at least isn't an easy option. I did manage to hack GRUB1 to be usable for a related project a while back (a tool to morph Casper based bootable ISOs, such as Ubuntu, into flash drive images, without the problems of unetbootin, which wants the target device instead of generating a dd-able image). But that hack has to be customized and re-applied, and GRUB rebuilt, for each different image I build. While I do have a script that does that, that is just fundamentally the wrong way to go. So at this point GRUB (1 and 2) are out for the new project.

I think I'm going to do this in two partitions, keeping the concept of a /boot partition. I'll build up a small drive image with SYSLINUX loading from partition 1 (either flagged as the bootable one or hack its mbr.S to always choose number 1 instead of the flagged one). SYSLINUX should be able to work directly with "this" drive (e.g. the one the MBR is booted from, index 0x80 in BIOS) in all cases, regardless of where that drive will show up in Linux once Linux is up. So the SYSLINUX loader program, kernel, and optional initrd/initramfs should all be in partition 1. The FAT filesystem should work, but I may still go to ext2, anyway. The config would then direct the kernel to mount partition 2 as root. Later, I'll add an initramfs based pre-init program (early user space) to hunt for a root filesystem based on some complex logic I have in mind. Maybe it can even present a user choice menu (the kernel is running by then, so more can be done than possible in a bootloader using BIOS).

These bootloaders all are intended to give the end user a lot of options for booting many different OSes, at the expense of not being able to boot if things are not found where expected. They lean on the user to know where things are. But what I want is a portable self-contained system that can bring itself up for sure on any standard PC which has a BIOS that can boot correctly from the media the system is on ... and do so with the ability to readily change everything on it and have it continue to always work (as long as what you changed is itself workable).