Quick summary:
Under Solaris you can edit the partition table and fool a "dd of the entire
raw disk" into only reading a part of the disk. This trick fails under
NetBSD, apparently due to a kernel bug which lets the dd (attempt to) read
past the physical end of the device.
TODO: (for someone else):
Change a partition table with "fdisk" and test under Linux, and a DOS or
Windows only tool. Like Encase?
> Yes, they do have disklabels on disks containing *BSD-filesystems, no they
> will not automatically superimpose these on foreign disks, at least the *BSDs
> will not.
I didn't say the system writes (superimposes) the auto-generated disklabel to
the disk, only that it uses (interposes) this disklabel to interpret the disk.
See disklabel(9)
[...] If the medium does not contain a native disklabel that can be read
in directly, readdisklabel() may resort to constructing a label from other
machine-dependent information [...]
and http://www.netbsd.org/Ports/i386/faq.html#ms_partition
Accessing Microsoft partitions
NetBSD supports a number of different filesystems [....]
Setting up the disklabel
[...]
3.Type "disklabel <DISKNAME>"
If the disk contains only MS-DOS partitions NetBSD will automatically
generate a 'fake' disklabel containing an entry for the first MS-DOS
partition. [...]
> This is the _creation_ of disklabels, not _reading_ a raw disk.
What is a raw disk? You're using the "raw disk" the OS presents to you. The OS
presents the disk to you after dividing it up according to the disklabel, which
is on the disk.
I was wrong in part of my last email. NetBSD will use a disklabel that doesn't
describe the entire disk, but the 'd' partition ('c' on non-intel platforms)
seems to ignore the disklabel and read right on past the end of the disk,
giving an IO error for a non-existent block. See PR#1238. I think this bug
alone shows that dd'd the 'raw disk' only gives you the image of the disk the
OS wants you to see, and that the OS can get it wrong.
I was right, in that Solaris will honor an invalid disklabel (VTOC). You can
use "format" to cut the drive's '2' slice down to much less than the physical
capacity of the drive. You have to change the "Tag" to "unassigned" instead of
"backup". This manual setting doesn't seem to fool prtvtoc, which reports the
unused space. If you use one of the predefined disks and partition tables
instead of doing it manually, all of the errors disappear, including the ones
in prtvtoc. I was able to convert an old 4G SCSI drive to 100MB.
To reproduce on your own, run "format", select the target disk, give the
command "type", pick something small (I used "SUN0104"), "partition", "select",
choose the partition table (for "SUN0104" you only get one choice, also named
"SUN0104"), "label", and then confirm with "y". Now quit out and "dd if=...s2
of=/dev/null bs=1024k" and see how small your disk is. Run "format" again and
notice the disk now identifies itself as a SUN0104 drive.
No, I don't know off hand how to get back to the real geometry, so be careful.
When I boot out of Solaris2.8 to NetBSD/sparc, the OS identifies it as a
SUN4.2G drive, the disklabel now says 99MB, but thanks to PR#1238 I can still
get all 4G with "dd if=/dev/rsd1c" (along with an EIO error).
> Besides, verifying the path from disk to dd is not that hard, the
> ATA/SCSI-code is small and straightforward and the datablocks are moved to dd
> unchanged.
I did not say the data blocks were ever changed by the OS. I said you are not
necessarily getting all of the datablocks. I said when you go back and md5
checksum these blocks, they will still be seeing the same set of (limited)
datablocks, which will still have the same checkum. md5 checksums do not prove
you copied the entire disk, they only show that the part you did copy hasn't
changed from the original.
> No. You are reading the whole disk, sector for sector, as advertised by the
> disk itself.
No, as advertised by the kernel, which (for Solaris and NetBSD) uses the
partition table from the disk.
-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see:
http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Tue Jul 03 2001 - 07:09:38 PDT