| View previous topic :: View next topic |
| Author |
Message |
Habbit
Apprentice
Joined: 01 Sep 2007
Posts: 237
Location: 3.7137 W, 40.3873 N
|
 Posted: Fri Sep 21, 2007 5:54 pm Post subject: Loopmounted madness (aka I, the masochistic freak) |
 |
|
Does anyone here know what should I do to make a loopmounted disk image file have its partitions recognized?
Some background: I'm running a test installation of the HURD on a Bochs VM, which is using a file, say disk.img, as its hard drive. I want to copy some files from its root partition, and so I tried to loopmount the image file with losetup. This was successful, and I have been able to run parted on /dev/loop0, confirming that the "disk" with all its partitions is there. However, I cannot address each individual partition the way as a block device the way you can do with actual hard drives (/dev/sda -> /dev/sda1,2,3,etc., but there are no /dev/loop01,2,3,etc.). Is there any way to make udev/the kernel "notice" that there is a new block device and make it scan for its partitions? I know this is possible because many flash pen drives actually appear in my computer as, say, /dev/sdc AND /dev/sdc1, that is, an HD with one partition.
Any help will be greatly appreciated, since my current way of copying things between the two machines is network, which, for bulk copies, sucks (NE2000 emulation -> 10Mbps).
_________________
| Code: | ~ $ objdump -d ./habbit_mind
90 xchg %rax, %rax
EB FD jmp $-3 |
|
|
| Back to top |
|
 |
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54313
Location: 56N 3W
|
| Posted: Fri Sep 21, 2007 6:02 pm Post subject: |
|
|
Habbit,
You are missing the offset=<bytes> option to mount.
Try this on a PC.
| Code: | | mount -o ro,loop,offset=32256, /dev/sda /mnt/cdrom |
That really is /dev/sda (no partition number)
This mounts the first partition (sda1) on /mnt/cdrom read only, without using the partition table on the drive.
On a PC, the first partition always starts at sector 63, which is byte 32256, given 512 bye sectors.
You need to use the partition table to calculate offsets for other partitions.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Habbit
Apprentice
Joined: 01 Sep 2007
Posts: 237
Location: 3.7137 W, 40.3873 N
|
| Posted: Fri Sep 21, 2007 6:12 pm Post subject: |
|
|
Well, that is indeed possible, but I was looking for something less painful that interpreting a partition table by myself. Also, mkfs-like utilities usually do not play well without partition block devices.
As I said, either kernel or udev react to the insertion of a removable _drive_ (be it an USB pen drive or a true hard disk) and scan its partition table, dinamically creating its entries in /dev. Also, when using parted on a live system, either the kernel or udev notices the HD partition table has changed and adjusts the /dev block devices as needed. So I am looking for a way to tell udev/kernel "hey, this has a partition table! parse it!"
_________________
| Code: | ~ $ objdump -d ./habbit_mind
90 xchg %rax, %rax
EB FD jmp $-3 |
|
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54313
Location: 56N 3W
|
| Posted: Fri Sep 21, 2007 6:53 pm Post subject: |
|
|
Habbit,
fdisk will give you partition starts in blocks, then its just a case of multiplying by the block size.
You can put all the nasty numbers in /etc/fstab and use the lazy form of mount.
Its not so easy if the partition tables keep changing.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Habbit
Apprentice
Joined: 01 Sep 2007
Posts: 237
Location: 3.7137 W, 40.3873 N
|
| Posted: Fri Sep 21, 2007 6:57 pm Post subject: |
|
|
| NeddySeagoon wrote: | | Its not so easy if the partition tables keep changing. |
Why wouldn't it? Udev does it fine when I, say, plug in a USB "PATA drive case" and parted it live! /dev nodes are generated and readjusted on the fly as the partition table _keeps changing_. I'm just asking how could I tell udev to monitor /dev/loop0 for partition table changes in the same way it does with other devices.
_________________
| Code: | ~ $ objdump -d ./habbit_mind
90 xchg %rax, %rax
EB FD jmp $-3 |
|
|
| Back to top |
|
|
Habbit
Apprentice
Joined: 01 Sep 2007
Posts: 237
Location: 3.7137 W, 40.3873 N
|
| Posted: Fri Sep 21, 2007 10:17 pm Post subject: |
|
|
Well, I have started finding things, and woefully I don't like them: | Code: | # partprobe /dev/loop0
Error: Error informing the kernel about modifications to partition /dev/loop0p1 -- Invalid argument. This means Linux won't know about any changes you made to /dev/loop0p1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.
Error: Error informing the kernel about modifications to partition /dev/loop0p2 -- Invalid argument. This means Linux won't know about any changes you made to /dev/loop0p2 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.
Error: Error informing the kernel about modifications to partition /dev/loop0p3 -- Invalid argument. This means Linux won't know about any changes you made to /dev/loop0p3 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.
Warning: The kernel was unable to re-read the partition table on /dev/loop0 (Invalid argument). This means Linux won't know anything about the modifications you made until you reboot. You should reboot your computer before doing anything with /dev/loop0.
# blockdev --rereadpt /dev/loop0
BLKRRPART: Invalid argument |
I dug a bit into the kernel code, and doing an ioclt(bldev, BLKRRPART) causes this function to be called: | Code: | /* From the Linux kernel 2.6.17 */
static int blkdev_reread_part(struct block_device *bdev)
{
struct gendisk *disk = bdev->bd_disk;
int res;
if (disk->minors == 1 || bdev != bdev->bd_contains) /* This seems to be the problem since both partprobe */
return -EINVAL; /* and blockdev returned the "invalid argument" error */
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
if (!mutex_trylock(&bdev->bd_mutex))
return -EBUSY;
res = rescan_partitions(disk, bdev);
mutex_unlock(&bdev->bd_mutex);
return res;
} |
I don't know what disk->minors stands for and why bdev should equal bdev->bd_contains (if that meant the block device had to be a self-contained disk then LVM/RAID and the like shouldn't work!). I wouldn't even mean patching my own kernel, so... any ideas? 
_________________
| Code: | ~ $ objdump -d ./habbit_mind
90 xchg %rax, %rax
EB FD jmp $-3 |
|
|
| Back to top |
|
|
Habbit
Apprentice
Joined: 01 Sep 2007
Posts: 237
Location: 3.7137 W, 40.3873 N
|
| Posted: Sat Sep 22, 2007 10:39 am Post subject: |
|
|
Continuing my lonely post, I have found that since 2004 (and the 2.6 series), there have been many patches to enable partitioned loop devices, but none has to this date made it into the official kernel. So I might just use one of those patches if I can bring them up to my 2.6.22 source and don't hose my box.
What I fail to understand is why should the Linux kernel categorically and definitively decide that a given device (not only loopX, but also fdX et al.) can't have a partition table and refuse any proof that it does! I know partitioning a floppy is at the very least extremely unusual, and I would approve that _by default_ the kernel only scanned some devices for partition tables instead of every single block device in the system. However, if I run partprobe or blockdev --rereadpt and they find that /dev/loop5 or /dev/fd0 _do_ have partitions, why the hell does the kernel insist that they are an "invalid argument" and refuse knowing about them?
Sorry about this rant on a suspiciously cathedral-like decision by the kernel team, I don't mean to nail them or anything, as I can - and will - patch my kernel to remove this absurd limitation, something that I wouldn't have been able to do on a propietary OS.
_________________
| Code: | ~ $ objdump -d ./habbit_mind
90 xchg %rax, %rax
EB FD jmp $-3 |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Other Things Gentoo
