Warning and disclaimers:

I hold no responsibilities for any potential damage you may inflict on loss of data on your pen-drives.

Usage of fdisk, mbr, and grub can potentially make your pen-drive unbootable, unreadable, or erased. If needed, backup your data on your pen-drive before you do any experiments!

Also, do not try to do this to your harddrive if you have never used GRUB2 or manually set MBR! Play and hack at your own risk!

You have been warned!

—-

THIS PAGE IS STILL UNDER CONSTRUCTIONS!

—-

One way to make your USB to boot is UNetBootin which can be found for both Windows and Linux and in my opinion, a very well done and easy to use tool (ues syslinux).  But this method is a one-shot solution which extracts and  copies the contents of the .ISO into your pendrive. But what if you want to just have an ISO image, byte the penalties of little bit slower boot, but be able to have multiple images of ISO?  Sure, you can have multiple copies of vmlinuz (and initrd) in your “/boot” folder, but the problem you may bump into is that different distros have different folder structures.  So my preferences is to preserve the ISO as a package and let it be isolated in that way.  In order to mount an ISO, you need to loopback (i.e. “mount -o loop”).  Another beauty of having it as plain ol’ ISO file is that in most cases, all I have to do is replace or add a new ISO file into my pendrive and edit my “grub.cfg” file and be done (well, of course we need to test it out – we’ll talk about using qemu to test later on). For example, here is my ISO files in my USB folder:

kusari pendrive # ls -la iso/
total 2837504
drwxr-xr-x 2 root root      4096 Jun  6 11:51 .
drwxr-xr-x 4 root root      4096 Dec 31  1969 ..
-rwxr-xr-x 1 root root 719142912 Jun  6 11:46 LinuxMint-8-x64.iso
-rwxr-xr-x 1 root root 721573888 Jun  6 11:49 LinuxMint-8.iso
-rwxr-xr-x 1 root root 731453440 Jun  6 11:51 ubuntu-10.04-desktop-amd64.iso
-rwxr-xr-x 1 root root 733419520 Jun  6 11:53 ubuntu-10.04-desktop-i386.iso

Nice thing about this is that I can choose to install either x86_64 or x86 (32bits)  by exposing the options in GRUB2 (or GRUB) menu.  Also, please note that as much as I love Gentoo, I’m not going to have Gentoo Install ISO for the following reasons:

• I’m not going to have a Live DVD ISO images eating up close to 3G of my pendrive
• Pendrive install is mainly for slower machines or laptop for me.  These types of targets are just hell to emerge (compile/build) applications (on my laptop, the fan stays on so much it gets very hot).  Of course the obvious counter to that is why then would I want a 64-bit install if the target machine doesn’t have the power?  The 64-bit is only useful for RAM greater than 4Gig, and obvious assumptions when you have that much RAM is that it’s gotta be pretty powerful enough to handle Gentoo compiling away…
• Gentoo does have minimal install but I believe it will need network to download stage3.  Install should be allowed network-less.  Maybe I am wrong on this one, I’ve never installed using “minimal install”.

As mentioned, the penalties you pay when you loopback mount the ISO is small loss in performance (well, at least, I feel the speed differences), but it’s not much and so far, I’ve not had any issues.

Ingredients

So before we begin the recipe, we need the ingredients…  I’ve done this with both Ubuntu and on Gentoo, and the methods are the same (or quite similar), but when I call out the ingredients, they will be in Gentoo format.  You will need:

• sys-boot/mbr
• sys-boot/grub-1.9.8
• sys-apps/util-linux (fdisk)
• sys-fs/dosfstools (mkfs.vfat)
• sys-apps/usbutils (lsusb – optional, but you can quickly verify when your USB is plugged in and working)
• app-emulation/qemu (optional but very handy so you don’t have to reboot all the time)

There will be many assumptions made here since lots of things are outside the scope of this cookbook.  For example, I will assume you know how to install grub2 (not grub), or that your USB is in fact functional and when you do a “lsusb” you do see your USB pendrive connected, or whether you know how to resolve the issues with SDL on qemu.

lsusb and fdisk

Assuming all are good, we first start off with making sure the pendrive is bootable.  Also, my preferences are usually to format it as VFAT/FAT32.  This is because PS3 manual says it has to be FAT32, and if I wanted to save something from Windows to my pendrive, I can do so.  So it’s just for the sake of conveniences more than anything else. First, I’m going to verify that I do have my pendrive connected.  We’ll use lsusb to check if my Kingston pendrive is connected:

kusari ~ # lsusb
...
Bus 001 Device 010: ID 0951:1625 Kingston Technology
...
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Next, I want to determine which device it’s currently defined as.  Kingston comes preformatted as FAT32 LBA (Type C) and so I’ll use fdisk -l to list it.

