What boot media to choose?

[Combuster]

Harddisk booting is not a viable option the moment you want to get out of a virtual machine.

Why not? Isn't stable HD handling pretty much a precondition for getting out of the VM? Either it's stable, then HD booting is an option. Or it isn't stable, in which case I don't want to get out of the VM.

Or am I missing something here?

Three things:
- People often don't want to touch their harddisks for safety reasons.
- Getting your OS installed on a physical harddrive requires an installation procedure of some sort. Configuring your OS on a remote harddrive requires an (existing) OS to do so, which means you have a rather tedious configuration cycle that's rather manual and long by nature - you need to boot a stable os, somehow get the image onto it, install it onto the harddrive, then reboot the machine. And if you happen to do an off write to the harddisk, you have to spend a few hours getting the "configuration" OS back into working state. Can you imagine how long your test cycle becomes?
- If you want other people to run it, they will want a removable medium.

[a5498828]

Of course HDD.
Put your os in its own partition, and jsut reboot. Let mbr code display choice if to boot your os or whatever ur using.

Unless of course you want to waste money (and more valuable time and patience) on burning cds...

[os64dev]

I would also prefer booting from HDD.
Modern BIOS's will map USB memory sticks as drives and you can probably select the boot drive at restart.

os64dev

[JackScott]

Unless of course you want to waste money (and more valuable time and patience) on burning cds...

I would personally just create an ISO image to use in an emulator, then every week or so burn it to test on a real machine, just to make sure it's still working on real hardware. There's really very few differences between emulators and real machines, so you just need to make sure that at the crucial hardware-dependent stages, that your operating system doesn't fall into the gaps.

In an ideal world, you'd have a multiboot-compliant bootloader load your operating system (because being multiboot-compliant is a very good thing). Then you configure your project and it's Makefile to generate a floppy image, an ISO image, and possibly a hard drive image; and do this every single time you run make. Then it becomes a trivial matter to boot from any medium. My first storage driver would be a RAM-disk, and then I would just add storage drivers for real hardware storage devices as I pleased.

[Velko]

At early stages of your OS it does not matter which boot media you use, assuming you make Multiboot $SOMEVERSION compatible kernel. As long as your bootloader (GRUB for example) can load it, you're fine. I do boot my kernel from CD (Oracle VirtualBox or QEMU), HDD (QEMU and dedicated test computer) , USB (if somebody is brave enough to let me do it on his/her computer) and direcly using QEMU's built-in bootloader. There's a small catch - most VM's have their own HDD image formats which may or may not be mountable on your host OS (to copy kernel images into). On the other hand - every VM knows what an ISO is and is able to boot from it. I'd vote +1 for CD here.

Later it's more about what's your root (UNIX'ly speaking), not boot media is going to be. It's when you're going to load some config files, kernel modules, userspace executables or whatever, from disk. There you choose, which device and file system you find easy/appealing enough. I went for HDD (in PIO, LBA mode) and EXT2. All in read-only mode for now.

Then you go to stage, when you're about to write to disk (disclaimer: I've never got to this stage). This is where CD's drop out (unless you're prepared for all the cdrtools' horrors). There's again a choice, if you're going to write back to your root filesystem or somewhere else. I think, at this stage You should acquired all the knowledge I'm talking about. Anyway, you got to be damn sure, about your partition driver, before you let it to touch something else.

[Chandra]

Unless of course you want to waste money (and more valuable time and patience) on burning cds...

There are things like CD-RW, which is there to save your wallet from running out of money.

There's really very few differences between emulators and real machines, so you just need to make sure that at the crucial hardware-dependent stages, that your operating system doesn't fall into the gaps.

I differ there. My personal experience suggests that emulators and hardwares are similar only in respect to code emulation, nothing more. I've lots of code that runs fine under an emulator but sucks under any real hardware you run. Nevertheless, your logic of regular testing on real hardware is appreciated.

[turdus]

I drop floppy and cdrom for the following reasons:
1. I do not know any computer nearby that has a floppy drive, and floppies are not produced any more.
2. I do not like cds, never did. I could never understand why to use el-torito and floppy emulation and things alike. That's lunatic.

So I turned it upside-down: I can boot my OS from any media that has lba bios support, regardless of media type and partitioning scheme. This way my bootloader is smaller, simplier (no motor fuzz, no chs calculation, no emulation etc.) and, nevertheless more compatible (eg. I can boot from usb-sticks, hdds, and possibly other future media as well as long as lba bios supports it).

Imho.

[smwikipedia]

I drop floppy and cdrom for the following reasons:
1. I do not know any computer nearby that has a floppy drive, and floppies are not produced any more.
2. I do not like cds, never did. I could never understand why to use el-torito and floppy emulation and things alike. That's lunatic.

So I turned it upside-down: I can boot my OS from any media that has lba bios support, regardless of media type and partitioning scheme. This way my bootloader is smaller, simplier (no motor fuzz, no chs calculation, no emulation etc.) and, nevertheless more compatible (eg. I can boot from usb-sticks, hdds, and possibly other future media as well as long as lba bios supports it).

Imho.

Hi, turdus,

I am very interested in the LBA BIOS support, especially the part "no motor fuzz, no chs calculation, no emulation etc.".

Now I am wondering:
- What preliminaries are required to use LBA BIOS?
- How to use LBA BIOS?
- Also, I am using VMware and Bochs, I am not sure whether they support LBA BIOS to interact block devices, say an ISO image or a USB disk?

I read from here http://en.wikipedia.org/wiki/INT_13H#IN ... Parameters that the driver index of the 1st HDD is 80H, so how to know the the driver index of CD-ROM or USB ?

Thanks.

[Brendan]

Hi,

Now I am wondering:
- What preliminaries are required to use LBA BIOS?

I'd assume "LBA BIOS" means a BIOS that supports the "IBM/MS INT 13 Extensions" BIOS functions, like this function.

- How to use LBA BIOS?

There's a formal specification called "BIOS Enhanced Disk Drive Specification", which is produced by Phoenix (in conjunction with a group of other companies). It should be easy to find a copy of this specification with a google search.

They're also listed in Ralph Brown's Interrupt list. There's a HTML version of this list online, and the "IBM/MS INT 13 Extensions" BIOS functions are all listed on the "Int 0x13" page - just scroll down until you get to "Int 13/AH=42h".

- Also, I am using VMware and Bochs, I am not sure whether they support LBA BIOS to interact block devices, say an ISO image or a USB disk?

They should - most OSs use these functions, as the older "int 0x13" functions are limited to 8 GiB (or less), and they are required by (and extended by) El Torito for "no-emulation".

I read from here http://en.wikipedia.org/wiki/INT_13H#IN ... Parameters that the driver index of the 1st HDD is 80H, so how to know the the driver index of CD-ROM or USB ?

Originally, floppy drives were numbered starting from 0x00 and hard drives were numbered starting from 0x80. For USB or CD-ROM emulating floppy or hard disk, the same numbering is used for the emulated device (and real devices are re-numbered to suit ). For e.g. an emulated hard disk on a CD-ROM would become device 0x80 and the real first hard disk would be shifted to 0x81 to make room. For "no emulation" CD, the device number could be anything - typically they're 0xC0 or above, but they could be anything.

The important thing is that you should never have a reason to care what the device number is. The BIOS tells you which device number you booted from (in DL) and you use that; and if you need to know more about the device you ask the BIOS (either using "Extended Read Drive Parameters" if supported, or the older "Read Drive Parameters" function.

Also note that using the "IBM/MS INT 13 Extensions" BIOS functions properly isn't necessarily as easy as it sounds - be careful of removable media like CD and USB (where the user can remove it during boot, and where it might be possible to lock the device to prevent this); and don't assume 512-byte sectors as CD uses 2048-byte sectors, and hard drives will probably shift to 4 KiB sectors one day (rather than "4 KiB sectors pretending to be 512-byte sectors").

It's also good idea to use ISO9660 for CD, and some other file system (or none) for hard disk. For USB (and hard disk too I guess), you can't really provide a partitioned generic USB image that everyone can download and use because you need to know the device geometry before you can create partitions correctly; and to get around that problem the easiest way is to provide an unpartitioned image. This means you may need many different boot loaders despite using "IBM/MS INT 13 Extensions" BIOS functions - one for "no emulation" CD that uses ISO9660, one for other devices that supports "MBR partitions", one for other devices that support "hybrid GPT partitions", one for other devices that aren't partitioned, etc.

In general, in my opinion, the entire idea of a single "one size fits all" boot loader is limited and broken. Even if there is only one boot loader initially; an OS's boot code should be designed with some abstraction, so that the OS itself doesn't care which boot loader was used (or what the boot device was), so that it's easy to write more boot loaders later to allow the OS to boot from radically different devices (including booting from network where there's no file system or sectors, and potentially including booting from EFI or other types of firmware).


Cheers,

Brendan

[andymc]

Hi Brendan

Sorry for reviving an older post, but I'm struggling with the best way for my boot code to indicate that the system is booting from USB.

In testing USB booting with my OS (Visopsys), I see that in the current configuration I'm using, the BIOS identifies the boot device as HDD 0x80, as mentioned.

When my kernel is launched after switching to protected mode, the OS loader gives it some structures of various hardware information provided by the 16-bit BIOS, including which device is the boot device, as a string (such as 'fd0', 'hd0', 'cd1'). What I'd like to do is to determine, in the OS loader, that we're booting from USB and pass a string such as 'sd0' (this would be the name of the first SCSI/USB disk in my running OS).

When booting from CD, there are extended int13 BIOS calls to determine whether CD emulation is enabled. Is there something analogous with USB?

I'd like to try and avoid having to write code in my kernel which tries to make guesses based on drive 'geometries' or by attempting to mount loads of filesystems looking for the OS root filesystem.

[andymc]

On reflection, I guess that utilizing some sort of signature (such as the available 'disk signature' space in an MBR) might be the most flexible method, and the least vulnerable to differences in BIOS behaviours, etc..

My OS loader could pass the signature of whatever device the BIOS says it's booting from, and my kernel could just cycle through its detected devices looking for that.

I guess maybe I just answered my own question but I'd still be curious to know whether there's some BIOS-provided indication of USB booting.