Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to set up a system to prepare a Linux system on a virtual machine and then deploy it onto an SD card. The target system has an Atom processor, so there aren't architecture compatibility concerns.

Do any of the mount points have to be in a special, physical location for this to work or can GRUB grok the filesystem?

How do I set up the SD card to boot this system using GRUB?

Would it be better to rsync the filesystem over or dd a filesystem image? I much prefer the former because I don't have to change my VM much when going between different card sizes.


I assume that I'll have to prepare the card before hand using something like parted, then I'll have to install GRUB to it, which isn't a big deal.

The major question is, will GRUB find the kernel if it isn't in a guaranteed, physical place on the partition? In other words, is GRUB smart enough to read an ext2, ext3, or ext4 partition and find the appropriate mount points?

My disk will look something like this (2 partitions):

[GRUB] [grub loader stuff] [GRUB partition] [OS partition]

share|improve this question
up vote 2 down vote accepted

When Grub boots, it loads itself using information provided by the BIOS. As long as all the pieces are on the same disk this should work seamlessly.

When Grub loads Linux, it can find the kernel on the same disk as Grub or by searching through the available disks. Again if you put the kernel on the same disk as Grub this should work seamlessly.

When the Linux kernel goes to mount the root filesystem, it uses its own disk numbering. Grub passes a command line argument to the kernel so that it knows where to find the root filesystem; the argument has to be in terms of what the kernel understands. Disk numbers (e.g. sda, sdb, hda, etc.) are unpredictable if you move from system to system. The easiest way to make sure this will work is to put the root filesystem (and any other filesystem or swap space) on LVM. At boot time (specifically at the initrd/initramfs execution stage) the system will look through all available LVM physical volumes, assemble the groups, and that gives access to all the logical volumes they contain. Since LVM volumes have names and not disk numbers, it doesn't matter what the disk numbers are.

Grub has to know the exact physical location on the disk of its pieces. You can't make a bootable SD card by just copying files onto it, you have to make a bootloader installation. To cope with different-size devices easily, a good way is to make a fixed-size partition at the beginning of the disk for the OS, and use the rest of the space as an extra data partition. On that topic, see Cloning a bootable USB stick to a different-size stick.

share|improve this answer
@Gilles- I added a little information about my specific setup. – tjameson Jul 1 '11 at 14:20
@tjameson The answer to your addendum is yes. Apart from some of Grub's own components, Grub finds stuff (e.g. the kernel) by reading filesystems, not at a fixed position on the disk. Depending on your exact setup, you may need to tune the configuration file, but any reasonable organization will work out with zero or little tuning. – Gilles Jul 1 '11 at 14:31
@Gilles- Thanks! This was exactly what I was hoping for. I assumed that I'd have to tune the config file, but I guess I can get a pretty generic one working if GRUB can read filesystems. – tjameson Jul 1 '11 at 14:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.