kusari ~ # fdisk -l
...
Disk /dev/sdc: 8019 MB, 8019509248 bytes
102 heads, 38 sectors/track, 4041 cylinders
Units = cylinders of 3876 * 512 = 1984512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x04030201

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1        4042     7830456    c  W95 FAT32 (LBA)

Now that I know my pendrive is in /dev/sdc (for now).  Note that if you have other I/O devices, it can be different each time you plug and unplug.  So we’ll want to use UUID instead of device.

While on the topic of device format, if you are formatting/setting up as ext4, make sure both your kernel and grub can support it.  I’ve booted older kernels in the past which didn’t support ext4 either because it was older kernel or because it wasn’t compiled with it.  Although ext4 is a different subject, you might want to read up on https://ext4.wiki.kernel.org on some issues.  Again, the best thing to do  for your pen-drives is to keep it at FAT32/VFAT so that it can be read from Windows, Mac, or Linux.

grub-probe (safe)

It is recommended that you use UUID rather than /dev/sdXN because depending on the order of when you plug in the USB, they can change from /dev/sdb1 to /dev/sdc1 or /dev/sdd1 etc…  To extract the UUID, you can run grub-probe like so:

grub-probe -t fs_uuid -d /dev/sdc1

By the way, blkid does a nicer job (or more easier to understand/comprehend/read) with list of UUID, it’s more of a preferences and what tools you have installed.

grub-mkconfig (safe)

Although the order does not matter in an idealistic world where nothing will go wrong, you might probably want to run this first before running grub-install if you’re running this on a harddrive you want to install grub2 (because if your PC accidentally rebooted – perhaps a power outage?) then you’re not yet setup for all the modules in your /boot/grub folder.  Fortunately in a setup such as for pen-drives, it shouldn’t matter unless your pen-drive is the source of booting.

For this recipe, we’re only calling this to make a place holder for the config file and it is optional.  This is because I want to boot multiple ISO images, which grub-mkconfig won’t know about…

grub-setup (unsafe)

From here on, the commands are “unsafe”, meaning if you accidentally run these commands to the wrong device, you may screw yourself;  For example instead of installing or updating your MBR to your pendrive, you enter your Windows device or grub1 device instead, making your perfectly good and bootable drive unbootable…  You may think you are being careful, but check and double check over and over of what you type because the device may change on you!  For example, if you boot from CDROM, what you remember of /dev/sda to be your hard-drive may become /dev/sdb because you’ve booted from CD (or USB-drive), and thinking your pen-drive is on /dev/sdb (which is now /dev/sdc) you do something to it and *whamo!*  Just be careful!

Similar to install-mbr, if you already have grub’s “boot.img” (and “core.img”) embedded inside the MBR, you do not need to run this again!

grub-install (unsafe)

First and foremost, grub-install is just a wrapper which calls other useful grub tools such as grub-probe and grub-setup, and guesses what needs to be done.  With that said, if you can manually do what grub-install does, you do not need to deal with grub-install.  Secondly, it will write over your MBR!  As mentioned in GNU manual, it is “less safe” to do it this way.  It is only here to mention that there are alternatives.

One thing to realize is that the device you tell it to install is not the partition, it is the drive in whole.  For example, your “/” (root path) and “/boot” are on “/dev/sda1″, you do not tell grub-install to install to “/dev/sda1″ but instead, you tell it “/dev/sda”.  Same deal with your pen-drive.  You tell it “/dev/sdc”.

install-mbr (unsafe)

You do not need to use this if you already have master boot record (MBR) on your pen-drive with grub’s stage1 embedded.  Again, even though this is for pen-drive, I just want to warn you that you should not run this against your harddrive unless you know what you are against…

install-mbr is a last resort for me usually.  grub-setup should write the MBR for me, so I should not have to do this.  But in one or two cases, I have had to fallback to using this method, possibly because I had experimented with syslinux and other tools that writes to MBR.

Sample grub.cfg

Since grub-mkconfig only will assume its auto generation based on existing vmlinuz files in your /boot folder, it won’t know how to do loopback.  We have to manually add our settings into the grub menu:

### hand edited:
# using "grub-probe -t fs_uuid -d /dev/sdc1" we find out our UUID for the pendrive currently is "ff90-d99b"
# grub-probe -t fs_uuid -d /dev/sdc1
menuentry "/iso/LinuxMint-8-x64.iso" --class gnu-linux --class gnu --class os {
        set             gfxpayload=keep

        insmod          ext2
        insmod          loopback
        insmod          fat
        insmod          ntfs
        insmod          lvm
        insmod          mdraid
        insmod          scsi
        insmod          usb
        insmod          iso9660

        search          --no-floppy --fs-uuid --set ff90-d99b

        echo            setting loopback
        loopback        loop    /iso/LinuxMint-8-x64.iso

        echo            Loading iso image /iso/LinuxMint-8-x64.iso
        linux           (loop)/casper/vmlinuz ro iso-scan/filename=/iso/LinuxMint-8-x64.iso boot=casper file=/preeseed/mint.seed splash

        echo            Initializing RAM disk (so that we have /dev/ram0)
        initrd          (loop)/casper/initrd.lz

        echo            Starting...
}

Honestly, I don’t need some of the modules such as ext2 or fat, but since most of my target machines has enough RAM to load these extra modules, I usually leave it be…  The above example is what I used for my pen-drive that I brought with me to the Linux Against Poverty install-fest to install Mint which was the chosen distro to install.

Boot Parameters

For Ubuntu and hybrids (i.e. MintLinux), it is critical that:

• “splash” is one of the kernel options when running in qemu because you cannot (or at least I don’t know how) to switch from one terminal to another (i.e. from 0 to 7) so if you are in text mode and the installer expects to be in GUI mode, you cannot switch easily.  So it’s better to just add splash to your kernel parameter and have it autoswitch for you.
• use “iso-scan/filename=/myISOfolder/myIso.iso” (similar to grml uses “findiso=xxx”)
• Do not use “root=/dev/ram0″ (that’s a zero) for initrd

xxx

Notes on discussing:

* /usr/src/linux/Documents/kernel-parameters.txt

mount -o loop -t iso9660 filename.iso /mnt/iso

Testing with qemu (requires SDL)

sync ; echo 3 > /proc/sys/vm/drop_caches ; qemu-system-x86_64 -hda /dev/sda -hdb /dev/sdb -hdc /dev/sdc

xxx

Related posts

• Dual/Multi Boot + GRUB + BOOT.INI (default boot to GRUB) (0)
• nvidia-drivers + edge-triggered + noapic (0)
• Use your O/S to Multi-Process (0)
• Syslog-ng + syslog-server (Kiwi) = network slowdown (0)
• Switched to Chromium and Never Turning Back (for now) (0)

Subtitle: Reasons why Gentoo is my Primary Boot rather than Windows 

I think it’s excellent to be able to multi-boot your system in case you need to switch to XP (as discussed here http://gentoo-wiki.com/HOWTO_Dual_Boot_from_Windows_Bootloader_(NTLDR)_and_why )

In my case, there used to be 5 reasons to keep Microsoft Windows:

1. Microsoft Visual Studio (including Express) is far more superior than any IDE, and C# (cl.exe) is only on Windows
2. MSDN.Microsoft.com and work e-mail does not seem to read/function well on any other browser than IExplorer
3. “World Of Warcraft” + Warcraft III (and other Warcraft series), and other Windows based games I love to play.
4. VPN for work uses Cisco VPN (proprietary) and they only provided me with Windows version
5. DirectX

Since I’ve been banned from “World of Warcraft” for reasons they would not explain to me (3 e-mails + 2 phone calls later, I’ve finally given up, I guess they don’t want my money…) and I can play Warcraft III (Frozen Throne) using wine (those guys at wine did an incredible job!), I’m down to 4 reasons to keep Windows. Anybody want to buy a frisbee with WOW label? I’ve asked Blizzard Accounting to refund me for the WOW disc because they’re useless without accounts. Maybe I can write my own server and connect to it *grin* (NOTE: If you think I was one of the victims who has been banned because of Linux, I never played WOW in wine or while Linux was running – I didn’t begin experimenting with wine until just recently.)

I’ve acquired from work the Linux version of Cisco VPN client so I’m now down to 3 reasons.

MSDN seems to work well now with Firefox (although I’ve no reason to research MSDN when I’m on my *nix system programming). And I can use my work (loaner) laptop to read and respond to work e-mail, so I’m down to 2. I have tried “wine iexplore” but it doesn’t seem to work well with frames yet.

DirectX is one of my favorite API because Microsoft did so well on its documentations and support. I love the X-File format because it is well documented, it’s much easier to use it than to roll your own and document it. If you had to come up with your own 3D file format, do you consider documenting it so that others can jump right into the project? Save some time and just use X format. But there’s Collada (https://collada.org/public_forum/welcome.php) now. Again, it’s because of the format and API documentation, not because I prefer Direct3D over OpenGL, or DirectSound over OpenAL. But now, there’s even talks about mono.XNA (http://www.taoframework.com/Mono.Xna) and others seems to use wine as a solution. So I don’t think a developer should stick with propriatory API and we should (in my opinion) lean more towards OpenSource API approaches.

Mono (and dotGNU) has evolved so much since its advent of it, if you haven’t check out mono in a while, it’s time to go evaluate the API support (they even have System.Thread and Windows.Forms now!), although I have problems compling dotGNU (due to long length filepath which cannot fit into buffer) at least mono works well on Gentoo, so that brings me down to 1 reason.  Only unfortunate part (as of this writing) is that currently, you cannot do managed-to-unmanaged C++.  Most would justify that if you are using .NET API, you should write your code in C# because it’s easier to read (none of that __gc or ^ stuff in Managed C++), but there are times when you have C++ code which you don’t wish to convert (due to performance, legacy, large code, project requirements, proven stabilities, etc) but you want to be flexible to support new modules and codes to support C# and .NET.  I have read on mono FAQ page that you can compile Managed C++ in pure or safe mode which can run under mono VM, but what I really need is a bridge between managed and unmanaged, which you still can do on Visual Studio.

I do not think I can separate myself from Microsoft Visual Studio. Although I love Eclipse (the CDT even does Intellisense and refactor – Visual Studio only refactors C#, not C++) it just doesn’t feel the same like Visual Studio. The price you pay for Visual Studio seems steep (expensive) but in the long run, it is well worth the money when you are a developer and spend most of your time in front of IDE (editor + debugger). MSDN and help which Microsoft provides is superior in the sense of “professional” (you get what you paid for). All in all, if you have been spoiled with Microsoft, it’s hard to go back. But to be honest, on my XP box, I do not even have Express Edition installed anymore.

In any case, I keep my dual-boot for now “just in case” but I’m quite content with my choice of operating system to be Gentoo Linux. In most of my daily purposes (including C++ programming) for hobbiest use, there’s no demand to pay $200 – $300 for an operating system today. I remember back in early to mid 90′s when it was so difficult (more like time consuming) to install Linux that I’d pay $200+ for Windows 95 and again on Windows 98 and again on Windows 2000. I’d rather be productive programming so investing $200 per operating system was worth it. Back in the 90′s, Novell dominated network systems. Unless you’ve really experienced integrating networking (i.e. Internet) to your operating system back then, you won’t know or understand the frustrations. With advent of Win9x, connecting to Internet became so easy.

Or another case in point is the differences between “back then” and “today” in terms of setup such as SAMBA. Today, it’s almost trivial to setup SAMBA. Back then, I remember there was an O’Riley’s thick book on SAMBA, I got so frustrated because there were so much information to absorb. I wasn’t being productive, I was doing more of setting up to get it to work than programming!

But today, the developers of Gentoo, Ubuntu, and other distros has done such an excellent job that it’s no longer an issue, you just download the distro, burn the CD, boot it, and you’re (majority of the time) good to go! Just like the Win98 days!

Don’t get me wrong, I still treat both Windows and Linux as “just another operating system” where I can code.  It’s just that as the operating system gets larger and larger, longer and longer to boot, it becomes inconvinient to switch back and forth (rebooting), so I have (currently) chosen my domain to be Linux.

So the purpose of this journal…

Setting GRUB as default boot

It’s rare, but when I ssh to my Gentoo box to install new version of the kernel or I wish to (for some odd reason) reboot my system, because BOOT.INI is defaulted to XP, I can never verify things if I remotely reboot. I’d have to physically go to my dev-box, wait for it to get to boot screen, choose GRUB, and off it goes.  But if I can have GRUB as my default, I can just wait until it reboots and ssh back on.

There are 3 trivial ways to set this:

1. GUI Method: My Computer -> Property -> Advanced -> “Startup and Recovery” (Settings button) – from here, select GRUB (under “Default Operating System”)
2. DOS: “bootcfg /Default /ID 2″ (where ID #2 is GRUB – just run bootcfg without the options to find out which ID you want.)
3. Edit BOOT.INI: I’ve tried this once and I could not correctly get it to boot, I thought all I had to do was set “default=C:\GRUBLDR” but that didn’t do the trick for me.  (NOTE: You can also click on “Edit” button under GUI to modify BOOT.INI for XP)

I usually just do bootcfg from DOS because that’s what always works for me, but I have tried GUI method and it does work.

Now, when ever you want to boot as Windows, you will have to physically be there to select it, but for rebooting your box as GRUB/Linux, it should automatically do so remotely.

Related posts

• GRUB2+USB pendrive+ISO (Loopback) cookbook (0)
• Switched to Chromium and Never Turning Back (for now) (0)
• nvidia-drivers + edge-triggered + noapic (0)
• Networking: AD + Linux (0)
• Use your O/S to Multi-Process (0)