On 21/09/12 15:40, Bryce wrote:
On 20/09/12 15:00, Lamar Owen wrote:
Hmm, I seem to remember some issues around the partitioning under F12 on SPARC.  It was recommended, best I can recall, that you let the installer autopartition; anything else is very unstable and will likely crash anaconda.

Once installed you can set up partitions, move LVM around (I did that with our E6500, taking the defaults at first onto a single drive, and then moving the physical volume (with the LVM tools) to a software RAID5.  Worked fine.) set up RAID, or whatever else.  But it was important, IIRC, to take the defaults during installation.  There is a set of posts in the archives about the installer caveats, and I think it's on the F12Beta page on Fedoraproject.org, or at least it used to be.

I have my own private archive of messages like that to this mailing list, and I can repost if mecessary.
Mmm auto partitioning works but replace doesn't because for whatever
reason it ignores anaconda/platform.py where _disklabel_types = ['sun']
is set for the sparc platform and decides the disk should be using a
msdos label instead, so the install goes along fine since linux is able
to handle both label types, at the end after you reboot, OBP looks for a
sun label disk and finds msdos garbage which it promptly chokes on.

I think the logic is buried in storage/device.py and

Anaconda - a cruel and unusual punishment to make anyone do.


sparc mailing list
Ah, I think I see it now.

When you ask for a replacement of the existing linux system anaconda does what I consider to be really bad practices.
It seems to believe that knowing where the partitions are is enough for it to DELETE the 1st MB of the disk to destroy the partition table. It then initializes the disklabel and then writes out the partitions in the exact same place,...

WHY it thinks it's necessary to do all this russian roulette work rather than just work with the existing table structure baffles me, however, I didn't write it so I'm disavowing blame for once.

Anyway,. tracing shows

        log.debug("resetting parted disks...")
        for device in self.devices:
            import pdb; pdb.set_trace()
            if device.partitioned:
                if device.originalFormat.type == "disklabel" and \
                   device.originalFormat != device.format:

which leads me into
class DiskLabel(DeviceFormat):
    def __init__(self, *args, **kwargs):
        if not self.exists:
            self._labelType = kwargs.get("labelType", "msdos")
            self._labelType = None

So when the disk is nuked, the label can't be found and it assumes msdos rather than being sensible and looking up the platform data
This is part of why the "Replace linux system option" won't work for sparc. There seems to be a gaping hole in anaconda where it just make no effort to remember what the disk label format was. This seems to be true of anaconda 18 as well, I didn't check whatever is in git, I kinda expect this to be a problem for PPC folk as well.

self._labelType = kwargs.get("labelType", "msdos")
self._labelType = platform.getPlatform(None)._disklabel_types[0]
alleviates the problem but is not in any way a true fix but it will suffice for 80-90% of cases... What should have happened is that the original label type should have been noted and returned somehow.
(since at least one architecture has two types assigned, we'll use index [0] as the default)
[root@emerald mnt]# grep _disklabel_types platform.py
    _disklabel_types = ["msdos"]
        return self._disklabel_types
    _disklabel_types = ["gpt"]
    _disklabel_types = ["bsd"]
    _disklabel_types = ["mac"]
    _disklabel_types = ["msdos"]
    _disklabel_types = ["sun"]
            self._disklabel_types = ["gpt"]
            self._disklabel_types = ["msdos", "gpt"]