Re: Bug#23143: make-kpkg fails on Alpha
On 4 Jun 1998, Manoj Srivastava wrote:
> I'll sleep over this overnight; I am not convinced this is
> a normal level bug. There is nothing I can do about this in the first
> place; as I can't test it. The alpha developers have not seen it fit
> to add kernel-package compatibility; I fail to see why it should be a
> bug against my package.
This is partially my fault since I just haven't gotten around to hacking
kernel-package at all. I did notice the fault, but haven't had time to
correct it (and still don't, otherwise, I'd throw a patch together right
now for you). I agree with you as far as a "wishlist" since it would
require knowledge and access to an arch that you don't have.
> Nevertheless; I can't test the changes, and I would not have
> guesses go into the package. If they are that trivial, how about
> someone with access to an alpha making the modifications, testing the
> changes, and forwarding the diffs to me along with docs about MILO
> (changes from LILO are all that is really required).
I can describe a possible solution, if you're willing at this point to put
time into it. I can also put time into testing whatever changes you make
prior to making an "official" modification to the package (and hopefully,
by that time, I can hold off RL enough to patch some myself).
FYI, MILO is much different than LILO and would require some user
intervention at reboot time to enable a new kernel unless it was named the
same as the old one with the exact same location. MILO is more like a
bootloader that also loads PALcode than a boot-block-based boot manager.
Here's an albeit brief solution for make-kpkg:
1. Find a way to check the build architecture (dpkg --print-architecture
works, but may be inefficient to call. It does return just "alpha",
though, so if that helps...if you need more info, let me know and I'll
find a command to get it for you)
2. Check it against a list of arch's and set an "argument" variable
similar to how most newer library packages' rules files set a PRIMARY
and SECONDARY arch variable
3. Based on that variable, use "boot" instead of zImage or bzImage as the
argument to make when building the kernel.
There are other problems with building a kernel on the Alphas, but they
relate more to the existing kernel-source packages and not with make-kpkg
(other than the now-obvious difference in make command args), so fear not
when it comes to that :)
> If it is not a gzippped file, why is it not called vmlinuz? If
> it *is* a gzippped file, this underscores my lack of expertise with
> the alpha, and undescores the need for someone to hook up with me and
> help create a set of valid kernel-package modifications.
FYI, Alpha kernels are generated as gzipped files, but are named
vmlinux.gz for some odd reason. They are located in arch/alpha/boot
(same as other arch's basically). MILO doesn't care about the file name
as long as it can find the file itself (it still has problems following
links, unfortunately).
> This is not how the other architectures have it. The symlinks
> are created in /, not .boot, and I would prefer to be consistent, if
> at all possible.
I'll retest symlinks with MILO hopefully this week (I need to resolve that
issue for myself as well, so I would like to know for sure if improvements
have been made since last year about this). Either way, links may or may
not be important when it comes to Alphas since MILO will let you boot
different images without needing the same filename. I could point you
towards some MILO docs if you'd like, but be warned that they're sketchy
at times. Also, without console access to an Alpha, you would never be
able to see MILO in action to see what I am describing, unfortunately.
> I can make the preinst fail if on an alpha (provided I knoew
> what the architecture is called). However, this is not a good
> criterion to label the bug normal. A wishlist bug is a wishlist bug,
> assigning a higher priority so that some people may have a look at it
> is wrong.
I think we can work out what to do with preinst between us. I'm sure we
can find an easy solution, even if it means just having it fail for now :)
> Actually, we need to be able to specify exclusions in the
> architecture field, since kernel-package is not supported on the
> alpha.
I agree with this wholeheartedly. We've got TONS of packages that are
totally irrelevant on the Alpha that cause havoc for us when trying to
figure out what we need to do and what we don't.
> As I said before, I'll sleep on it. If I still feel the same
> way tomorrow, I shall lower the severity again to wishlist.
Treat it as you must, IMO. As long as we get the issue resolved sooner or
later, I'm sure the submitter of the bug originally will be happy :)
Chris
--
To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: