(1) VMware car "read" an iso file and and fire up the kernel. One can't configure the boot loader inside to boot a system outside VMware or inside VMware, at least that is what I found. I suppose your definition of booting is different to mind.
(2) Grub legacy can read any partition that it supports including those filing systems in MS Dos/Windows, Solaris and BSD. For those systems it doesn't support, like NTFS, Grub boots its OS indirectly by chainloading its boot sector. It virtually cut and paste itself with the next boot loader.
Thus one can use Grub to display the Lilo's configuration and boot up that Linux without using Lilo.
syslinux is a light weight Dos-based bootloader designed to run on fat partitions. I haven't gone into Grub 2 because it has no documentation. All the Linux I have seen so far are based on Grub legacy.
(4) Grub is a general boot loader that can be used to boot any PC system. If a Truecrypt partition can be booted by a boot loader it is because that boot loader has been compiled with a Truecrypt driver. Grub does not have the *****ion to become a universal boot loader that can handle every filing system with every encryption. After all it is only a small boot loader suppose to pass the control to an operating system. It is not in a boot loader's scope to decipher the content of a encrypted partition. That job lies with the kernel.
I expect Grub to be able to boot the boot loader of an encripted partition but I have not worked with the Encrpt partition. The boot loader in the boot sector is always stored in binary pattern ready to be loaded into the CPU. The boot sector is not a part of a filing system and so it is never encrypted, as far as I know, but that doesn't stop people doing non-standard PC feature with it.
Grub legacy is already being acused of being too large for what it is able to do at the moment, relative to other boot loaders.
(5) If the mobo does not support booting from a USB device then the Bios does know the existence of the USB device. In such case Grub can't find it because Grub relies on the Bios to get the disk information.
Grub can boot from a CD. It has a special version of it called stage2_Eltorito. A minority of distros also use it. One can boot a CD with only Grub inside or with any operating system compiled as an iso to be booted by Grub. CD used a different filing system, has no partition and no usual sector devision as a hard disk.
In general if the Bios reports a bootable device Grub legacy should be able to boot it. At least that is my experience so far.
One has to remember at the time the boot loader is operating it does not have the benefit of a kernel and its drivers. The boot loader's duty is always to boot the kernel in Linux, a module in a Unix-like system or another boot loader of another operating system.
There are 3 HD`s.
IDE 0,0 harddisk (hd0) (file system not recognized by Windows)
IDE 0,1 harddisk (hd1) (file system not recognized by Windows)
IDE 1,0 CD-ROM
IDE 1,1 harddisk (hd2) (empty)
Windows XP shall be installed on hd2. The Windows setup wants to format hd0 to place some startup files there.
IDE 0,1 and IDE 0,1 in BIOS does not help. The Windows setup is seeing them anyway, I guess because it loads their own disk controller driver and is talking directly to the harddisks and not thought the BIOS.
Also map (hd0) (hd2) and then booting the CD-ROM (with grub4dos or smartbootmanager) didn`t work, guess for the same reason.
What probably would work is physically detaching IDE 0,0 and IDE 0,1 while installing. But I am for a more professional solution with less violence. Therefore I am asking you here for advice.
Still I am looking for a good replacement for legacy floppy. I would like to use an USB flash drive just in floppy emulation mode or even better as superfloppy.
When booting from USB flash drives or USB harddrives the USB becomes (hd0) and C:\. This quite problematic (especially when you want your bootmanger on USB) because it`s not a full IDE 0,0 harddrive emulation mode. I mean, it`s C:\ but if some applications ask what`s on IDE 0,0 it returns the USB drive, others return the real IDE 0,0.
Much better it would be if the USB drive could become (fd0) and A:\. But when formating an USB as superfloppy my BIOS can no longer boot it (only formated as harddisk). However. Is this even possible if the BIOS could boot up superfloppy to see the USB as (fd0) or at least as A:\?
[url=http://brainstorm.ubuntu.com/idea/6138/]TrueCrypt - Full Disk Encryption - Documentation Request - please vote - any advancend user can contribute starting a wiki article[/ur
AFAIK if your Bios allows you to choose another hard disk to boot up first then you should have no problem in selecting (hd2).
If you manage to elect (hd2) to boot up first then XP will write its MBR on disk (hd2). and you can run XP happy as long as (hd2) is the first bootable disk.
When you change the 1st boot disk to (hd0) you need two extra map statements to tell Grub to re-map (hd2) on-the-fly to (hd0) if XP is booted.
The above should work alright without physically altering the electrical connections of the hard disks.
Window XP, and all other Dos and Windows too, always assumes it is the only one in the PC and so if there is a first boot disk it needs to place its boot loader there if the system is installed in another disk. That characteristic cannot be changed.
Regarding using the Grub on USB you can do it as long as you remember this rule.
If you boot up a USB disk device it is looked upon by the Bios as a "hard disk" and so it becomes (hd0) by default. This pushes all your existing hard disks up in number by one.
Therefore say without the USB device the Grub in hard disk (hd0) boots successfully your XP in (hd2) by command
title Windows XP installed as (hd0,0) now booted from (hd2,0)
map (hd2) (hd0)
map (hd0) (hd2)
After inserting the USB disk you can highlight the XP choice but instead of pressing enter to fire it up you press "e" key to edit the lines. The editions are the two map statements (edition marked in red).
map (hd3) (hd0)
map (hd0) (hd3)
Then XP will boot up just same as before.
Therefore you can do it with a USB memory device to house Grub but just remember its menu.lst has to be adjusted for the one extra disk number. Alternatively you do he amendment manually in every boot up demonstrated in above.
Using a floppy or a CD does not have such drawback because neither of these two is a "hard disk", as far as Bios is concerned.
There may be a way you can cheat Linux on the device names, of change a USB memory device to /dev/fd0, but I wouldn't know how to do it myself. I find the honest way is still the best. As long as you know the reason behind it you should be able to find a way out. That has been my happy arrangement with Linux so far.
I have read some articles here on booting that are way and above better than anything else anywhere else. Kudos to the submitters. I learned a lot, THANKS!
TrueCrypt works by putting a tiny, PRE-BOOT decryption test program in the MBR. This tests the different algorithms with the supplied password and looks for the word TRUE in the Volume Boot Record. (At least in Windblows versions)
For it to be successfully chainloaded, the trueCrypt MBR has to be stored in a partition OTHER than the Windblows partition it is for, loaded as if it were the Volume Boot record, and if Active Flag is correct in the Partition Table (in the stored TrueCrypt MBR?), it will then do it's thing and boot(strap) the encrypted Windblows partition.
So, gurus all, can GRUB boot a stored MBR? The motherboard wouldn't care, I don't think, because the VOLUME BOOT RECORD is written over the MBR in memory, right?
All thoughts ,(expert knowledge, and fearless experimentation), appreciated.
Hey! I got help here and now I want to share my little knowledge also. Ok, about TrueCrypt... Isn`t exactly what you are asking for I think but it`s imho still a very nice workarround. I like bootmanagers on any other medium like internal harddisks very much.
First of all a general info. I don`t think TrueCrypt can be installed in another partition then hd0,0 and it will always take the whole MBR for itself. The TC bootloader can not be simple chainloaded for some strange reason, but the TC bootloader is a chainloader itself, he will boot any partition/harddisk after hd0,0.
The best is to have TrueCrypt on floppy. Or on CD-RW. You can also boot from USB if your BIOS supports that. Note that the booted USB device will become hd0.
tc.iso = the TrueCrypt rescue CD created while encrypting a system partition. It`s only working for this and only this unique disk, no other iso can be used. Here is an example for floppy. It needs grub4dos (I did read storys that there are problems with memdisk, but not confirmed myself.).
You could use isolinux (and only isolinux, not syslinux because syslinux does not have the localboot command) and then use localboot 0x80, it will chainload the first harddisk (including MBR).
saikee: Thank you for your amazing and comprehensive tips. I've worked with Unix, Linux and Windoze for years, and am finally starting to learn about Linux boot. What a help. I've been reading a lot of threads here and elsewhere, and thought I was starting to understand some of this. Of course, the first time, things don't seem to work as expected.
Earlier, I created two Puppy Linux LiveUSB sticks under WinXP using Linux Live USB Creator (which I now understand uses syslinux). Both of the sticks worked great, and I have been a happy puppy.
After reading some of your threads on Grub, it seemed like a good thing to try, especially with all the good details. However, as soon as I run grub to setup the loader on one of the USB sticks, it is no longer bootable! I can't figure this out.
I've tried reformatting three times, twice with gparted, and once following your notes using mkdosfs. Nada. The stick is ignored and XP starts up. Both gparted and fdisk show a primary fat32 partition with the boot flag set. I've tried rerunning grub, and even tried using grub-install. Still nada. Wtf am I missing?
I suspect it is more to do with the device numbering if you are booting it with a USB stick.
Basically when you installed Puppy the USB device may be recognised as sdb and hard disk No.1 when the hard disk No. 0 goes to the existing hard disk which also gets the device name /dev/sda.
When you boot the USB stick up by instructing the Bios to boot the USB device first the stick becomes device sda and hard disk No. 0. This effectively means the Grub menu and /etc/fstab will have to be modified to suit.
If you still have a problem post your /boot/grub/menu.lst and /etc/fstab here.
Thank you for your quick reply. I would have been happy to post my menu.lst. However, just before I read your note, I re-ran LiLi (Linux Live USB Creator). It happily deleted my entire /boot subdirectory. I will have to recreate it. Also, an fstab assumes that something's booted. The USB is ignored at this point (the OS is on the stick, I'm not booting to another disk).
After running LiLi again, the stick is still not bootable. I don't get errors, it is completely ignored. The first time I ran LiLi on this stick, it worked great. However the USB has become "invisible" as a boot device ever since trying to install Grub.
Prior to running LiL the 2nd time, I tried to run syslinux directly, but got the error "this doesn't look like a valid FAT filesystem". The -f option did not help. GParted and fdisk continue to show a partition w/fat32 and the WinXP partition manager reports a healty fs.
All of your examples that I found (granted I haven't read all of them yet), follow your good advice to install OS-specific boot loaders into the partition boot sector for that OS. Cool. But the first step is to add Grub to the MBR, yes? How do I do that, and how do I troubleshoot when it fails? I assume that a stick with one primary partition has both an MBR and a partition boot sector, but it sure acts like there's no MBR.
Usually when something this easy fails so completely, there's something very basic that I'm missing. Thank you again,
If you run Puppy CD you can get the device names as detected by root terminal command
My prediction is if the CD is booted as the first bootable device Linux detect the internal disk first and then the external disk (USB) second. Therefore your USB device should be /dev/sdb while the internal hard disk will be /dev/sda.
You can then get a second opinion from Grub by activate a Grub shell at the root terminal by command
Inside the Grub shell you can ask Grub to tell you the disk order (hd0) and (hd1) by command
If you have installed Puppy inside the USB disk with Grub then you want put Grub in the MBR of the USB disk. If (hd1) has been confirmed as the USB disk then this command will put Grub in the MBR of the (hd1)
The above command will work if you have in the USB disk partition /boot/grub and there is two files stage1 and stage2 inside. Refer to this thread on how to put Grub into a USB device.
You then tell the Bios now you want the USB device to boot first. The Bios will then treats the USB disk as the first bootable disk or (hd0). The USB disk will boot and Grub will try to execute /boot/grub/menu.lst inside the USB disk. If the menu.lst is absent or faulty Grub will default to a Grub prompt.
All the installed PC operating systems I know can be booted up by a Grub prompt.
You can ask Grub to list the content of the syslinux.cfg by command in a Grub prompt
depending on the location of the syslinux.cfg.
The above tells you the kernel and initrd files names with which you can fire up Pupply Linux manually. In general the sysliniux.cfg can be converted into menu.lst. There is a few examples here. The thread was first written to put several Linux iso into a DVD. To do this I change the isolinux to Grub. Later I added a post to demonstrate how to put all of them in a USB stick.
There are two types of Linux installation in a USB device. The first one is to replicate a Live CD. This is done by copying the expanded iso into a USB device and altering isolinux into Grub. The second is a normal installation which specific to the PC hardware and the hard disk footprint can be 4 to 5 times larger than the first type installation. The thread I wrote was for the first type installation. Puppy installer calls it as Fungal install.
Yeah, thanks, I understand these details. I don't understand why the USB is no longer recognized as a bootable device. If Grub is in the MBR, I should get a Grub prompt even if menu.lst is wrong, missing, whatever. I've tried ten ways tonight that don't work, including permutations of grub, syslinux, fdisk, dd and MBRWiz. Nada. I even managed to hose the other USB that was still working, and now it doesn't boot.
Maybe this is a BIOS problem with my PC. Today I downloaded Ubuntu and used the pendrivelinux Universal USB Installer to reinitialize the failed USB stick.
Still isn't recognized by my PC, but a friend's HP laptop booted it just fine. At least all of the recent searching wasn't a total waste: I'm writing this from Ubuntu booted on my Macbook. The same stick now boots on both a PC and on my MacBook, using grub-efi that doesn't need to be added to the MBR. Very cool.
It won't boot on my friend's MacBook Pro (kernel loads, but it hangs after the initrd). In fact, the second and third times I tried, the USB stick was no longer recognized as a boot device on the MacBook Pro. When I booted OS X and looked, disk manager showed that the boot flag had been reset. However, when I got home just now, it booted up fine again on my MacBook.
Anyone know the trick to booting Ubuntu on a MacBook Pro?
Last edited by c.cobb; 03-12-2010 at 12:41 PM.
Reason: more info, fix url
Issue resolved: USB recognized as boot device again on PC
Success, finally. In frustration, I dd'd a kilobyte from /dev/zero to the device and rebooted. Got the cryptic message "Boot error". So an error's better than nothing! That lead me to this article and then this page. The fix that worked for me:
sudo mkdiskimage -F /dev/sdX 0 128 32 # good for my 2GB USB stick
Immediately after this, gparted didn't like the partition. However, after running the Puppy Universal Installer, everything is copacetic once again: gparted is happy, and I can boot from the stick on my PC. Yay, hooray.
I hope this saves someone else the 100 or so hours I spent on this (well, seemed like it anyway...in six and a half days, maybe fifteen hours, but still, whadda drag).
After screwing around for a couple of days i tried your tip on line E3=other=/dev/hda8
added to lilo and bingo it worked , looks so easy after messing with grub (which i like by the way) but with so many different options my head was about to explode,thank you for taking the time to share your knowledge .
3 Slackware12.1 and 1 Debian Squeeze (3 puters), purring
Ok, not sure if this is the right place to post this and ask these questions - but looking around the net, it appears to be the best I've found...so here goes.
1. Let us assume I have formatted a blank USB stick showing as H: - 1GB, 2, 4, 8 etc. with a fat32 file system, likely to be done in Windows since I haven't got a Linux system yet, and I use the command:
format H: /FS:FAT32
(I happen to have Windows 2000, service pack 4 - this command is ancient - haven't tried it with Vista or 7)
2. Now I have a Linux OS to install on there - for tiny problem and tiny copy, lets use Tiny Core - about 10MB.
Tiny Core likes to be installed in a folder, \TCE off the root. So, I get their files and place them there - primarily
3. Now I've used syslinux, ntldr and grldr, linuxlive (?livelinux?), syslinux etc. - and GRUB
Not quite sure about how this works, but thus far, Grub working on a W2K box has been the most reliable and easy to configure. syslinux seems to "hang" and Lilo? Uh - problems...
So I have
... sitting in a folder on my C: W2K drive - just a "storage" folder -
and I copy them to the USB stick
copy c:\stuff\grldr H:\
4. I use notepad to edit menu.lst and have a basic menu.lst file
title Pocket Rocket Linux
find --set-root /tce/tinycore.gz
kernel /tce/bzImage quiet norestore bkg=splash.jpg desktop=jwm waitusb=15 xvesa=1400x1050x24
...saved as H:\menu.lst
So at the end here I have - in the root
and below that
5. QUESTION: why won't it boot?
It used to (sort of) when I had syslinux working - sometimes booted ok -sometimes hung - but BIOS was capable of seeing it and running. Since it hung half the time I figured I'd use GRUB (grldr and menu.lst) which has been very reliable on the W2K box, installed on C:\grldr and C:\menu.lst
I liked Grub so much I said "To heck with syslinux (hangs) or Lilo or anything else.
6. I have a feeling it has to do with the MBR - master boot record
I have seen answers that say "Go copy this or that file from another Linux CD to the USB drive.
QUESTION: I would like to know if there is anything I could type in NOTEPAD - or even use Perl or quick basic - and write a quickie bit of data - less than 512 bytes - that could tell BIOS to GO RUN GRLDR - which will automatically snag menu.lst and do whatever it wants to do - i.e. use the grub find command and away we go
Basically I want to open notepad or use some "editor" and create the commands (?assembler?) that say "Go run grldr (or something) so the grub parameters are executed.
Is there a method of either doing this manually or somehow getting grub / grldr to run?