3

I am trying to create booting system from raw disk image. This is what I do:

$ dd if=/dev/zero of=system2.img bs=1M count=6000
6000+0 records in
6000+0 records out
6291456000 bytes (6.3 GB) copied, 69.3662 s, 90.7 MB/s
$ sudo fdisk system2.img
Command (m for help): o
Building a new DOS disklabel with disk identifier 0xdd22ed22.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): w
The partition table has been altered!

Syncing disks.
$ sudo fdisk system2.img

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p):
Using default response p
Partition number (1-4, default 1):
Using default value 1
First sector (2048-12287999, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-12287999, default 12287999):
Using default value 12287999

Command (m for help): a
Partition number (1-4): 1

Command (m for help): w
The partition table has been altered!

Syncing disks.
$ sudo kpartx -avs system2.img
add map loop1p1 (252:0): 0 120832 linear /dev/loop1 2048
$ sudo mkfs.ext4 -U c0f21c98-ebf4-4f27-91b8-205da17c7893 /dev/mapper/loop1p1
mke2fs 1.42 (29-Nov-2011)
Discarding device blocks: done
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
15104 inodes, 60416 blocks
3020 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=61865984
8 block groups
8192 blocks per group, 8192 fragments per group
1888 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

Then I try to use this disk image QEMU and rescue mode (booting from debian netinst ISO). It offers me to mount /dev/sda1, but fails to do so. From /var/log/syslog it appears like it sees the /dev/sda1 as FAT

I have another disk image, which works with rescue mode. The only difference I could find between them is that, if I look at the working image with cfdisk I see first partition type as ext4. In failing image it says Linux

1

There is apparently a bug in kpartx. This sequence of commands works:

$ sudo losetup --show --find system2.img
/dev/loop5
$ sudo kpartx -avs /dev/loop5

Should not give disk image file directly to the kpartx

Tested on Ubuntu 12.04

  • 1
    Probably you can just add -P to losetup and drop kpartx altogether. – mikeserv Apr 19 '14 at 17:43
  • Agreed, kpartx went horribly wrong. Output shows kpartx gave you a partition of 60.4 MiB... and it also seems to have been mapped starting at sector 0, which would obviously be wrong. The partition you created with fdisk was really 5.999 GiB, starting at the 1MiB mark. – sourcejedi Jun 6 '18 at 21:27
  • Feel free to mark this answer as "accepted" by the questioner (you), by clicking the grey tick. Maybe I'm silly but I think it looks more complete when people can see the nice big green tick :). – sourcejedi Jun 6 '18 at 21:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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