Re: [Fedora-sparc] SPARC Status

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2012-09-22 at 20:21 +0100, Bryce wrote:
> 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
> > storage/partitioning.py.
> > 
> > Anaconda - a cruel and unusual punishment to make anyone do.
> > 
> > Phil
> > =--=
> > 
> > _______________________________________________
> > sparc mailing list
> > sparc@xxxxxxxxxxxxxxxxxxxxxxx
> > https://admin.fedoraproject.org/mailman/listinfo/sparc
> Ah, I think I see it now.

Are talking about Fedora 18, Fedora 12, or what? We've fixed a few bugs
since F12.

> 
> storage/formats/disklabel.py
> 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,...

Choosing "Use all space" will always create a new disklabel. Choosing
"Replace existing linux systems" will only create a new disklabel if
removing all linux partitions yields a disk with no partitions.

As far as the extra measure we take to ensure we do not leave (or find)
stale metadata -- if you want to complain about it, go ahead. This
clearing of metadata is what allows us to safely reuse the same geometry
if we so choose. It's beyond me why being careful would bother anyone.
Also, we do this any time we create a new disklabel, regardless of which
button was clicked to trigger the creation.

> 
> 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.

Here's how this works: 50% of complainers complain that we're not
aggressive enough with replacement of disklabels. The other 50% complain
that we're too aggressive. Go figure.

> 
> Anyway,. tracing shows 
> 
>         log.debug("resetting parted disks...")
>         for device in self.devices:
>             import pdb; pdb.set_trace()
>             if device.partitioned:
>                 device.format.resetPartedDisk()
>                 if device.originalFormat.type == "disklabel" and \
>                    device.originalFormat != device.format:
>                     device.originalFormat.resetPartedDisk()
> 
> which leads me into
> storage/formats/disklabel.py
>         class DiskLabel(DeviceFormat):
>         ...
>             def __init__(self, *args, **kwargs):
>                 if not self.exists:
>                     self._labelType = kwargs.get("labelType", "msdos")
>                 else:
>                     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 correct IFF the original disklabel type was not passed into the
constructor.

It looks like you've made a pretty big incorrect assumption about what
resetPartedDisk does. It does not wipe or reinitialize a disklabel. What
it does is really just an internal detail of how anaconda commits
partitioning changes to disk (one at a time). A call to resetPartedDisk
resets the disklabel to whatever state it was in when the DiskLabel
format was instantiated.

If I were you I'd be trying to figure out why no label type is being
passed to the constructor for your new disklabel. It'll be somewhere in
a getFormat("disklabel", ...) call.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list


[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux