Hey Anil,
All that fdisk does, is to print the partition table information present
in the MBR. If the MBR on the USB doesn't contain a valid partition
table at 0x1BE - Garbage In, Garbage Out.
Here is a test I just did on my USB Key:
# dd if=/dev/zero of=/dev/rdsk/c7t0d0p0 bs=512 count=1
1+0 records in
1+0 records out
# fdisk -W - c7t0d0p0 | tail -1
* Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect
This is definitely not flaky behaviour from fdisk. So what exactly are
you using the information from 'fdisk -W' for ?
Cheers,
Ananth
Anil Gulecha wrote:
> Alright.. we've been following offline and the issue is resolved..
>
> However it was due to 'flaky' behavior by fdisk.. fdisk with the -W -
> options should o/p something like below for the last 2 lines:
>
> * Id Act Bhead Bsect Bcyl Ehead Esect Ecyl Rsect Numsect
> 191 128 65 2 0 233 58 303 4096
> 4878336
>
> The size calculation in usbdump does
> nsect=fdisk -W - $device | tail -1 | nawk '{ print $10 }'
>
> On one of the wrong runs, this expanded to (in debug mode)
>
> ++ fdisk -W - /dev/rdsk/c1t0d0p0
> ++ tail -1
> ++ nawk '{ print $10 }'
> + nsect=Rsect
>
> (the line with numbers wasnt o/p by fdisk leading to nsect=Rsect)
>
> Chooch and myself were poking around this and in the next run the
> last line of numbers was also o/p allowing usbdump to proceed normally
> and create the liveUSB.
>
> So my question is, is there any reason why fdisk -W may ignore to o/p
> the last line of numbers?
>
> Regards
> Anil
>
>>> Hi,
>>>
>>> I've sent you some instructions offline..
>>>
>>> This looks like an issue we faced before, 'rmformat -s' command fails.
>>>
>> .. And once the issue is resolved I'll post the results to the list.
>> (and a new usbdump script if necessary)
>>
>> Anil
>>
> _______________________________________________
> belenix-discuss mailing list
> http://mail.opensolaris.org/mailman/listinfo/belenix-discuss
> http://groups.google.com/group/belenix-discuss
