Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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.
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).
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.
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.
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.