srm nightmare, milo & kernel future questions
Hi, I'm new to this but I tried to do as much research as possible before
posting, so here goes...you can skip the paragraph of back story if you
just want to see my questions.
The "short" story is, I have an old PC164 Alpha (Enorex, 500Mhz) running
woody. I was running ARC, MILO, and 2.2.22 just fine, but I wanted to
upgrade to 2.4.18 because the security fixes on the 2.2 kernels haven't
made it into stable. I read up on this online, and apparently ARC/MILO
isn't "the future", SRM is, 2.4.18 needed initrd, and MILO doesn't support
initrd, and ARC doesn't support aboot, and SRM doesn't support PC
partitions, etc. So, I have this _HUGE_ dependeny chain of stuff I have to
do to my already working system, all of which has to come together at the
same time. I put it off for a while, and then finally bit the bullet and
did everything, and it was a nightmare[*], but I kinda got it
working. Except for a few important parts, hence my questions:
1. I am having the "SRM won't save the bootdef_dev and auto_action
variables" problem. At first I thought it was only on 2.4.18, but I've
seen it on 2.2.22 as well. The variables are saved if I just reboot from
the SRM console, but not if linux ever loads, which seems to indicate the
kernel hosing something, but who knows? From linux, shutdown -r sometimes
halts, and shutdown -h sometimes reboots. There are a lot of posts about
this problem and no one seems to know the real answer? This is important,
because now the machine can't be left alone or upgraded remotely because
reboots don't work.
2. After it was far far too late to turn back, I read a post from Herbert
Xu that MILO will support initrd with 2.4.20 because of a load address
change. ARGH! Is this true? In general, is ARC/MILO really going to not
work anymore in the future, or will it continue to be supported? I never
had any problem with ARC/MILO on this machine, ever. I would love to go
back to MILO if possible and try to forget all of this SRM madness.
3. I'm now trying to build the srm_env.o module by building the kernel
sources in the vain hopes that a shutdown script stuffing the SRM variables
will somehow save them. I copied the config-2.4.18-generic from /boot and
make menuconfig to save out autoconf.h, and make dep, and make vmlinux, and
gzipped it, but the kernel is a different size than the
vmlinuz-2.4.18-generic from the distribution. Compressed it's about 100kb
different, and uncompressed they're about 700kb different. Mine is much
bigger. What gives? I'm building with gcc 2.95.4. Is there some what to
find out what the distribution kernels were built with?
4. If I try to make modules it bombs on drivers/atm/ambassador.c. I don't
need this, but I'm trying to use the exact .config from the distribution to
avoid problems. Assuming there's a solution to this, can I then just turn
on CONFIG_SRM_ENV=m and make dep and rebuild vmlinux and modules (or do I
just need modules?) and get the srm_env.o, and then load it with my
-generic kernel? Or do I need to use the new kernel I just built? Do I
also need CONFIG_ALPHA_SRM on to build srm_env.o? The config script seems
to make a dependency between them, but the generic config doesn't have
either on and it boots from SRM just fine (except the variables thing).
Thanks,
Chris
[*] Nightmare: repartition the running system with sdisklabel from PC to
BSD, very poorly documented; flash the BIOS with the "latest" SRM from
DEC, except the ARC bios in the machine was newer than the "latest" ARC
from DEC, so it's clear I can never go back; find out after rebooting that
SRM doesn't support the SCSI harddisk I'm using; boot off a floppy (go
through 10 bad floppies); install IDE hard drive, format it, partition it,
put aboot/kernel/etc on it, pointing towards the original SCSI drive as
root for the kernel; repartition IDE so /boot can be a mount from it so
upgrades will work; gnu parted is a broken pile that only allows you to
specify sizes in MB instead of sectors; aboot doesn't recognize the new
partition; repartition from scratch with sdisklabel; find that SRM doesn't
save settings as outlined above; can't build kernel correctly; etc etc
etc. Basically, it's taken 3 full 10 hour days, and counting. Everything
went wrong that could.
Reply to: