RE: An (flamebait ?) idea to preserve debian on sparc32...
Hi Jurij et all,
Is this using the link to initrd.img in /boot? I had to change my
symlink to read the full path for both vmlinuz and intrd, otherwise it
hangs on bootup as it couldn't find them ... I think.
i.e.
These symlinks hang: -
lrwxrwxrwx 1 root root 33 Jul 19 20:02 initrd.img ->
boot/initrd.img-2.6.12-1-sparc32
lrwxrwxrwx 1 root root 30 Jul 19 20:01 vmlinuz ->
boot/vmlinuz-2.6.12-1-sparc32
And these work fine: -
lrwxrwxrwx 1 root root 33 Jul 19 20:02 initrd.img ->
/boot/initrd.img-2.6.12-1-sparc32
lrwxrwxrwx 1 root root 30 Jul 19 20:01 vmlinuz ->
/boot/vmlinuz-2.6.12-1-sparc32
On boot, I see it creating the RAM disk and then releasing the memory
later on. Shall I post you a copy of a my kern.log from a bootup?
Cheers,
Steve
-----Original Message-----
From: Jurij Smakov [mailto:jurij@wooyd.org]
Sent: 31 July 2005 15:39
To: Steve
Cc: debian-sparc@lists.debian.org
Subject: RE: An (flamebait ?) idea to preserve debian on sparc32...
On Sat, 30 Jul 2005, Steve wrote:
> Well, I have mailed to this list before and said ...
>
> I have a SPARC 4 sun4m working quite happily with the 2.6.12-1-sparc32
> kernel running a fully upgraded sarge installation. Perhaps the
> reason for it being so happy is because this box is just being used a
> DNS/Syslog server with no monitor attached.
>
> Anyway, I shall continue to drop this bit of info into the list until
> someone explains why there seem to be so many issues when it would
> appear this box will run quite happily for quite some time before
> problems arise regarding new kernels or OS releases. Always willing
> to learn :-)
Hi Steve,
Unfortunately, the good old QA standard "it works for me" does not apply
in this case :-). I am aware of multiple problems with this kernel. To
mention a few:
* The kernel you tested does not have initrd support, unlike other
Debian
kernels. I could not boot it with initrd (panic on boot), so I
disabled
it. 2.4.27 boots fine with initrd.
* Debugging of the initrd problem indicated that occasionally (not every
time, so you can be just lucky) the basic memory-copying routine
corrupts the data it copies. That's a very serious problem, and I
don't
know an easy way to fix it. I suspect that this is responsible for
the
filesystem corruption under heavy load, I can reliably trigger it by
dist-upgrade, and in this case it corrupts dpkg status files, which
usually requires a reinstallation.
* I have an independent confirmation, that the success/failure of 2.6.12
kernel to boot is correlated to the locations of the memory chips in
the
slots.
I don't think it is acceptable to release a kernel with problems like
these to our users.
Best regards,
Jurij Smakov jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
Reply to: