Re: [Fedora-xen] ppc64 xen support
by Spencer Shimko
On 11/26/07 11:40 AM, "Daniel P. Berrange" <berrange(a)redhat.com> wrote:
> On Mon, Nov 26, 2007 at 11:37:13AM -0500, Spencer Shimko wrote:
>> Hi,
>>
>> I was looking for any information people may have on running Fedora 8 Xen on
>> a PPC64 platform. Xen appears to support ppc64 but none of the Fedora pages
>> seem to mention it and Fedora doesn't have a ppc64 Xen kernel.
>
> Libvirt & the tools stack is able to build on PPC & we've have patches to
> fix PPC portability issues. The main blocker is that we don't have a PPC
> kernel for Xen that is usable. Without that we can't build the Xen userspace.
>
>> Anyone taken a swing at this or have any thoughts on where I should focus my
>> efforts?
>
> You should probably ask on the Fedora PPC mailing list
Thanks Dan. The libvirt + tool stack is working fine as your described.
Running qemu VMs works as advertised for x86 emulation. I had noticed the
Xen userland components missing as well and it makes sense now. Guess I'll
focus on the kernel side for now.
>
> http://lists.infradead.org/mailman/listinfo/fedora-ppc
Ah, another nice low-volume list :) I see your August thread in their
archives:
http://lists.infradead.org/pipermail/fedora-ppc/2007-August/001033.html
I'm going to cross-post for now as responses might be of interest to
subscribers of both lists. Any additional comments on the state of
kernel-level Xen support from the PPC contingent?
--Spencer
>
> Dan,
16 years
Doctor Database in the US
by rage Hinkle
Fully Licensed Doctors in America
788,815 in total <> 17,613 emails
Lots of Doctors in specialties like Orthopedics, Surgery, Radiology, Dermatology, Neurology, General Practice etc..
Sort by over a dozen different fields
Now offered at the lower rate: $393
=== ITEMS BELOW ARE INCLUDED IN THE DEAL AT NO EXTRA COST ===
US Pharmaceutical Company Executives Contact List
47,000 personal emails and names of decision makers
American Hospitals
more than 23k hospital administrators in over 7k hospitals [worth over $300 alone)
Extensive Listing of Dentists in the US
Practically every dentist in America is listed here
Chiropractors in the USA
Complete data for all chiropractors in the US (a $250 value)
Email us at: mdpro(a)live.ca
valid until Nov 23
By sending an email with 591 in the subject you will have your email revoked
16 years
Does mkisofs or genisoimage "magic library support" Warning require a bug post?
by Greg Morgan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"This program has been compiled without magic library support."
"Ignoring the -magic option."
Does this mkisofs/genisoimage message require a bug report? I receive
it when trying to respin a Fedora 8 PPC disk. I don't like the message
because the command I used is what pungi/anaconda use to create the PPC
ISO files
http://lists.infradead.org/pipermail/fedora-ppc/2007-July/001003.html.
The message occurs on a Fedora 7 distribution.
You can follow what I am doing here
http://fedoraproject.org/wiki/PlayStation/Ps3ReSpin. Thanks to all of
you on the list that posted questions and answers because that helped me
generate the ISO. Anyhow, I have been working on a PS3 Respin ISO
document. I want to use the Sony add-on CD to work around the Fedora 8
video driver issue. I have a working document that creates a PPC
oriented ISO file but the magic warning appears.
The PS3 system is my first exposure to the PowerPC way of doing things
and lack the background on how or if this is a serious issue or not.
Google searches bring back mkisofs pages like so
http://linux.about.com/library/cmd/blcmdl8_mkisofs.htm However, it
looks like the order of the -map and -magic directives avoid errors in
the pungi Anaconda builds as per the mkisofs man page.
mkisofs page
HFS CREATOR/TYPE
A Macintosh file has two properties associated with it which define
which application created the file, the CREATOR and what data the file
contains, the TYPE. Both are (exactly) 4 letter strings. Usually this
allows a Macintosh user to double-click on a file and launch the correct
application etc. The CREATOR and TYPE of a particular file can be found
by using something like ResEdit (or similar) on a Macintosh.
The CREATOR and TYPE information is stored in all the various Apple/Unix
encoded files. For other files it is possible to base the CREATOR and
TYPE on the filename's extension using a mapping file (the -map option)
and/or using the magic number (usually a signature in the first few
bytes) of a file (the -magic option). If both these options are given,
then their order on the command line is important. If the -map option is
given first, then a filename extension match is attempted before a magic
number match. However, if the -magic option is given first, then a magic
number match is attempted before a filename extension match.
My command string and error message.
/usr/bin/mkisofs -v -U -J -R -T -part -hfs -r -l -sysid PPC -no-desktop \
> -allow-multidot -chrp-boot \
> -map /prs/ppcbootiso/ppcboot/mapping \
> -magic /prs/ppcbootiso/ppcboot/magic \
> -hfs-bless /prs/ppcbootrespin/f8petitboot/ppc/mac \
> -V "F8 ppc respin" -o ../f8petitboot.iso \
> /prs/ppcbootrespin/f8petitboot
This program has been compiled without magic library support.
Ignoring the -magic option.
Warning: creating filesystem that does not conform to ISO-9660.
genisoimage 1.1.6 (Linux)
Please advise,
Greg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFHQQRZxyxe5L6mr7IRAoAPAKCKJlKhVcRuyxzL7VyQBS23w7UjbQCfWd01
My9SwpE+bv8M4hBB0XXH7u8=
=eQsE
-----END PGP SIGNATURE-----
16 years
Fedora 8 PPC and Playstation
by James Lapthorn
I am new to Fedora PPC and have decided to have a go at getting it
installed on my Playstation 3. Does anyone know of a good guide to
do this. I have read that the boot loader required for the PS3 is
located on the PPC dvd but am unable to find it. Does anyone know
where the otheros.bld file lives for Fedora 8?
James
16 years
Re: Dealing with PPC in Fedora 9(+)
by David Woodhouse
On Mon, 2007-11-12 at 09:14 -0500, Jesse Keating wrote:
> > I would like to stick to the agreement to keep PPC as a primary arch.
> > This is _also_ because the secondary arch framework isn't in place
> > yet.
>
> I'm making a compromise. I don't want to turn PPC into a full
> secondary arch yet either, however in the places that really aren't
> related to the buildsystem there is no reason why PPC can't take care
> of itself.
I certainly agree that we can reach such a compromise on the rel-eng/QA
side.
> No. The same tools have been used for Fedora 7 and 8. They've been
> developed on and improved, but its the same tools. They have to be ran
> on the arch they are composing, which means we can't easily use setarch
> to produce ppc trees/media like we do on x86. This requires those of
> us doing the compose to maintain a second machine and thread the output
> back into the other arches. There is also validation of the bits, time
> spent syncing them around, etc...
OK, cool. This kind of thing has been black magic for so long that I'd
mostly given up on trying to follow it. I may need a small amount of
babysitting, because I'm not very clever. But it sounds like it makes
sense for us to handle the composes for ourselves too, as you suggest.
We'd still want to put them in the 'normal' download location though,
for now.
> > It certainly makes sense for myself and other volunteers to take a
> > more active and _visible_ rôle in QA, I agree. I've been vaguely
> > aware of text matrices in the wiki, but I've never been sure that it
> > would be welcome for me to simply mark stuff off as 'tested'. I try
> > to just make sure that when it _is_ tested, it works.
>
> Will's repeated pleadings for people to help out have been missed?
> That's a shame.
Yes, they have. And yes, it is. If that's my fault, then I apologise --
Will, please do feel free to Cc me (and fedora-ppc(a)lists.infradead.org)
directly if you need assistance with anything related to PowerPC.
And if we're not paying sufficient attention to fora which we _should_
be monitoring, please point us at them and we'll try to do better.
> > > It would fall upon this team to host the bits for download at
> > > release time (if no suitable framework exists for hosting the bits
> > > elsewhere at various release points, rel-eng could insert them into
> > > the normal tree structure as a last resort).
> >
> > Let's not do this yet -- the hosting, and surrounding issues about
> > "Fedora" branding and mirroring, is a fairly important part of the
> > "secondary architecture infrastructure" which we agreed should be in
> > place and working for at least one other architecture _before_ we
> > switch PowerPC over to it.
>
> I'm not so sure that this is the "important" part.
Not "the" important part, I agree -- but "an" important part. One of the
things we want to be tested out by a guinea pig first :)
> It's really quite simple. If you're built from our bits, you can call
> it Fedora. Put it in a directory structure that would fit well with
> the rest of the mirror structure so that if mirrors chose to, they
> could spend their bandwidth and disk space on mirroring ppc (or other
> secondary arches).
Absolutely -- and in fact we already _have_ such a structure. Mirrors
can, and do, already choose which architectures to carry. I don't think
we need to change the location for Fedora 9. Especially if it's likely
to change again when we set it up properly for "secondary architectures".
> > > We would clearly advertise that PPC is to be considered a secondary
> > > arch.
> >
> > Advertise to whom and for what purpose? Precisely what is the message
> > that you'd be trying to convey? What effect would you want to achieve?
> > The term 'secondary arch' doesn't really mean a lot, in and of itself.
<...>
> What I want is for it to be clear that the quality of PPC is entirely
> up to the the user base for it. All too often the user base, even your
> self, just rely upon somebody else to find the problems, and you just
> come in late in the game or the release and see "yep, everything is
> still fine. No need to pay attention to alpha/beta/rawhide, it'll just
> work at release time and I don't have to care.".
Thanks, Jesse. Nice to know my work is entirely worthless. Here was I
thinking that I'd been running rawhide, and reporting and fixing bugs
(most of which didn't turn out to be arch-specific anyway).
Maybe I just imagined it.
<...deep breath...>
I certainly have no intention of relying on somebody else to find
PPC-specific problems. I start testing rawhide at about the same point
in each cycle that I've _always_ started testing rawhide, even in the
days where I was playing with RHL on i386. I was not aware that I came
to it "late in the game", and the bugs I find when I do this usually
turn out not to be PPC-specific. Perhaps I should start earlier.
> If every arch did that we would miss the majority of the bugs. The
> difference is on other arches, we have a very large set of users using
> it every day and testing it every day and reporting all the problems
> they find. We hear crickets from the ppc community.
I'm dubious about the validity or relevance of that observation. You
could just as well say that we hear crickets from the Kerberos-using
community. If I file or fix a bug which isn't arch-specific, I don't
mention PowerPC. Do you count me as an i386 user when I do that?
Arch-specific bugs make up a _small_ proportion of the total, in my
experience.
Anyway, if we agree that the PPC SIG will take on the task of QA for F9,
then that point is moot, is it not? If it isn't installable and "good
enough" in time, then it doesn't go out in sync with F9/x86.
> Advertising PPC as a secondary arch is a clear sign that the fate of
> ppc relies upon the users of that arch. If they don't step up and pay
> attention and report when there are issues, they'll likely get missed
> and wind up in the final release.
<...>
> I want to set the expectation that the BugFreeness of PPC relies on
> them the users actually using rawhide and the test releases to find the
> bugs,
OK, that makes some sense; thank you for clarifying. That being the
intention, the best time for this 'advertisement' doesn't seem to be
_now_, as you suggested -- it would be better to do it when we put out
the first release candidate tree. _That_ is when we want the testers to
be paying maximum attention.
It's also an issue which shouldn't directly concern you -- it's up for
the us (the PPC SIG) to whip our users into action when we believe we
need more from them.
> > if Fedora/PPC is significantly lower in quality than Fedora/i386
> > then we shouldn't release it as "Fedora" at all.
> Then /do/ something about it. Don't just rely on others to find your
> bugs, don't just rely on the release team to find all your bugs at the
> last moment, don't expect QA to spend a ton of effort finding your
> bugs
<...another deep breath...>
OK. Let's do it that way. I wish I'd thought of that earlier :)
> The way to accomplish this is to put the responsibility of producing
> the release upon those that would consume it.
OK. The PPC SIG will take on the responsibility of producing the
composes and doing the QA on them, for the F9 release. If we don't
manage that, it won't go out on PPC.
As you said, we don't need to make any changes to the build system or
the way rawhide is handled right now.
I don't believe it's realistic to make changes to the hosting and
mirroring arrangements either -- let's stick with the plan of keeping
them in the 'normal tree' which you called a last resort.
We'll plan to have each spin ready on time, so it can go out fairly much
synchronously with the i386 and x86_64 releases -- and more to the
point, with precisely the same package set. If for some reason we slip,
let's impose a rule that we may not ship any packages in the PPC spin
which are not in rawhide (for the RCs) or f9-updates (for the release).
OK?
--
dwmw2
16 years, 1 month
Why 'secondary architectures'?
by David Woodhouse
On Fri, 2007-11-09 at 14:06 -0500, Jesse Keating wrote:
> Now that Fedora 8 is out, I'd like to make a suggestion with regard to
> PPC. It's no secret that we've been talking about dropping PPC. First
> it was all together, then it was so that it could be come a secondary
> arch. So far, we've failed to execute.
Digressing from the technical side, I'd like to properly understand your
motivation. _Why_ do you want to do this?
I like Fedora. I like to see it expand and get used in places it
couldn't have been used before. I've always wanted to see it ported to
new architectures and made versatile enough to do new things -- to be
used as a basis for more than the bog-standard Linux desktop/small
server on a PeeCee.
I'd love to see more functionality -- more _possibilities_ -- merged
under the 'Fedora' umbrella.
As far as I can tell, you have the opposite desire. You seem to want to
reduce what we have -- even when something's _working_, you want to back
away from it -- disown it and all but abandon it. And even 'advertise'
that we're doing so -- you want to shout it from the rooftops that we're
backing into our corner.
Why?
We strive to ensure that PowerPC "Just Works™", when it comes to QA and
release time. I think we do a reasonably good job, don't we? Stuff slips
through occasionally, of course -- we should do more testing with
SELinux enabled, for example. But in general, I don't think we do badly.
So why do you constantly fight to throw out our work? What benefit do
you think this attitude brings to Fedora? I assume you don't _just_ do
it because you enjoy the massive slap in the face that we feel every
time you do it? :)
Have I missed a large amount of work which you personally need to do for
each release? Or missed a large store of 'private' bugs in bugzilla
which have never come to my attention? Or just misinterpreted the state
of Fedora on PowerPC despite the fact that I use it on all my primary
machines?
So what _is_ the motivation?
If Fedora/PowerPC is not good enough to be called 'Fedora', I will
heartily agree that we should stop calling it that. That isn't the case
though.
If Fedora/PowerPC causes a significant amount of work for you, we can
strive to take that load off you -- although I understood that's part of
what the "secondary architecture infrastructure" was _for_, and we'd
agreed that reclassifying Fedora/PowerPC would wait until that was in
place.
It can't be _just_ about the number of users -- I bet that there are
fewer users of Kerberos on Fedora than there are PowerPC users, but we
don't get people ranting after every release that they want to drop
Kerberos support. Our usage numbers are very tenuous anyway, and we
certainly can't factor in the bizarre things like the fact that Linus
chose Fedora _because_ it runs on PowerPC.
--
dwmw2
16 years, 1 month
Re: Dealing with PPC in Fedora 9(+)
by David Woodhouse
On Fri, 2007-11-09 at 14:06 -0500, Jesse Keating wrote:
> Now that Fedora 8 is out, I'd like to make a suggestion with regard to
> PPC. It's no secret that we've been talking about dropping PPC. First
> it was all together, then it was so that it could be come a secondary
> arch. So far, we've failed to execute.
That's not entirely true. We agreed that we would not change the status
of PowerPC until one new 'secondary architecture' had been added. We
have been working towards that goal, and progress has been made. Not all
of it has been entirely sensible, on the build system side, but stuff
_has_ happened.
> Starting now, I'd like to treat PPC as a pseudo secondary arch. This
> is because the secondary arch framework just isn't in place yet.
I would like to stick to the agreement to keep PPC as a primary arch.
This is _also_ because the secondary arch framework isn't in place yet.
> What would this mean? We'd continue to build ppc binaries as if it were
> a primary arch, this requires no change to Koji. We continue to make
> rawhide trees of it, this requires no change to buildrawhide (mash,
> pungi).
Sounds good so far :)
> However, come release time (Alpha/Beta/Pre Release/RCs/Final)
> it would fall upon a secondary arch team for PPC to create release
> trees and isos of the bits.
I'm not sure exactly what that means, because my visibility into those
parts of the release process has always been somewhat limited -- in fact
I usually mostly ignore the rc1/rc2/rc3 or alpha/beta/prerelease or
fish/monkey/turnip or whatever you want to call them this week, and just
poke at rawhide. I've always considered the 'RC' spins to be just a
confidence trick to get more victims^Wusers to install the stuff.
What does it actually take to create the RC spins? I thought it was
mostly just a case of running the same tools which run automatically to
build rawhide each night?
Given that those tools seem to change from release to release, it sounds
like having that done by a separate team is just make-work stuff, for
now. When we have other secondary architectures we'll want some kind of
process for it, but at the moment it sounds like it would just be easier
to keep running the same script three times instead of twice, surely?
> It would fall upon this team to QA the bits.
It certainly makes sense for myself and other volunteers to take a more
active and _visible_ rôle in QA, I agree. I've been vaguely aware of
text matrices in the wiki, but I've never been sure that it would be
welcome for me to simply mark stuff off as 'tested'. I try to just make
sure that when it _is_ tested, it works.
> It would fall upon this team to host the bits for download at
> release time (if no suitable framework exists for hosting the bits
> elsewhere at various release points, rel-eng could insert them into
> the normal tree structure as a last resort).
Let's not do this yet -- the hosting, and surrounding issues about
"Fedora" branding and mirroring, is a fairly important part of the
"secondary architecture infrastructure" which we agreed should be in
place and working for at least one other architecture _before_ we switch
PowerPC over to it.
> We would clearly advertise that PPC is to be considered a secondary arch.
Advertise to whom and for what purpose? Precisely what is the message
that you'd be trying to convey? What effect would you want to achieve?
The term 'secondary arch' doesn't really mean a lot, in and of itself.
Do you mean that you'd want to advertise to Fedora packagers that we
don't really care about stupid endianness bugs any more, and they can be
much more sloppy in their code?
Do you mean that you'd want to advertise to Fedora users that we won't
bother to look at bugs which happen to show up on PowerPC, unless
they're also reproduced on some other platform?
Do you mean that you just want to stick your fingers up at PowerPC
because you think RISC is the work of the devil? :)
Do you want to lower the expectations of Fedora users, so that they
don't expect Fedora/PowerPC to be as BugFree™ as Fedora/i386?
I think all of those are bad ideas. The first two because they'd reduce
the quality of Fedora code _overall_, the third because it's silly, and
the fourth because if Fedora/PPC is significantly lower in quality than
Fedora/i386 then we shouldn't release it as "Fedora" at all.
Ok, admittedly they were straw men... what _do_ you want to be saying?
> We would do this /now/ so that there is enough time for interested
> parties can form a team and have it in place to handle bug reports,
> composes, etc...
Is there an issue with the way that bug reports are handled already?
We keep the FE-ExcludeArch-ppc bug nice and empty, and the ppc64 version
as empty as it needs to be given that we favour 32-bit userspace.
Let's work towards making sure that F9 QA is done for you by those who
care about the platform. Tell us what you need done in that respect, and
we'll make sure it happens. But let's not change the hosting or other
arrangements until another arch has led the way, as previously agreed.
--
dwmw2
16 years, 1 month
