4

I'm trying to install ChromiumOS from the Vanilla build. To install to hard drive, it is recommended to just dd it to a flash drive and copy the files from the finished flash drive to identical partitions that you've created yourself. But, if I could somehow trick Ubuntu into recognizing a .img file as an actual block device or open it with GParted, I could use GParted's partition copying to stick in empty space in an extended partition and so boot it from my hard drive without having to do the intermediary flash-drive copying.

Is this even possible? (edit: this is a whole-disk image)

1 Answer 1

5

Yes, but there are many types of "img" file. For the purposes of this discussion, I am going to assume that your image file contains raw disk blocks, which is what dd does.

One type of img file contains an entire hard disk image. Another type contains a partition image.

The general concept of an .img file created via dd is that it contains the disk blocks that comprise the hard drive (or respectively, the partition). The difference is this:

If the img file is for an entire hard disk, then it contains:

  • The partition table (whether it's GPT, MBR, or something else).
  • The boot sector, if any.
  • All partitions for the hard disk, each one respecting the layout/format of the partition table and containing filesystem-specific data.

If the img file is for a partition, then it only contains one partition's data without any of the "container" data of the partition table.

Think of your entire hard disk like an orange or grapefruit that's been cut down the middle. You have these little walls built around the orange sections of fruit.

The partition table creates those little walls, and the filesystem data is the orange juicy fruit itself.

It sounds like your img file is probably an entire hard disk, so it contains a partition table.

What you will do is run the losetup command to "map" your img file into a loopback block device. This translates your file, which is just a normal file containing binary data, into a block device which the kernel can do disk-like I/O on.

The loopback device node that you choose, for example /dev/loop3, can be thought of as equivalent in functionality to /dev/sda (the entire hard disk) if your img is an entire hard disk. If your img is just one partition, then the loop device can be thought of as equivalent in functionality to /dev/sda1 (just a partition).

If it's the entire hard disk, then you can run tools such as gparted, palimpsest, cfdisk, etc. to:

  • Identify the partition table type
  • Determine where the partitions are, their size, and their filesystem type
  • Mount the individual partitions to modify them

If it's just one partition, then you can run the mount command directly on the loopback device, e.g. mount /dev/loop3 /mnt/part.

The losetup(8) manpage. Learn to read manpages; I won't give you the exact syntax to type into the command line because it depends on your system configuration.

6
  • 1
    Awesome. I know about the different types of image files; sorry if I didn't make that clear. Looks like losetup should work for me! Commented Nov 27, 2012 at 18:30
  • Sorry that I made you give an extra explanation! Commented Nov 27, 2012 at 18:33
  • Update: losetup worked but unfortunately it sprung an error that "can't have overlapping partitions". I guess I'll just have to do it the old-fashioned way. Thanks for the info - this will be very useful in the future. Commented Nov 27, 2012 at 19:30
  • That error message may be because Chrome OS is using a non-standard partition type, or some other magic that is confusing the tool (I'm assuming you're using gparted?). Or was losetup the tool that threw that error? Commented Nov 27, 2012 at 20:26
  • No, it was GParted. Commented Nov 27, 2012 at 23:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .