Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Portage Developer (http://www.linux-archive.org/gentoo-portage-developer/)
-   -   SPARC Status (http://www.linux-archive.org/gentoo-portage-developer/706458-sparc-status.html)

Bryce 09-22-2012 07:20 PM

SPARC Status
 
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/sparc

Ah, I think I see it now.



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



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:

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



changing

self._labelType = kwargs.get("labelType", "msdos")


to


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"]





Phil

=--=



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

Bryce 09-22-2012 07:21 PM

SPARC Status
 
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/sparc

Ah, I think I see it now.



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



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:

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



changing

self._labelType = kwargs.get("labelType", "msdos")


to


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"]





Phil

=--=



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

David Lehman 09-24-2012 04:21 PM

SPARC Status
 
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@lists.fedoraproject.org
> > 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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Bryce 09-24-2012 06:06 PM

SPARC Status
 
On 24/09/12 17:21, David Lehman wrote:



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



Sorry this is actually anaconda 12 I'm dealing with, since the sparc
port is being restarted, but when I looked at fc18 for comparison of
what changes may have happened the code seemed identical. which is why
I dropped a note here.






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.


because the geometry does change? (solaris label after formatting from
a zero'd drive (no partitions made))

root@solaris ~]# dd if=/dev/sdc bs=512 count=1 | cat -v

ATA-Corsair Force 3-3 cyl 65533 alt 2 hd 16
sec 223

[root@blackknight ~]# fdisk -l /dev/sdl



Disk /dev/sdl (Sun disk label): 16 heads, 223 sectors, 65533 cylinders

Units = sectors of 1 * 512 bytes




After anaconda requests a sun label for it

import parted

sd = parted.Device(path="/dev/sda")

disk = parted.Disk(device=sd)

print sd.biosGeometry

(72961, 255, 63)


The result being that alignment then goes crazy and we end up with
alignments of 15.86GB size rather than a more expected 2048K (which I
do get before the label get rewritten)

Anyway I do not expect anyone to worry or care about this. This is a
parted issue I'm looking at as well. It's just annoying that the label
does change and croak horribly. I just wasn't paying attention to the
'if no* partitions left, then re-label' aspect you just explained.



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.


damned if you do damned if you don't normally I'd be blamed for
something like that.





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




My assumption came from reading the action queue, literally,* whilst I
was following resetPartedDisk()

[debugging note]

(Pdb) print
self._actions[0]************************************************** *

Destroy Format ext3 on disk sda (id
1)*****************************************

(Pdb) print
self._actions[1]************************************************** *

Create Format disklabel on disk sda (id
1)* <----* ? ********************************

(Pdb) print
self._actions[2]************************************************** *

Create Device partition sda2 (id
3)********************************************

(Pdb) print
self._actions[3]************************************************** *

Create Format lvmpv on partition sda2 (id 3)



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.





Thank you for the pointer.



Phil

=--=







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


All times are GMT. The time now is 09:14 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.