2:59 p.m.
Okay, I've finally gotten around to merging dwmw2's changes for ppc
support in livecd-creator. First off, thanks for getting the ball
rolling.
Of course, now the fun part is that it would be nice to be able to
support both ppc and ppc64 with the images. There are a few barriers to
that as it currently stands.
The biggest is probably that the ppc and ppc64 kernels currently
conflict. The actual vmlinuz files as well as the modules end up under
the same paths. Without that fixed, it's a bit of a non-starter. Maybe
it finally makes sense to make the paths depend on uname -m in addition
to uname -r? Other ideas?
If we get that fixed, the livecd-creator side of things shouldn't be
that bad to do. Mainly just making it so that we handle multiple
kernels (which kanarip has a patch for, just need to finish getting it
into a merge-ready state) and then a little of the 3264 logic out of
anaconda's scripts.
Jeremy
10:43 p.m.
On Wed, 2007-08-15 at 15:59 -0400, Jeremy Katz wrote:
Okay, I've finally gotten around to merging dwmw2's changes
for ppc
support in livecd-creator. First off, thanks for getting the ball
rolling.
Ah, cool. Thanks.
Of course, now the fun part is that it would be nice to be able to
support both ppc and ppc64 with the images. There are a few barriers to
that as it currently stands.
Indeed. I was planning to get to that after we'd got the groundwork
merged.
The biggest is probably that the ppc and ppc64 kernels currently
conflict. The actual vmlinuz files as well as the modules end up under
the same paths. Without that fixed, it's a bit of a non-starter. Maybe
it finally makes sense to make the paths depend on uname -m in addition
to uname -r? Other ideas?
That was certainly one of the potential solutions I'd thought of. Others
were more hackish, like installing each kernel into its own chroot and
then setting up a symlink as early as possible in boot so
that /lib/modules/$(uname -r) points to the right place. And after the
installation to a real hard drive, you _move_ the appropriate one into
the right place and delete the other.
It would be nice if whatever solution we settle on ends up with only the
'proper' kernel installed, not both. Not mandatory though, I suppose --
as long as yum isn't going to keep updating both, and letting the user
boot the 'wrong' ones.
I suppose one way to help with that particular problem would be to put a
hack into yaboot where we can mark each boot option as 32-bit or 64-bit,
and then have yaboot filter out the ones which aren't appropriate to the
system we're running on at the time. That would actually be cute for the
straight DVD install on non-Mac too.
But if we can avoid having the 'wrong' kernels installed even alongside
the 'right' kernel, when we've installed from LiveCD, that's probably
the best answer. Right?
If we can change the $(uname -r) so that kernels and install them in
parallel, presumably you'll rpm -e the unwanted one after install?
If we get that fixed, the livecd-creator side of things shouldn't
be
that bad to do. Mainly just making it so that we handle multiple
kernels (which kanarip has a patch for, just need to finish getting it
into a merge-ready state) and then a little of the 3264 logic out of
anaconda's scripts.
Cool. I should be home this weekend, and in a position to screw with it
on various 32-bit and 64-bit hardware (including PS3, although PS3 is a
bit too memory-starved to be running swapless).
--
dwmw2
10:50 p.m.
On Thu, 2007-08-16 at 11:43 +0800, David Woodhouse wrote:
(including PS3, although PS3 is a bit too memory-starved to be
running
swapless).
I assume the LiveCD looks for swap partitions when it starts and will
try to use them?
Could we make it also notice when it's running on a really
memory-starved machine, and prompt early during startup...
"Your machine has only 256MiB RAM. It will need to use swap.
Would you like to create a swap partition on your hard drive now?"
Bonus points for being able to use swap on a FAT partition, I suppose --
if you always use the same filename isn't that relatively easy to scan
for at boot? If it's named like a swapfile and it _looks_ like a
swapfile, it's relatively safe to try swapon, right?
--
dwmw2
10:15 a.m.
On Thu, 2007-08-16 at 11:43 +0800, David Woodhouse wrote:
On Wed, 2007-08-15 at 15:59 -0400, Jeremy Katz wrote:
> Of course, now the fun part is that it would be nice to be able to
> support both ppc and ppc64 with the images. There are a few barriers to
> that as it currently stands.
Indeed. I was planning to get to that after we'd got the groundwork
merged.
After I wrote this, I _think_ I got most of the livecd pieces in place
ppc64 kernels. Didn't get a chance to test the created disc before I
had to leave the office, though, and I'm wfh today. Will be in tomorrow
to try it out.
> The biggest is probably that the ppc and ppc64 kernels
currently
> conflict. The actual vmlinuz files as well as the modules end up under
> the same paths. Without that fixed, it's a bit of a non-starter. Maybe
> it finally makes sense to make the paths depend on uname -m in addition
> to uname -r? Other ideas?
That was certainly one of the potential solutions I'd thought of. Others
were more hackish,
Hackish, indeed... I think that encoding the arch might be the cleanest
thing. And it allows some other things down the road too
It would be nice if whatever solution we settle on ends up with only
the
'proper' kernel installed, not both. Not mandatory though, I suppose --
as long as yum isn't going to keep updating both, and letting the user
boot the 'wrong' ones.
We can probably put something into anaconda to do removal of the
non-relevant kernel after the install. It's going to be a little ugly,
but I don't see any way around it.
> If we get that fixed, the livecd-creator side of things
shouldn't be
> that bad to do. Mainly just making it so that we handle multiple
> kernels (which kanarip has a patch for, just need to finish getting it
> into a merge-ready state) and then a little of the 3264 logic out of
> anaconda's scripts.
Cool. I should be home this weekend, and in a position to screw with it
on various 32-bit and 64-bit hardware (including PS3, although PS3 is a
bit too memory-starved to be running swapless).
Any help and testing would be much appreciated; the goal being to have
ppc live images available for test2 even if there are a few rough edges
still
Jeremy
10:20 a.m.
On Thu, 2007-08-16 at 11:50 +0800, David Woodhouse wrote:
On Thu, 2007-08-16 at 11:43 +0800, David Woodhouse wrote:
> (including PS3, although PS3 is a bit too memory-starved to be running
> swapless).
I assume the LiveCD looks for swap partitions when it starts and will
try to use them?
Right now we don't, but that's something that I'm pretty convinced needs
to change anyway. We just need to be sure AUTOSWAP=yes
in /etc/sysconfig/init and then the right thing will happen. And
probably add an override for disabling it.
Could we make it also notice when it's running on a really
memory-starved machine, and prompt early during startup...
[snip]
Bonus points for being able to use swap on a FAT partition, I suppose
--
if you always use the same filename isn't that relatively easy to scan
for at boot? If it's named like a swapfile and it _looks_ like a
swapfile, it's relatively safe to try swapon, right?
Doing something like this would tie in a bit with some of the persistent
change work that Douglas McClendon is working on. It's not that
different in what's being done, so it probably makes sense to just
extend that infrastructure. Asking is a little trickier, just because
of input, locales, etc... but if we're even to where we can use it
automatically and you just have to do a certain setup in advance, it's
not too bad I don't think. At least for at first
Jeremy
11:48 p.m.
On Thu, 2007-08-16 at 11:15 -0400, Jeremy Katz wrote:
> > The biggest is probably that the ppc and ppc64 kernels
currently
> > conflict. The actual vmlinuz files as well as the modules end up under
> > the same paths. Without that fixed, it's a bit of a non-starter. Maybe
> > it finally makes sense to make the paths depend on uname -m in addition
> > to uname -r? Other ideas?
>
> That was certainly one of the potential solutions I'd thought of. Others
> were more hackish,
Hackish, indeed... I think that encoding the arch might be the cleanest
thing. And it allows some other things down the road too
Yeah. I have a feeling there were problems with putting the arch (or
even a letter signifying it) unto $(uname -r). Can't actually remember
them right now, so maybe I'm imagining it.
It would also help to stop people compiling kernel modules against the
wrong-arch kernel-devel package (i586 vs. i686) too, right?
--
dwmw2
6097
days inactive
6099
days old
5 comments
2 participants
participants (2)
-
David Woodhouse -
Jeremy Katz