The problem is ostensibly fixed in a new version of firmware that will be released in the next couple of days.
The problem is actually a little more complicated than having a partition table or not. There was a situation where a disk could appear to both have a partition table, and also have a FAT file system starting in the first sector. The way that can happen is if you use mkdosfs on the raw disk (sda), and then change your mind and use fdisk to partition it and then do mkdosfs again on sda1. fdisk does not automatically erase the BIOS parameter block (the FAT equivalent of a super block) in the partition sector, so you end up with an ambiguous situation where the first sector looks like an unpartitioned FAT volume and also a partitioned volume at the same time. I tried to correct that problem, but in the process I managed to break the case where there is an unpartitioned FAT volume that has the extended form of BIOS parameter block. I think I have now fixed that breakage... At least I hope so. fdisk + mkdosfs is a mistake-prone combination. Philip Macpherson wrote: > It now works. Jerub on the wiki helped me with this. > > [14:14] <Jerub> crazy_bus: I found just now that a drive with a > partition table and a fat partition has that problem. > > [14:14] <Jerub> but one with no partition taboe, and /dev/sda > itself formatted as FAT, did not have that problem. > > > I formatted so I had no partition and then open firmware was able to > read it. Maybe this should be mentioned on the wiki. > > Thanks for all your help, > Philip > > ------------------------------------------------------------------------ > > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel