Multi-boot from USB?

[Stryder Honeymonkey]

Hi,
I need the ability to boot to multiple kernels or OS's from a USB
drive without having to install anything on a system's primary fixed
HDD.

In other words, as a technician, I need the ability to walk up to a
powered-off PC, insert a USB key, power up the PC, and be presented
with a selectable list of things to boot.

I say "things" because OS is generally construed as Windows or Linux.
I'm thinking more along the lines of

1. BCWipe
2. Spinrite 6
3. Knoppix
etc...

I can make all of these things boot from USB key, but I'd need three
keys for the three examples above. I'm just looking for a way to
consolidate and pick-n-choose from a single key.

Any thoughts?
Much appreciated!!
'monkey

 

[Arno Wagner]

Hi,
I need the ability to boot to multiple kernels or OS's from a USB
drive without having to install anything on a system's primary fixed
HDD.

In other words, as a technician, I need the ability to walk up to a
powered-off PC, insert a USB key, power up the PC, and be presented
with a selectable list of things to boot.

I say "things" because OS is generally construed as Windows or Linux.
I'm thinking more along the lines of

1. BCWipe
2. Spinrite 6
3. Knoppix
etc...

I can make all of these things boot from USB key, but I'd need three
keys for the three examples above. I'm just looking for a way to
consolidate and pick-n-choose from a single key.

I have an USB key with Damn Small Linux, which boots via GRUB.
Grub can also boot other things, so additional partitions behind
the DSL partition can hold other bootable systems or system images.

Arno

 

[Eric Gisin]

You are better off using CD-RW, BIOS boot support goes back about 8 years.
There are mature tools for multiboot: http://www.nu2.nu/bootablecd/

USB boot support goes about 4 years back. USB has multiple access methods
(SCSI RBC vs transparent), drive geometry issues, that make it more problematic.

 

[Stryder Honeymonkey]

I have an USB key with Damn Small Linux, which boots via GRUB.
Grub can also boot other things, so additional partitions behind
the DSL partition can hold other bootable systems or system images.

Arno

Thanks Arno,
Someone else suggested grub as well. Have you actually tried booting
multiple images from usb/grub with success, or is your response based
on the theory that it should be possible?

'monkey

 

[Rod Speed]

You are better off using CD-RW,

Dunno, USB is a lot more convenient physically.

No reason to not have both, use the bootable
CD when the bootable USB key doesnt work.

BIOS boot support goes back about 8 years.
There are mature tools for multiboot:
http://www.nu2.nu/bootablecd/

USB boot support goes about 4 years back. USB has
multiple access methods (SCSI RBC vs transparent),
drive geometry issues, that make it more problematic.

But maybe about time to work out a config which does work now.

Particularly if say grub does provide a viable approach.

 

[Stryder Honeymonkey]

Dunno, USB is a lot more convenient physically.

Precisely why it's so appealing. Unless there's a way to attach a CDR
to my keychain and still fit it in my jeans pocket.

No reason to not have both, use the bootable
CD when the bootable USB key doesnt work.

Not geeky enough

But maybe about time to work out a config which does work now.

In my experience I've been able to USB-boot all of the images I've
needed from most modern PC's. It's just the boot manager piece that
eludes me... something that will allow me to throw it all on one key
and just pick one.

Particularly if say grub does provide a viable approach.

I'd like to see a proof-of-concept if it's out there.

'monkey

 

[Arno Wagner]

Thanks Arno,
Someone else suggested grub as well. Have you actually tried booting
multiple images from usb/grub with success, or is your response based
on the theory that it should be possible?

The second, I admit. I have DSL on a 128MB key and there is not
really room for much else except data.
But if DSL can be booted then Grub gets control successfully.
Of course whether you can get an image or OS to boot depends
also on the image/os. In an other experiment I could get Knoppic
to boot and run from an USB device, but that was some time ago.
I think there are instructions out there on how to do it.
I have no idea for the other things you list, since I do not use
them. I guess your main problem will be making the things run
from USB after initial boot.

Arno

 

[kothdvideo]

Dunno, USB is a lot more convenient physically.

No reason to not have both, use the bootable
CD when the bootable USB key doesnt work.



But maybe about time to work out a config which does work now.

Up to it?

 

[Rod Speed]

Up to it?

I dont do it that way myself, basically because I dont
charge around with just a USB with everything on it.

I might have a play with that if just using grub doesnt work.

 

[Antoine Leca]

In Stryder Honeymonkey va
escriure:

I can make all of these things boot from USB key, but I'd need three
keys for the three examples above. I'm just looking for a way to
consolidate and pick-n-choose from a single key.

A problem you may face is a motherboard/BIOS which would not admit to boot
from USB _except_ for the first partition.

It is said there are such setups out there. I have yet to encounter one, but
my experience with USB booting is rather short.

OTOH there are many many urban legends about USB booting, too.
This particular one looks like plausible (because it seems a number of BIOS
peeks at the MBR partition table on the flashdisk to figure things, e.g.
so-called USBFDD-emulation.)
It also looks bad design ("bug"), so it is possible you actually do not have
such a beast on the park you manage (that is, until one comes in.)


Debian suggests (http://www.debian.org/releases/stable/i386/ch04s04.html) to
use SYSLINUX on a single FAT16 to boot .ISO images; it might fit your needs
without having the above problem, just add entries in SYSLINUX
configurations (and .ISO).
Not tried personnally though.


Another thing I saw recently is ons should prevent write access to the boot
or root *USB* devices: I saw comments there is a low number of "guaranteed"
(thousand) writes for keyfobs.


Antoine

 

[Folkert Rienstra]

In news:[email protected], Stryder Honeymonkey va escriure:

A problem you may face is a motherboard/BIOS which would not admit
to boot from USB _except_ for the first partition.

A bios that reads the MBR code and then replaces it with it's own?
How viable do you think that is.

It is said there are such setups out there. I have yet to encounter one, but
my experience with USB booting is rather short.

OTOH there are many many urban legends about USB booting, too.

Right, and this will be one of them.

This particular one looks like plausible (because it seems a number of BIOS
peeks at the MBR partition table on the flashdisk to figure things, e.g.
so-called USBFDD-emulation.)

Well, how many floppies do you have with partitions on them?

It also looks bad design ("bug"), so it is possible you actually do not have
such a beast on the park you manage (that is, until one comes in.)


Debian suggests (http://www.debian.org/releases/stable/i386/ch04s04.html) to
use SYSLINUX on a single FAT16 to boot .ISO images; it might fit your needs
without having the above problem, just add entries in SYSLINUX configurations
(and .ISO).
Not tried personnally though.


Another thing I saw recently is ons should prevent write access to the boot
or root *USB* devices: I saw comments there is a low number of "guaranteed"
(thousand) writes for keyfobs.

Which obviously only applies to "the boot or root *USB* devices". Yeah, right.

 

[Antoine Leca]

In Folkert Rienstra va escriure:

A bios that reads the MBR code and then replaces it with it's own?

Never said it will be replaced.
A motherboard of mine (MSI 7032 "K8M Neo-V") allows only booting from
USB-FDD. If I enter a "normal" keyfob (one with a MBR), the (AMI) BIOS reads
it to locate the boot sector, and presents this (only) partition as a floppy
(DL=0).

No idea if this behaviour is common, or simply a bug or a shortcoming.

How viable do you think that is.

About whether the above behaviour is "viable" is a matter of point of view,
and I do not want to entrer this debate.


Antoine

 

[Folkert Rienstra]

In Folkert Rienstra va escriure:

Never said it will be replaced.

No, but that was the consequence of what you said.

A motherboard of mine (MSI 7032 "K8M Neo-V") allows only booting from
USB-FDD. If I enter a "normal" keyfob (one with a MBR), the (AMI) BIOS reads
it to locate the boot sector, and presents this (only) partition as a floppy
(DL=0).

So it is not 'booting' it. It is mounting it (ignoring the bootcode).

No idea if this behaviour is common, or simply a bug or a shortcoming.

It is not "booting".

 

[Antoine Leca]

In Folkert Rienstra va escriure:

So it is not 'booting' it.

When I insert a floppy into the drive, then turn the PC on, and when as a
result the PC is running the copy of MS-DOS which is on the floppy (and
nowhere else on the PC), I am saying "the PC is booting from the floppy."
And I expect everybody to understand that (well, almost everybody).

Now, when I insert a keyfob with MS-DOS, turn the PC on (with the relevant
BIOS options), and as a result the PC is running MS-DOS, I am saying "the PC
is booting from the USB keyfob." No difference here.

When it appears that the bootblock (the one with the BPB) was read using INT
13h DL=0, and so as a result MS-DOS shows the keyfob as A:, it is booting
using FDD emulation. Still "booting".

It is mounting it (ignoring the bootcode).

You mean the code in the MBR: yes, true. So what?

This is why I advised using SYSLINUX (which starting code resides in the
bootblock, not in the MBR), by the way.


Antoine

 

[Folkert Rienstra]

In Folkert Rienstra va escriure:

When I insert a floppy into the drive, then turn the PC on, and when as a
result the PC is running the copy of MS-DOS which is on the floppy (and
nowhere else on the PC), I am saying "the PC is booting from the floppy."
And I expect everybody to understand that (well, almost everybody).

Now, when I insert a keyfob with MS-DOS, turn the PC on (with the relevant
BIOS options), and as a result the PC is running MS-DOS, I am saying "the PC
is booting from the USB keyfob." No difference here.

When it appears that the bootblock (the one with the BPB) was read using INT
13h DL=0, and so as a result MS-DOS shows the keyfob as A:, it is booting
using FDD emulation. Still "booting".

Ok, I got it now (I think).
It's DOS that is ignoring the other partitions since
a floppy is emulated and it only emulates 1 floppy.

You mean the code in the MBR: yes, true.

Probably not. No boot without that code.

So what?

Well, that is what I consider booting, the first stage of it.

This is why I advised using SYSLINUX (which starting code
resides in the bootblock, not in the MBR), by the way.

But is still run/started from the MBR.

 

[Antoine Leca]

In Folkert Rienstra va escriure:

Ok, I got it now (I think).
It's DOS that is ignoring the other partitions since
a floppy is emulated and it only emulates 1 floppy.

Yes. Not only DOS BTW, it affects in the same way at any OS (e.g. Minix) or
any pre-boot environment (SYSLINUX, NTLDR, etc.) which does NOT take over
the USB stack built initially by the BIOS.
And my case is that _this_ stack considers the device to be a "floppy", only
considering the first partition entry.
While other (Windows, Linux, etc.) stacks will read the MBR from the device.

Probably not. No boot without that code.

Huh?
*No* MBR code will be executed when we are booting from a floppy, right? (or
with El Torito CD, behaves the same.) Well, we are in the same case here:
the BIOS does not execute the code in the MBR of the keyfob.


BTW, I believe the same behaviour might happen with more complete BIOSes,
which allows the choice to boot a USB device as "forced FDD emulation": the
MBR code on the USB device will be discarded, only the first partition will
be "mounted" by the BIOS, and then BOIS will execute the content of the
bootblock (1st sector on this partition).
Not checked experimentally that point, however.
Will research it if I found some time to do it, and a mobo/BIOS with the
required characteristics (so do not hold your breath.)


Note it is different from a keyfob formatted as "super-floppy" (that is,
without any MBR at all), which is still another case (still to encounter
one, but I know it might exist.)


Antoine

 

[Folkert Rienstra]

In Folkert Rienstra va escriure:

Yes. Not only DOS BTW, it affects in the same way at any OS (e.g. Minix) or
any pre-boot environment (SYSLINUX, NTLDR, etc.) which does NOT take over
the USB stack built initially by the BIOS.
And my case is that _this_ stack considers the device to be a "floppy", only
considering the first partition entry.
While other (Windows, Linux, etc.) stacks will read the MBR from the device.



Huh?

Well, that would be my response if it didn't.

*No* MBR code will be executed when we are booting from a floppy, right?

I don't think the bios cares. Dos (probably) will.

(or with El Torito CD, behaves the same.)

I will have to check that. Does it? Think not.
With El Torito the emulation type is in the data on the CD.

Well, we are in the same case here:
the BIOS does not execute the code in the MBR of the keyfob.

I see no reason why not. I don't think BIOS cares about the emulation
where booting is concerned. I don't think BIOS is even aware of partitions.

BTW, I believe the same behaviour might happen with more complete BIOSes,
which allows the choice to boot a USB device as "forced FDD emulation": the
MBR code on the USB device will be discarded, only the first partition will
be "mounted" by the BIOS,

Don't think so. Almost certain that bios is not aware of partitions.

and then BOIS will execute the content of the
bootblock (1st sector on this partition).

That is what the MBR code is supposed to do in the first place, so no conflict
with what I said.

Not checked experimentally that point, however.
Right.

Will research it if I found some time to do it, and a mobo/BIOS with the
required characteristics (so do not hold your breath.)

Does a sigh count?

Note it is different from a keyfob formatted as "super-floppy" (that is,
without any MBR at all),

MBR or bootsector, same (similar) functions. They don't bite each other necessarily.

which is still another case (still to encounter one, but I know it might exist.)

Just format your keyfob as a floppy?