[hardy][sparc]: new kernel in security doesn't boot

Hi Stefan,

Can you comment how far into the boot it is able to get?

Hi,

it *looks* like it's not getting very far. Last thing displayed on serial console is the "Booting" message from the kernel, then nothing seems to happen.

HTH,
   Stefan.

Leann Ogasawara <email address hidden> writes:

> Can you comment how far into the boot it is able to get?

output from serial console:

SC Alert: Host System has Reset

Sun Fire V240, No Keyboard
Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.8.2, 8192 MB memory installed, Serial #11112456.
Ethernet address 0:3:ba:XX:XX:XX, Host ID: 8334XXXX.

Boot device: disk File and args:
SILO Version 1.4.13
boot:
Allocated 8 Megs of memory at 0x40000000 for kernel
Uncompressing image...
Loaded kernel version 2.6.24
Loading initial ramdisk (6992997 bytes at 0x1300000000 phys, 0x40C00000 virt)...
/
Remapping the kernel... done.
OF stdout device is: /pci@1e,600000/isa@7/serial@0,3f8
Booting Linux...

Then nothing more appears, and we have to reboot machine via ALOM.

(mac and hostid altered)

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Have you tried the current kernel from proposed? IIRC there was one patch that did not get included and caused problems for sparc64.

Actually it would be good if you could try those kernels at: http://people.ubuntu.com/~smb/bug349655/
Given it works with that kernel, this could go into the next security update which is happening soon.

Hi Stefan,

sure thing, will do... however I won't come around until Monday to test it (I don't have access to serial console until I exchange cables... and on Monday, I can easily go down to the location of spooky again and do some plugging ;))

Cheers and thanks,
      Stefan.

Hi,

excellent, the one from -proposed works:

>> uname -a
Linux spooky 2.6.24-24-sparc64-smp #1 SMP Wed Mar 25 12:55:02 UTC 2009 sparc64 GNU/Linux

Thanks,
    Stefan.

The kernel p.u.c works as well:

>> uname -a
Linux spooky 2.6.24-23-sparc64-smp #1 SMP Fri Mar 27 22:50:34 UTC 2009 sparc64 GNU/Linux

hm... s.th. just ate my silo.conf (i.e. made a link from /etc/silo.conf to /boot/silo.conf, which is now no longer existant). What I've done is upgrading from the package posted on people.ubuntu.com to the package from proposed again. Is this related to the package in -proposed, or just a side effect from the package on p.u.c?

StefanPotyra wrote:
> hm... s.th. just ate my silo.conf (i.e. made a link from /etc/silo.conf

That is odd. Both packages use the same build/configuration. Just the one in
-proposed is more recent and has a few other fixes. None of those should act
any different from each other. The code that runs on installation has not
changed in ages.

Well, the one from p.u.c has the modules all in one package, maybe that's somehow related?
Should I file a separate bug about this?

StefanPotyra wrote:
> Well, the one from p.u.c has the modules all in one package, maybe that's somehow related?
> Should I file a separate bug about this?
>
Can you specify which? What is true is that the kernel from proposed needs
updated version from lum, lrm as the abi changed. The one compiled for p.u.c
has the same abi version as the current security kernel and doesn't need any
upgraded depending packages. Both kernel packages should bring a certain set of
modules in the package. And it should be (more or less) the same.

StefanPotyra wrote:
> Should I file a separate bug about this?

Oh and, yeah. We should file this as a separate bug. Not sure how reproducible
that is.

Ok, tracked in bug #351572.

Oh, and I was confused about the modules, these are indeed (only) the standard modules, sorry.

Has been included in security release.

This bug was fixed in the package linux - 2.6.24-23.52

---------------
linux (2.6.24-23.52) hardy-security; urgency=low

  [Stefan Bader]

  * rt: Fix FTBS caused by shm changes
    - CVE-2009-0859

  [Steve Beattie]

  * fix apparmor memory leak on deleted file ops Bug: #329489
    - LP: #329489

  [Upstream Kernel Changes]

  * NFS: Remove the buggy lock-if-signalled case from do_setlk()
    - CVE-2008-4307
  * sctp: Avoid memory overflow while FWD-TSN chunk is received with bad
    stream ID
    - CVE-2009-0065
  * net: 4 bytes kernel memory disclosure in SO_BSDCOMPAT gsopt try #2
    - CVE-2009-0676
  * sparc: Fix mremap address range validation.
    - CVE-2008-6107
  * copy_process: fix CLONE_PARENT && parent_exec_id interaction
    - CVE-2009-0028
  * security: introduce missing kfree
    - CVE-2009-0031
  * eCryptfs: check readlink result was not an error before using it
    - CVE-2009-0269
  * dell_rbu: use scnprintf() instead of less secure sprintf()
    - CVE-2009-0322
  * drivers/net/skfp: if !capable(CAP_NET_ADMIN): inverted logic
    - CVE-2009-0675
  * Ext4: Fix online resize block group descriptor corruption
    - CVE-2009-0745
  * ext4: Initialize the new group descriptor when resizing the filesystem
    - CVE-2009-0745
  * ext4: Add sanity check to make_indexed_dir
    - CVE-2009-0746
  * x86-64: syscall-audit: fix 32/64 syscall hole
    - CVE-2009-0834
  * x86-64: seccomp: fix 32/64 syscall hole
    - CVE-2009-0835
  * shm: fix shmctl(SHM_INFO) lockup with !CONFIG_SHMEM
    - CVE-2009-0859
  * apparmor: Fix handling of larger number of profiles
    - LP: #345144
  * udf:SAUCE (drop after 2.6.30): Fix oops when invalid character in
    filename occurs
    - LP: #321606
  * Fix memory corruption in console selection
    - CVE-2009-1046
  * SPARC64: Loosen checks in exception table handling.
    - LP: #301608, #349655

 -- Stefan Bader <email address hidden> Mon, 16 Mar 2009 18:39:14 +0100