Bugzilla – Bug 192080
uninitalized disk gets an msdos partition table on pmac
Last modified: 2008-07-16 15:43:53 UTC
run these commands on apple.suse.de dd if=/dev/zero of=/dev/sda bs=1M count=1 blockdev --rereadpt /dev/sda yast the partitioner suggests an extended partition, which makes me think it will create an partition table of type 'msdos' instead of 'mac'. While Linux may have no problem accessing the disk, the firmware can not handle it.
Created attachment 93389 [details] bug192080.tar.bz2
if I create a mac label in the background and let yast reread the partition table in the expert partitioner, then go one window back and choose 'sda whole disk', the proposal looks correct.
Thomas, could you look at this problem?
So far default disk label is determined by processor architecture. It is "gpt" for IA64, "sun" for "sparc" and "msdos" otherwise. Of course I could extend this to create a mac disk label for arch PPC but I doubt this would be useful since there are many different PPC machines. Need exact specifiction under which circumstances a mac disk label should be created.
yast2/library/modules/Arch.ycp provides Arch::board_mac to test this condition.
./storage/storage/src/modules/Partitions.ycp has DefaultPartLabel(), but there is also ./storage/libstorage/src/Disk.cc.
as discussed, the c++ code is used. in /proc/cpuinfo, the line ^machine contains either "PowerMac*" or "PowerBook*"
Should be fixed in current svn head.
on an empty disk without disk label, yast will start create partitions with sda1 on an empty disk with mac disk label, yast will start create partitions with sda2 sda1 is the partition table. There seems to be some check for that fact. It has to be applied also for a disk without disk label.
Should be fixed in SVN head for SL 10.2.
r31968 doesnt seem to fix it. sda1 is supposed to be created, with 20.0GB. I have replaced these files: usr/lib/YaST2/plugin/libpy2StorageCallbacks.so.2.0.0 usr/lib/perl5/vendor_perl/5.8.8/ppc-linux-thread-multi-64int/LibStorage.so usr/lib/liby2storage.so.2.0.0
Created attachment 94622 [details] bug192080.tar.bz2
Current DVN head of do_proposal_flexible.ycp should fix that.
no, still sda1 20.0GB. Now the proposal doesnt seem to assign mount points to the partitions, r32019 doesnt help. system is mac.suse.de, root pwd is 'root'.
Current SVN head should heopefully finally work (unfirtuanately mac.suse.de froze again while testing).
its still not perfect. sda2 is now the root partition, but its way too small with 39.2MB.
Created attachment 94893 [details] bug192080.tar.bz2
Did you test with the new version of do_proposal_flexible.ycp I mentioned in comment#13? From the logs it does not look so.
yes, I forgot that add this file to my inst-sys. hopefully the swig bindings get fixed soon.