Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Technology

Booting from USB Drives? 49

GilesP asks: "With so many USB flash drives around (like the pendrive, Targus Go-Anywhere, and others), and with the demise of the floppy disk, I began to wonder if it would be possible to boot from a USB drive? So your BIOS is going to need to support booting from a USB device, but what else would be involved? I'm primarily thinking about Linux here, but other OSes would be interesting too. These devices come in a range of sizes from 8Mb up to 1Gb, so there is plenty of room to hold a Linux installation. Has anybody done anything like this?"
This discussion has been archived. No new comments can be posted.

Booting from USB Drives?

Comments Filter:
  • All you need to do is to tell your bios to boot
    from USB, as long as your bios allows this.

    Then just install a system on the pendrive,
    kernel and all, usb support compiled in.
    That should be sufficient. rdev/lilo as needed

    -Fallen
    • by GoRK ( 10018 ) on Monday August 05, 2002 @09:07PM (#4015642) Homepage Journal
      Ehrm, no.

      OK, here is the real answer.

      Some pc BIOS can boot off of an ATAPI device hooked to USB, such as an Iomega Zip drive or a compact flash card or somesuch; however, the implementations vary WILDLY on how this is accomplished. Booting from said devices involves much fakery in what is usually presented to a bootloader as either a virtual floppy drive or a virtual hard disk. The fakery involved in booting from USB is even more complicated than booting from a CD-ROM, for which there is (at least) a standard that most bioses somewhat support.

      Your bootloader (lilo, grub, etc.) can indeed bootstrap the kernel from a USB connected boot media; however, you will have to configure it differently based on which kind of device (floppy or HDD) your bios simulates for a USB boot. IE if your bios simulates a floppy drive, you'll have to tell lilo/grub/etc to load the kernel from the bios's floppy drive (here, bios calls to the floppy drive are rerouted to the usb device). Incedentally, this is the way CD-ROM booting works, but CD-ROM booting is MUCH simpler since an image file in a special area of the CD-ROM sits in for the virtual drive.

      Anyway, most USB booting bioses are going to be simulating hard drives anyway due to the size of most usb media, so all you have to do is set up lilo to boot from the first bios hdd (ie 0x80) and you're set there.

      Now on the subject of actually bringing the OS up - well that is the fun part. You can not (as the parent post said) just have "usb support compiled in" to make linux boot. USB doesnt exactly work that way in Linux. You can indeed have your usb controller driver, the usb mass storage driver, etc. all compiled statically with the kernel (not modules), but you're still going to have to start the hotplug daemon to get the setup functional to where you can use the connected device, and that's not going to happen without a root filesystem.

      So, you need an initrd. No problem provided you can get lilo or grub or whateverelse to find and load it. All your initrd needs to do is to load up your USB modules, mount your root fs off of usb mass storage (/dev/sda1 or whatever weird devfs name you use) and then pivot_root over to it. This is mostly equivalent to an initrd setup for something like a network booting system that uses NFS root or fibre channel or something like that. Any initrd HOWTO will cover setting up an initrd that loads modules and performs configuration to mount the root device that the kernel cannot do on its own.

      Sorry for the long ramble. Booting linux from USB is possible; however, it is not for the faint of heart. If you get it to work, it will probably not work for every motherboard that claims to allow usb booting. Any modern version of Windows will most not boot this way. (Well, technically you could load windows 3.11 or earlier in real mode like this, and maybe even windows 95/98 in safe mode)

      FYI, a good place to start looking is the HOWTO's that involve installing linux onto subnotebooks without internal CDROM or Floppy. A lot of these sites provide floppy images that can boostrap an installation system (ie linux) from a USB connected floppy or cdrom drive. The USB booting on these laptops is probably quite a bit more solid than the equivalent on any desktop motherboard.

      ~GoRK
      • by disappear ( 21915 ) on Monday August 05, 2002 @09:51PM (#4015787) Homepage
        So, you need an initrd. No problem provided you can get lilo or grub or whateverelse to find and load it. All your initrd needs to do is to load up your USB modules, mount your root fs off of usb mass storage (/dev/sda1 or whatever weird devfs name you use) and then pivot_root over to it. This is mostly equivalent to an initrd setup for something like a network booting system that uses NFS root or fibre channel or something like that. Any initrd HOWTO will cover setting up an initrd that loads modules and performs configuration to mount the root device that the kernel cannot do on its own.

        You missed a step:
        The initrd has to have about a one-second delay before you attempt to mount the drive from USB. This is because it takes a little while to detect it.

        If you make this one change (a little static binary that does 'sleep 1', essentially) to a standard Red Hat 'mkinitrd' ramdisk, you can indeed do USB if your BIOS supports it.

        I've done it. It was a @!#$% to debug the first time around: every time I dropped into sash everything worked, but if I didn't drop into sash it didn't. :-)

        • I've done it. It was a @!#$% to debug the first time around: every time I dropped into sash everything worked, but if I didn't drop into sash it didn't. :-)

          Ah, good times messing with free Unix systems. :)

          This is totally offtopic to the article. I just thought of a little story that was somewhat related to yours. Once, long ago (OK, 4 or 5 months ago) hacking the Linux VM for an OS class. An editing error (I cut some code to move it around, and ended up pasting it twice in two different spots) completely broke shared libraries (I think I may have disabled major portions of the copy on write semantics of fork, actually). Booting the system, even in single user mode, failed in fairly obscure way (init said "No more processes at this runlevel" and just sat there). Of course booting with init=/bin/sash worked very nicely.

          Your story just made me think about this, and I felt like 'sharing'. (Awww...)
        • I'm working on a run-from-CD system. To speed up testing, I'm doing the development by booting the kernel off CD and then using a USB disk for the root filesystem.

          Setting it up's pretty easy; just tell Linux that the root is /dev/sda1, insert the mass storage driver into the kernel, etc. No initrd or user daemon is necessary.

          However, the delay-before-detection bit me. USB seems to be initialised last, so by the time Linux tries to mount the root filesystem the USB bus is still powering up and Linux panics because it can't find the root. I fixed this by patching the kernel to have a 3s delay just before mounting the root filesystem. What I'd really like to do is to move the USB initialisation so that it occurs before the IDE initialisation; as detecting the IDE devices takes about three seconds anyway, that would give time for the USB stuff to come up without slowing down the boot process.

          • A better solution would be to change the "mount the root filesystem" step to wait and retry if root is not available.

            The dumb way is to use a sleep() with a maximum number of tries. The smart way is to keep trying until all drivers are done initializing (and drive access times out -- it can take a while in a configuration where the mount is initiated by a boot-time audio message through the speaker and someone has to insert a disk...), or at least all drivers which are relevant, which is pretty hard to determine due to so many possibilities, particularly if networking is involved.

      • What happens if you have more than one bootable USB device? USB assigns ID's to devices dynamically, so that sda1=drive1 is not ALWAYS true. USB polls for devices, and then waits for the devices to respond. Device ID's are handed out "first come, first served" basis. While that's great for cameras, where there software looks for a device with a particular media type in it's QMS response, a bios will not have the luxury of obtaining a particular QMS signature (again where there is more than one bootable usb drive) before it begins the boot sequence. Not in today's BIOS anyway.
  • Amptron (Score:4, Informative)

    by theNote ( 319197 ) on Monday August 05, 2002 @09:11PM (#4015651)
    I just bought a new Amptron MOBO and the BIOS supports this.

    The BIOS also has some network features built in, but I haven't checked them out yet.

    Go try one out, they're pretty cheap.

    • >I just bought a new Amptron MOBO and the BIOS supports this.

      Most likely they are lying to you.

      PCChips and Amptron are virtually the same company. PCChips is the company that uses fake chipset names, fakes CPU speeds in BIOSes, fakes cache settings in BIOSes, uses plastic cache chips, and pirates BIOS code.

      I wouldn't trust anything in a BIOS that's built for a PCChips board without a _lot_ of testing.

      Oh, I can provide references to these little facts, too. :-)
  • You could try a acomact flash to IDE interface in order to boot from CF. I know alot of people are using this for IOpeners. http://www.acscontrol.com/Pages/Products/CompactFl ash/IDE_To_CF_Adapter.htm?=AdSelect

    Cheers
  • by norwoodites ( 226775 ) <pinskia@ g m a il.com> on Tuesday August 06, 2002 @12:14AM (#4016252) Journal
    On macs with os X, the OF reads from the devices and then the os sends messages to the of to read particular blocks from the device to get the driver and then loads the drive and lets the driver take over. In fact this is how they do scsi and ide. The OF(BIOS) contains generic drivers to load the kernel and also to read from the device.
  • by Mustang Matt ( 133426 ) on Tuesday August 06, 2002 @01:30AM (#4016446)
    I know, stupid question, but I'm missing it.
    • OpenFirmware

      It's sort of the Mac equivilent of a BIOS if you like
    • by Tsk ( 2863 )
      Open Firmware [sun.com].
      Basicly it's a forth interpreter that initialises the processor, initialises various chips on the mother board and initialises PCI cards. It's avaiables on MacIntosh since the PPC switch and on sun Hardware.
      Booting from a USB drive on a mac would not be difficult you'de just specify the path of the system blessed folder, be it a linux, Open, Net, Darwin or Mac OS X system.
      • Actually its available ever since the switch to PCI from Nubus, which happened slightly after the PPC switch. 61xx, 71xx, and 81xx (and possibly others?) are Nubus based and do not have Open Firmware. Not intending to be nitpicky :)

        nwp
  • ... this could be a security risk like the Dreamcast Phone Home project. Just stick a USB drive into the back of a computer where someone is away on vacation and turn the monitor off. That's probably even more "hidden in light" than a dreamcast, plus it would get past efforts to clamp down on such attacks that involve allowing only certain MAC addresses.
  • Has anybody experience using these usb-stick with sun solaris on non-intel hardware? does it work?
  • Use a flash memory to IDE converter like this. [acscontrol.com]

    Then you realize flash memory costs more per MEG than hard drives per GIG and is SLOW.

    Skip the fancy stuff unless you are just looking for toys.

  • I have an IDE-CF bay, a PCMCIA-CF adaptor and a USB-CF adaptor. Now linux sees the CF in the USB adaptor as a scsi disk but the others are straight IDE.

    I cannot for the life of me get lilo to correctly install on CF when in my laptop, and then boot in another computer. The CF reports itself as the same CHS whether it is in my PCMCIA slot or in the final computer's primary master CF-IDE bay. I've tried linear, lba32, with and without compact.

    Example setup: install CF into PCMCIA adaptor, install adaptor into laptop. Laptop sees /dev/hde. mount /dev/hde1. /mnt/sbin/lilo -b /dev/hde -r /mnt. Lilo says it installs fine. umount, remove from laptop and place CF into CF-IDE adaptor on final computer. Boot. Disk is detected with same CHS as it was in the PCMCIA-CF adaptor but lilo will either say "LI" or "LI 0x01 0x01..." (0x07 is another common one.)

    According to the LILO documentation that's illegal command and invalid initialization. Fun. Boot from a floppy on the target machine, run lilo from there, all is well. Unfortunately that isn't an option for me in all cases.

    groups.google.com suggests that this is a longstanding problem with LILO (booting CF) but has no suggestions. Other than Grub which seems to be an excercise in bloat, has anyone got a solution to this?

  • This would be good enough, if it is possible.

    This would be enough for me , as an alternative to booting directly from the USB. Does anyone know if this is easier, or even possible? It would -seem- to be easier, since the USB driver and fs could be modloaded instead of needing to be statically linked.

    Anyone have any experience with this?

  • why not replace your floppy drive with an internal pcmcia or compact flash reader [emjembedded.com]? it would only take up a 3.5 bay in your computer, and it would be recognized as an ide device. this would make botting from it much easier, even with an older bios. this may be a problem if you are using a laptop, but for desktops this would be your best bet.
    • He was talking about *USB* drives!

      With your sense of humor why don't tell him that he could replace the USB drive with a normal floppy drive or IDE disk...

      Stupid, the matter som people are made of...

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.

Working...