On May 12, 2008, at 7:51 AM, Joel Andres Granados wrote:
Jeremy Katz wrote:
On Sat, 2008-05-10 at 18:22 +0200, Joel Andres Granados wrote:
I'm posting the patch here because I don't know where pyparted
discussion list lives :)
You can find the patch at https://bugzilla.redhat.com/attachment.cgi?id=305028
pyparted needs to search the valid partitions before it returns
anything in the py_ped_disk_next_partition function. With this
patch we can now save anaconda tracebacks to usb keys. I build
pyparted but didn't test the patch extensively.
Comments are greatly appreciated.
This significantly changes the semantics of the next_partition() API
call. While there aren't a lot of cases where you care about the
non-active partitions, there are a few. I think that actually the
right fix for the bug is probably something
along the lines of (completely untested)
diff --git a/partedUtils.py b/partedUtils.py
index 573bf4c..22bccb6 100644
--- a/partedUtils.py
+++ b/partedUtils.py
@@ -1362,7 +1362,7 @@ class DiskSet:
drives = []
for d in isys.removableDriveDict().items():
- func = lambda p: not p.get_flag(parted.PARTITION_RAID)
and
not p.get_flag(parted.PARTITION_LVM) and p.fs_type.name in ["ext3",
"ext2", "fat16", "fat32"]
+ func = lambda p: p.is_active and not
p.get_flag(parted.PARTITION_RAID) and not
p.get_flag(parted.PARTITION_LVM) and p.fs_type.name in ["ext3",
"ext2",
"fat16", "fat32"]
disk = self.disks[d[0]]
parts = filter_partitions(disk, func)
You have to ensure that the partition is an active one before doing
any
of get_flag or fs_type, etc. Yeah, it's a little ugly, but it's a
part
of the API and until we completely replace it, I think we have to
live
with it
Jeremy
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
The argument of waiting for pyparted to be rewritten is a
considerable one. If your going to do the whole thing from scratch,
why bother adding new stuff to the current one. OTOH, checking for
the validity of the partition so in the anaconda code make me feel
dirty. The other thing is that fix to anaconda goes in and then
might stays there even when the new pyparted is being used. It
might be good to do the anaconda change and have a bug (if someone
has a better idea of how to not let this fall through the cracks
please tell me) that documents this issue.
btw, where does the new pyparted live? the patch is done against
the latest version present in ssh://git.fedorahosted.org/git/pyparted.git
maybe I can help speed things up and include a patch in the new
pyparted. (something like an argument that will give you the "next
partition" or the "next sane partition")
We've been talking about the new pyparted in today's anaconda meeting,
so I wanted to point out what clumens and I had already completed:
1) Emulation of the existing pyparted API marked as deprecated.
2) New _ped module that gives full access to libparted.
3) New parted module full of classes and exciting fun functions that
may or may not do handy things.
At this point, we want to get the new pyparted done and in Fedora and
working. Anaconda will use the deprecated API until parts of it can
be rewritten to use the newer API.
Anyways, it got back-burnered last year because of too much other
stuff to do, but it's on the list for F-10 now.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
