On Mon, Oct 11, 2010 at 1:01 PM, Brian C. Lane <[email protected]> wrote: > On Mon, Oct 11, 2010 at 12:02:22PM -0500, Mills, James wrote: >> >> Replying to my own post, I have a bit more information around this >> behavior. Hopefully it will help someone on the list point me in the >> right direction. >> >> I have 4 machines: >> >> Ubuntu 9.10 x86 running parted 1.8.8.1.159-1e0e >> Ubuntu 10.04 amd64 running parted 2.2 >> Ubuntu 10.04 x86 running parted 2.2 >> Fedora Core 13 x86 running parted 1.9 > > The Fedora version should be v2.1
It was. I downgraded it to test a >1.88<2.x version. Sorry for the confusion. > >> >> On all four boxes, I am using the following steps (as root) >> >> losetup -d /dev/loop1 >> dd if=/dev/zero of=test bs=1M count=100 >> losetup /dev/loop1 test >> parted -s /dev/loop1 mklabel msdos >> >> At this point, I run both "fdisk -l /dev/loop1" and "parted /dev/loop1 >> -s unit chs p" >> >> Version 1.8.8 reports the same CHS numbers using both fdisk and parted >> (12,255,63). All other versions report: >> >> fdisk - 12,255,63 >> parted - 1600,4,32 >> >> Can anyone help me understand what has changed that would cause me to >> get such disparate behavior? > > When using a file or loop device the heads and sectors are set to 4,32 > and cylinders is set based on the length using these defaults. > > See init_file() in libparted/arch/linux.c > > As for why this is different, I have no idea. When dealing with real > devices it appears to set it to 255,63 as a default, unless the kernel > returns useful info with HDIO_GETGEO ioctl call (which according to the > comments isn't useful with 2.6.x kernels). Interesting. I wonder what prompted the change, as the loopback behavior in 1.8.8 *seemed* to work more like an actual device. > > See _device_probe_geometry() in libparted/arch/linux.c > > Does C,H,S really matter for any real usage, or is this just cosmetic? Unfortunately it does matter for this particular application.I am working with a piece of embedded hardware that requires a 2-stage bootloader, and the first stage is basically hardcoded to expecting that particular HS configuration. Anything else, and the machine won't boot. :( Thanks for the information! I'm guessing it is probably time to investigate integrating another disk partitioning/labeling tool into the image creation tools we are using... ~james > > -- > Brian C. Lane / Anaconda Team > Port Orchard, WA (PST8PDT) I miss Port Orchard! I lived in Bremerton for several years... :) > _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
