Goal
I'm trying to make a harddisk image from scratch using a file. This includes MBR, partition table, number of partitions, etc. I cannot for the life of me get Linux to mount the partitions I make though.
edit: See end of question for update – seems to be related to vboxsf
Procedure
I've tried many different approaches by now but the ones that have gotten my the furthest all end up the same place. I've made a simplied version below which should be enough to explain my problem
Generate empty file using dd (or truncate for speed)
dd if=/dev/zero of=test.img bs=1M count=150
Make partition table
parted -s test.img mklabel gpt
Warning: The resulting partition is not properly aligned for best performance.
Make partition(s)
parted -s test.img -- mkpart logical 0 5M
parted -s test.img set 1 bios_grub on
parted -s test.img -- mkpart logical 5M 50M
etc.
Mount as loop device (loop module loaded with max_part=31)
losetup /dev/loop0 test.img
lsblk to check
loop0 7:0 0 150M 0 loop
├─loop0p1 7:1 0 4.8M 0 loop
├─loop0p2 7:2 0 43M 0 loop
└─loop0p3 7:3 0 4M 0 loop
so far so good – I guess. Format the partitions
mkfs.ext4 /dev/loop0p1
mkfs.ext4 /dev/loop0p2
mkfs.ext4 /dev/loop0p3
Now lets mount our new partitions
[root@localhost vmdk test]# mount /dev/loop0p2 boot
mount: /dev/loop0p2 is write-protected, mounting read-only
mount: unknown filesystem type '(null)'
This is where it ends – every time. I've tried mounting the image to a loop right after its created and call parted on /dev/loop0 instead. This yields the same result. I've tried losetup with offsets manually. I've tried kpartx – I cannot figure out how to get beyond this point.
I should note that I also tried this procedure with an actual harddrive (well I'm using a VM but you know what i mean). In this case I called the exact same commands but on /dev/sdb instead. At the end I was able to mount /dev/sdb2 with no problems.
Debug info
I don't know if its relevant but here goes
[root@localhost vmdk test]# uname -a
Linux localhost.localdomain 3.10.0-327.36.2.el7.x86_64 #1 SMP Mon Oct 10 23:08:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost vmdk test]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
[root@localhost vmdk test]# file test.img
test.img: x86 boot sector; partition 1: ID=0xee, starthead 0, startsector 1, 307199 sectors, extended partition table (last)\011, code offset 0x0
[root@localhost vmdk test]# file -s /dev/loop0
/dev/loop0: x86 boot sector; partition 1: ID=0xee, starthead 0, startsector 1, 307199 sectors, extended partition table (last)\011, code offset 0x0
[root@localhost vmdk test]# file -s /dev/loop0p2
/dev/loop0p2: data
[root@localhost vmdk test]# fdisk -lu /dev/loop0
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/loop0: 157 MB, 157286400 bytes, 307200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
# Start End Size Type Name
1 34 9765 4.8M BIOS boot parti logical
2 10240 98303 43M Microsoft basic logical
3 98304 106495 4M Microsoft basic logical
I don't understand why the loop device does not behave the exact same way as the harddrive does when I follow the same procedure. If anyone has any ideas they would be much appreciated!
Update
By coincidence I observed that a reboot fixes my problem so my mind immediately went to sync. After some testing though it would seem that my problem only occurs when the test.img file is placed on my vboxsf mount (shared folder between host and VM). I haven't really given this any thought but maybe it caches file writes in a weird way ? I'll leave the question open for now – maybe someone can elaborate.
Best Answer
If the image file is hosted on a weird filesystem like e.g. vboxsf this could be the problem.