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

Bug #349655 reported by StefanPotyra on 2009-03-27
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Stefan Bader

Bug Description

SRU justification (mainly for documentation for the security release as this issue has already been through SRU)

Impact: Due to a missing patch from upstream sparc fails to boot with Hardy kernels, currently in updates.

Fix: The patch has been integrated in the current proposed kernel and now also in the upcoming security release.

Testcase: boot fails on sparc without this



with this kernel from -security, spooky fails to boot.
ii linux-image-2.6.24-23-sparc64-smp (2.6.24-23.46)

This one is still working:
ii linux-image-2.6.24-22-sparc64-smp (2.6.24-22.45)

The issue is a little bit opaque, the new kernel doesn't leave any trace on serial console. Any logs I should check?

cat /proc/cpuinfo
>> cat /proc/cpuinfo
cpu : TI UltraSparc IIIi (Jalapeno)
fpu : UltraSparc IIIi integrated FPU
prom : OBP 4.8.2 2003/03/27 13:22
type : sun4u
ncpus probed : 2
ncpus active : 2
D$ parity tl1 : 0
I$ parity tl1 : 0
Cpu0ClkTck : 000000003bb94e80
Cpu1ClkTck : 000000003bb94e80
MMU Type : Cheetah+
CPU0: online
CPU1: online


StefanPotyra (sistpoty) wrote :

Hi Stefan,

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

Changed in linux (Ubuntu):
importance: Undecided → High
status: New → Triaged
StefanPotyra (sistpoty) wrote :


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.


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
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)

Reinhard Tartler, KeyID 945348A4

tags: added: regression-update
Stefan Bader (smb) wrote :

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

Changed in linux (Ubuntu):
assignee: nobody → stefan-bader-canonical
Stefan Bader (smb) wrote :

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.

StefanPotyra (sistpoty) wrote :

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,

StefanPotyra (sistpoty) wrote :


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


StefanPotyra (sistpoty) wrote :

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

StefanPotyra (sistpoty) wrote :

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?

Stefan Bader (smb) wrote :

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.

StefanPotyra (sistpoty) 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?

Stefan Bader (smb) wrote :

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.

Stefan Bader (smb) wrote :

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.

StefanPotyra (sistpoty) wrote :

Ok, tracked in bug #351572.

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

Stefan Bader (smb) on 2009-04-01
Changed in linux:
status: Triaged → In Progress
Stefan Bader (smb) wrote :

Has been included in security release.

description: updated
Changed in linux (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in linux (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments