On 3/19/2011 12:36 AM, Mark Morgan Lloyd wrote:
Thanks Mitch, generally noted. I've still got problems reading ext2 (Linux) filesystems, below reordered and truncated to focus on this.
Doing that builds OK, but I still can't read the directory. I'm suspicious about the partition table layout on the drive I'm using:
I've set myself up a disk with DOS and Linux which .partitions c describes as
1 Primary Yes FAT-16>32M 37 2 Primary No Extended 2252 2 Logical No FAT-16>32M 2045 3 Logical No 0x82 207
Linux's fdisk -l shows this to have start cylinders
/dev/hda1 1 6, FAT16 /dev/hda2 6 5, Extended /dev/hda3 311 83, Linux /dev/hda5 6 6, FAT16 /dev/hda6 283 82, Linux swap
I think one fair question here is how to tell .partitions to display all available, rather than stopping after four.
.partitions only displays the four partition entries that are directly contained in the partition map in the Master Boot Record. To make it decode logical partitions correctly, it would be necessary to improve the code of (.1partition) in ofw/fs/fatfs/fdisk2.fth . That code would need to be recursive, reading the subordinate disk block containing the extra partition map info that subdivides the extended entry into 4 logical sub-partitions.
(find-partition in ofw/fs/fatfs/partition.fth is recursive in that way, so it handles logical partitions. (find-partition is used when you choose a partition with a device specifier.
Admittedly, the current behavior of .partitions is sub-optimal. On the other hand, the primary use case of .partitions in the past has been as a quick check to see if the disk is basically readable, independent of whether it contains a supported filesystem.
One problem you might be having is that OFW and Linux probably disagree about partition numbering in the face of extended partitions. OFW does a depth-first recursion, counting only the leaf nodes. Conversely, at least according to the example above, Linux does a breadth-first recursion and appears to count the intermediate nodes (extended entries) as first-class partitions.
Given the layout above, here is my swag at how the numbering works. Indentation represents inclusion in an extended partition.
hda1 - OFW 1 hda2 - (OFW doesn't count this as a selectable device) hda5 - OFW 2 hda6 - OFW 3 hda3 - OFW 4
I tend to format disks using only primary partitions, just to keep things simple.
Linux's largely-unwritten policies for numbering disks and other devices have been a source of confusion forever.
I've just put Debian onto another disk, which Linux's fdisk -l shows as
/dev/hda1 1 83, Linux /dev/hda2 248 5, Extended /dev/hda5 248 82, Linux swap
ok dir /pci/pci-ide@1f,1/ide@0/disk@0:1,\ ok dir /pci/pci-ide@1f,1/ide@0/disk@0:1,\boot\
both get me directory listings. Almost there now :-)
Setting up symlinks in /boot to save typing, and working on my experience with Sun systems that parameters get passed through,
ok boot /pci/pci-ide@1f,1/ide@0/disk@0:1,\boot\vmlinuz initrd=/boot/initrd.img root=/dev/hda1
That (plus a few variants) doesn't work, I think I need to have the initrd "piggybacked" onto the kernel, or quite simply use a kernel that doesn't rely heavily on modules... yes, testing with a Slackware kernel works fine.
You need to tell OFW to read the initrd into memory; OFW does not parse the Linux command line to slurp out the initrd specifier. And Linux typically can't read it itself, due to the chicken-and-egg problem of needing to execute code from inside initrd in order to set up the necessary mounts to create the illusion of a uniform hierarchical file system in the face of multiple physical volumes. What does "/boot" mean before you have mounted anything?
The solution is to do this before executing boot:
ok setenv initrd c:\boot\initrd.img
(Assuming a suitable devalias for c)
So that leaves a possible issue with partition tables on some systems but apart from that looks pretty good.