|
From: | Henrik Nordstrom |
Subject: | Re: [Qemu-devel] fdisk give wrong number for losetup |
Date: | Mon, 11 Jul 2005 04:15:42 +0200 (CEST) |
On Sun, 10 Jul 2005, octane wrote:
Jim C. Brown a écrit :I have some trouble using losetup to mount partitions from the host.I never realized how difficult it was to interpret error messages written ina foreign language.Ok, sorry, in plain english messages are: address@hidden:/usr/src/qemu-test# fdisk -l zipslack.img You must set cylinders. You can do this from the extra functions menu. Disk zipslack.img: 0 MB, 0 bytes 16 heads, 63 sectors/track, 0 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System zipslack.img1 1 66 33232+ 82 Linux swap zipslack.img2 67 609 273672 83 Linux address@hidden:/usr/src/qemu-test# and mounting the file with an offset of $((67*512)) doesn't work
The offset if 67*516096, as this partition table is printed in cylinders, not sectors.
When calculating partition offsets it is always best to look at the partition table in sectors, not cylinders, especially considering that partitions does not need to start exactly on a cylinder boundary. For example the first partition doesn't start at cylinder 1, it starts at cylinder 1 head 2, or sector 64. Both fdisk and sfdisk supports viewing the sector based partition values, maintaining sanity.
I really recommend using lomount or some similar tool to figure out these offsets for you. (Incidently, lomount doesn't care about disk geometry - it uses the absolute sector values in the partition table.)
Nearly nobody except for DOS (and the parts of BIOS used by DOS) cares about geometry..
I receive a mail that says: fdisk -l zipslack.img is not the same as fdisk- lu zipslack : address@hidden:/usr/src/qemu-test# fdisk -lu zipslack.img You must set cylinders. You can do this from the extra functions menu. Disk zipslack.img: 0 MB, 0 bytes 16 heads, 63 sectors/track, 0 cylinders, total 0 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System zipslack.img1 63 66527 33232+ 82 Linux swap zipslack.img2 66528 613871 273672 83 Linux and incidently $((66*516096))=$((66528*512))
Correct, from the cylinders/heads/sectors geometry. If you look at the swap partition then things is more interesting.. (also why sfdisk printed a + there, and probably what the + in the blocks column of fdisk refers to...)
Regards Henrik
[Prev in Thread] | Current Thread | [Next in Thread] |