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)

One of the frustrations I have with Firefox (on both Linux and Windows) is that it is not just a memory hog but a CPU hog as well.  On my Linux box (only box that has desktop, others are all console/text based) that runs under Xfce4, watching top will tell me that it’s eating up 50% of my CPU (on a dual AMD Opteron64, that means 100% of one of the CPU right?).

I’ve had enough of that!  One of the reasons why I kept Firefox was because of three plug-ins that I could add to it.

• Rikaichan
• Furigana
• FoxyProxy

Just recently, I’ve discovered that there are now plug-in extensions for Chrome for Rikaikun and Furigana, so I’ve started to keep my options open to try Chrome again.

When Chrome first came out on Windows, I’ve tried it out, mainly because I prefer (with all things) to try it out and construct my own opinions about it rather than listen to others and rely on their opinions.

Back then, I wasn’t impressed much, but then again, I don’t use any of the web-browser much on both Windows and Linux other than to research on something technical (rarely use it for entertainment).  But when I do use the browsers, I want something flexible and be able to do what I need (i.e. I would like Furigana injection and/or Rikaichan/Rikaikun) as well as something native and/or reliable (for example, for Windows I usually trust IE more than Firefox and at work, I don’t want to install anything “extra” on my devbox so I rely on IE).  Back then also, I was researching on any web methods to read managa online, and Shonen Sunday (mainly, I wanted to read “Cross Game” – if both Sunday and Jump would allow paid subscriptions of outside Japan, they would be rich, because I’d be paying them and never would unsubscribe!) and trying to access their reader from Chrome was causing problems.

In any case, back to technical issues…

One thing I’ve noticed about Chrome (on my Gentoo, it’s Chromium-bin) is that each tabs are created as new process (meaning they have different PID) for both Linux and Windows.  More tabs you open on Firefox (or IE), more CPU and memory it hogs up.  This is not the case with Chrome.

I think approaching it this way plays nice and well/better and will task schedule better with the O/S.  Whether it is on my Windows or Linux desktop, with Chrome it does not become a CPU hog.

What does that mean to me?  Well for one, on my Laptop, it doesn’t eat up as much batteries or spin my fan as much to make my lap warmer…  For my Linux desktop, I can use my CPUs for what I need, to compile/emerge Gentoo portage updates  *grin*

Notes:

• I can probably do the same with IE or Firefox by opening each site as a separate applications.
• When Firefox introduced tabs and IE copied it, there was no turning back, we’re all now using tabs.  I cannot live without tabs anymore, so the option of opening up new application for each site is unjustified for me…
• Chrome-bin doesn’t do well with both SCIM and IBUS, so when I want to write e-mail in Japanese, I still use Firefox (I use SquirrelMail)

Related posts

• Networking: AD + Linux (0)
• Dual/Multi Boot + GRUB + BOOT.INI (default boot to GRUB) (0)
• Use your O/S to Multi-Process (0)
• Syslog-ng + syslog-server (Kiwi) = network slowdown (0)
• RAID0 is Useless in Today’s Technology (0)

Have you ever ran into an issue like this:

--------------------------------------------------------------------------------
ERROR   : # 1.
WHAT    : A runtime command failed to execute (returned error 2).
SOURCE  : line 16 of /etc/firehol/firehol.conf
COMMAND : /sbin/iptables -t filter -A in_interface1_syslog_s7 -p udp --sport syslog --dport 514 -m state --state NEW\,ESTABLISHED -j ACCEPT
OUTPUT  :                                                                                                                                
 
iptables v1.3.8: invalid port/service `syslog' specified
Try `iptables -h' or 'iptables --help' for more information.

You’d get similar errors for “ftp”, “ftp-data”, and I’d imagine other random ones.  You probably won’t see it if you have “START_FIREHOL=YES” not set (or commented out) in your firehol.conf file either…

Contrary to the beliefs that it is a problem with FireHOL or older bash, it’s actually (at least for me) a permission issue…

A simple test might be to do “whoami” and you might see this:

root@localhost ~ # whoami
whoami: cannot find name for user ID 0

I seem to get this whenever I run nscd daemon and have my ldap configured incorrectly.

In any case, try the following:

root@localhost ~ # grpconv
root@localhost ~ # pwconv

Now try restarting FireHOL again (or try “whoami”).  If that works, a possible “temporary” fix until you resolve it is to run a cron hourly of grpconv & pwconv (and of course disable other services such as nscd – at least for me).

Related posts

• Syslog-ng + syslog-server (Kiwi) = network slowdown (0)
• RAID0 is Useless in Today’s Technology (0)
• Networking: AD + Linux (0)
• Compiling Apache on Gentoo (0)
• Why KeepAlive Heartbeats should be on Dedicated Socket Stream (0)