Booting Linux from an internal IDE Zip disk?

[Richard Gordon]

That's an idea I hadn't considered. I'll have to think about it. The way we
have done
labs in the past requires students to be able to alter system files (e.g.
files buried in
/etc), but I might be able to cirumvent that requirement and have students
make the
changes to the network configuration after the system is booted.

As to how my system manages 2 hard drives and a CD-ROM, you have identified
a gap in my understanding of the BIOS. I suppose the problem is that the BIOS
does
not think of the CD-ROM or the Zip drive as one of its hard drives and so does
not
assign numbers to them (i.e. it uses 0x80 for hda, 0x81 for hdb, but does not
use
0x82 for CD-ROM or 0x83 for Zip) so it cannot boot from them. I suppose if I
actually installed additional hard drives the BIOS would assign them the
higher numbers.
It is basically not clear to me how Linux decides that my Zip drive is hdd and
that therefore
it should have bios number 0x83, whereas the BIOS knows nothing about drive
0x83.

I have noticed that the web sites for the latest versions of Award or Phonix
BIOSes claim
that they can boot from Zip disks. That doesn't explain to me how I should
identify the
drive that contains the root partition in lilo.conf.

Christopher Wagner wrote:

> Can the boot disk be read-only?  You may consider writing a set of CDs for
> students to boot from if the boot disk can be read-only.
>
> If your bios only supports two drives, how are you managing 2 hard drives
> and a CD-ROM?
>
> - Christopher Wagner
>
> -----Original Message-----
> From: Richard Gordon [mailto:gordon at SONOMA.EDU]
> Sent: Wednesday, December 19, 2001 2:06 PM
> To: talk at nblug.org
> Subject: Booting Linux from an internal IDE Zip disk?
>
> The short version of my question is this:
>
> Has anyone successfully booted Linux from an internal ATAPI Zip drive?
>
> The long version is this:
>
> In the computer labs at SSU there is a need to allow students to be root
> under Linux and to have a copy of Linux that they can configure and run
> on any computer in the lab. For this we want them to have Linux on a Zip
> disk.
>
> We have PCs with an internal 100MB SCSI Zip drive. Linux (weI currently
> use RedHat 7.1) can be installed on the disk and booted. (Yes, Linux is
> too large for a 100 MB Zip. The Zip disk holds all the directories
> except /usr which resides on the internal hard disk and is mounted by
> the version of Linux on the Zip.) The boot loader on the computer
> (either Windows NT or LILO) has an entry to boot the Zip drive. This all
> works.
>
> The problem is that Iomega no longer markets internal SCSI Zip drives.
> Anyway. we would like to switch to 250 MB drives and there never was an
> internal SCSI version of that drive.
>
> So, I am trying to get the same mechanism to work with an internal IDE
> (I guess now these are all ATAPI) drive. The computer I am using has two
> IDE drives and a CDROM, so once Linux is running it thinks the Zip drive
> is hdd. I followed all the same steps for this computer that I used to
> in the SSU labs. Here is the contents of lilo.conf that I used on the
> Zip disk:
>
> boot=/dev/hdd1
> map=/boot/map
> install=/boot/boot.b
> prompt
> timeout=50
> linear
> default=linux
>
> image=/boot/vmlinuz-2.4.2-2
>  label=linux
>  initrd=/boot/initrd-2.4.2-2.img
>  read-only
>  root=/dev/hdd1
>
> The Zip disk is mounted at /mnt/zip. When I issue the command:
>
> lilo –r /mnt/zip
>
> I receive a warning that drive 0x83 may not be available. Sure enough,
> when I try to boot this Zip disk it fails with an error 0x01.
>
> My understanding of what is going on is that the bios numbers its drives
> starting at 0x80. Lilo has to embed one of these number in the boot
> record to correspond to the location of the root. Since lilo.conf claims
> root is on hdd1, lilo embeds the number 0x83 (had is 0x80, hdb is 0x81,
> etc.) The problem appears to be that the bios cannot use any drive
> number above 0x81 (i.e my bios can handle only two drives).
>
> If all this is correct, then I need to locate a bios that can handle
> drives numbered higher than 0x81. If I cannot solve this problem then I
> will have to resort to one of the following less desirable solutions:
> using external SCSI drives, or booting from some other device (e.g. a
> floppy) and using the Zip disk to hold the file system but not the
> kernel image.
>
> So my questions are:
>
> 1. If my analysis is correct, is there a bios out there that will do
> what I need? What is it?
> 2. If I am not correct, where is my explanation in error.
> 3. Is there some other mechanism I haven’t thought of that will work?
>
> Thanks
> Richard Gordon