Booting Linux from an internal IDE Zip disk?

[David Cole]

Richard,
     You can definitely boot from a 10cent CD,
and have the files and folders you want to customize
(like var. and user folders and logs),
mounted on your zip.
Just like you mount different folders on different harddrives.
Linux doesn't handle CDs and Harddrives that differently,
other than Linux will error if it tries to write to the CD.

(Remember a script to copy these user folders onto
the zip if linux find the zip empty.
In that case I'd ask the user if he wanted the zip setup,
then have the script copy,
then go to a reboot to start over)

Think of it as the standard bootable distribution CD
with the user folders mounted on the zip.
Just like you can mount these folders on separate HDs.

It takes less time to manage a CD distribution.

I'd also consider instead a CD & diskette pair,  editing the linux to be as
read only as possible.  This would allow the student to use almost any
computer.

David Cole

----- Original Message -----
From: "Richard Gordon" <gordon at SONOMA.EDU>
To: <talk at nblug.org>
Sent: Wednesday, December 19, 2001 2:06 PM
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
>