[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

These symlinks hang: -
lrwxrwxrwx   1 root root     33 Jul 19 20:02 initrd.img ->
lrwxrwxrwx   1 root root     30 Jul 19 20:01 vmlinuz ->

And these work fine: -
lrwxrwxrwx   1 root root     33 Jul 19 20:02 initrd.img ->
lrwxrwxrwx   1 root root     30 Jul 19 20:01 vmlinuz ->

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?



-----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
   kernels. I could not boot it with initrd (panic on boot), so I
   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
   know an easy way to fix it. I suspect that this is responsible for
   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

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: