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:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]