Hello everyone,

i am trying to set up a linux workstation whose sole purpose in life is to create bootable flash cards (compact-flash).

currently, when i want to create a new bootable flash card, i have to power down the system, put the blank flash card in /dev/hda position, boot off a floppy, and the floppy boots to a linux partition that is located at /dev/hdb2. then, i can partition the blank flash card, create filesystems, copy all the files over, and then run lilo, and lilo writes to /dev/hda. then i have to power off the machine and remove my newly created bootable flash card and i can go use it.

what i want to do is eliminate all the powering up and down that is required to attach the flash card to the IDE bus. obviously, the answer is to use a usb flash read/writer to write my compact flash cards.

well, linux treats usb storage as a SCSI disk. this is no problem when doing the following: put the blank flash card in the usb writer, partition /dev/sda, create filesystem on /dev/sda1, copy all my files over. this works great.

then i have to run lilo to make it bootable. this is where the problem occurs. the SCSI subsystem gets a different geometry than the geometry that the machine gets when the flash card is used as the bootable IDE drive. basically, i am creating the bootable flash card as a SCSI drive (because i'm going through a USB writer), but then i'm using it as a bootable IDE drive. the geomtries never match and it never boots properly.

here are the things i've tried:
1. using the '-f' option to lilo to specify a geometry
2. using the '-g' option to lilo, and configuring the IDE geometry to be that which is reported when the flash card is a SCSI drive
3. using lba32 and linear modes of lilo

nothing seems to work to create it as a SCSI drive, but then allow it to boot as an IDE drive.

has anyone done this before and made it work?

thanks for your time!

-eric

This is really not my bag but I thought I'd share an idea.

If all the flash cards you're preparing are to have a similar configuration and used in similar environments/systems, wouldn't it be possible to create one such card and just copy the boot block using dd and then use that boot block as a master for all the cards you're creating later? I know this works when creating bootable CD-ROMs, but like I said, I know very little about these things.


Håkan

thanks for the reply!

actually, before we had the current set of scripts that created our custom linux disks using sfdisk, mke2fs, lilo, etc., we actually did use 'dd' as you suggested to just dup the disk. this works fine for flash cards up to around 512MB because the size of the drive is small. but these same scripts are also used to create bootable hard disks (instead of flash) sometimes, and when you 'dd' a 20GB drive, it takes a *long* time. also, 'dd' requires that the size of the original and target disk be identical (or if the target is bigger, you just lose the space).

-eric

Yes, but what I meant was actually just using dd to copy the boot block. As long as the device geometry is the same, the boot block would remain the same, right? So my thought was to use something like dd if=/dev/hdb count=1 size=512 of=~/bootblock.bin (where 512 is the size of the boot block, /dev/hdb is the card you want to rip from and bootblock.bin the output file) to rip out the boot block. You could then use dd to reverse this action and put the boot block on a newly created flash card to make it bootable.

See what I mean now?


Håkan

yes, i see what you mean. but from what i know of the way lilo works, it is not enough to just dup the superblock (boot block) to copy all the necessary bootstrapping information that lilo needs. i believe lilo actually stores a list of absolute hardware sector addresses on which the kernel image is located, so that the kernel can be loaded using only the bios. i don't think that this list of sectors is stored on the boot block itself-- i think lilo stores it elsewhere on the disk. perhaps someone who knows for sure can verify this?

also, duping the boot block only makes sense when the original (master disk) and target disk are the exact same size. we have to support 64MB, 128MB, 256MB, 512MB flash cards, along with supporting various size hard drives. the boot block contains partition information which obviously changes depending on the size of the target disk. i don't think there is a way to make a one-boot-block-fits-all.

-eric

heres mine, it took a while but it works really well.

I have a compact flash card reader which is device /dev/sda. i have my dist on /dev/sda1. the command line i use to load lilo is:

lilo -v -C lilo.conf -b /dev/sda

my mounted flash card (/dev/sda1) is mounted at /mnt/flash

disk = /dev/sda
bios = 0x80
boot = /dev/sda
LBA32
backup = /dev/null
map = /mnt/flash/map
# install = /mnt/flash/boot.b
append = "quiet"
password=justinlinux
restricted
image = /mnt/flash/bzImage
label = linux
root = /mnt/flash/dev/hdc1
vga = 0x317
read-only

The flash card boots up on my other machine on secondary master hence /dev/hdc1.

i will give your options a try-- you have a couple of options there that i haven't been using in my lilo.conf. but it doesn't seem all that different from what i've been doing.

out of curiosity, since that is working for you, what do you get when the flash is in the USB writer and you type
sfdisk -g /dev/sda

and then, what do you get when the flash is in the IDE secondary bus and you type:
sfdisk -g /dev/hdc

do they match for you? for me, they don't match.

also, how is your IDE geometry bios configured when the flash is in the IDE secondary bus?

thanks alot!

-eric

wow a big thanks to user Frustin...

i almost sh!t a brick when it booted. the lilo.conf option "bios=0x80" is what did it. after screwing with all the different geometry parameters to lilo for like 8 hours straight, i never thought about the fact that it might be saving the wrong bios driver number as a part of the lilo data.

hey this board rocks!

Like I said - I am not very aware of the inner workings of booting with Lilo. Sorry I wasn't much of help but I'm glad you got it fixed!


Håkan