netboot image fails to boot.

Bug #541399 reported by Tobin Davis
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
debian-installer (Ubuntu)
Fix Released
Medium
Steve Langasek
linux-mvl-dove (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Netboot image from http://ports.ubuntu.com/dists/lucid/main/installer-armel/current/images/dove/netboot/dove/ fails to boot when loaded from usb manually. Everything in uboot seems ok. After launching the bootm command in uboot, uboot loads the kernel, then nothing. No serial console logs, no output beyond starting kernel.

tags: added: iso-testing
tags: added: kernel-series-unknown
Steve Langasek (vorlon)
Changed in linux-mvl-dove (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Michael Casadevall (mcasadevall) wrote :

Tobin: what was the kernel command line you set in bootargs?

tags: added: lucid
removed: kernel-series-unknown
Revision history for this message
Tobin Davis (gruemaster) wrote :

setenv bootargs console=ttyS0,115200 console=tty0

Revision history for this message
Eric Miao (eric.y.miao) wrote :

Confirmed. Michael, how was this kernel generated and based on which version?

Revision history for this message
Eric Miao (eric.y.miao) wrote :

Michael,

This is root caused to be the incorrect setting of loading and entry point of the resulted uImage.

$> mkimage -l casper/uImage.netboot
Image Name: Debian kernel
Created: Fri Apr 2 06:21:22 2010
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3392060 Bytes = 3312.56 kB = 3.23 MB
Load Address: 0x00000000
Entry Point: 0x00000000

While a correct one looks like below:

$> mkimage -l casper/uImage
Image Name: Ubuntu Kernel
Created: Wed Mar 17 17:56:04 2010
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3377896 Bytes = 3298.73 kB = 3.22 MB
Load Address: 0x00008000
Entry Point: 0x00008000

After regenerated the uImage with 0x0000_8000 as the load address and entry point, the resulted uImage booted OK here at my side. It's currently not possible to arbitrarily place the load address and entry point to anywhere for ARM kernels.

Changed in linux-mvl-dove (Ubuntu):
assignee: nobody → Michael Casadevall (mcasadevall)
milestone: none → ubuntu-10.04
status: New → Triaged
Revision history for this message
Steve Langasek (vorlon) wrote :

The load address and entry point are being set by a call to mkimage within debian-installer, which generates the netboot images from the existing kernels in the archive. I've committed the fix to bzr for upload post-beta.

affects: linux-mvl-dove (Ubuntu) → debian-installer (Ubuntu)
Changed in debian-installer (Ubuntu):
assignee: Michael Casadevall (mcasadevall) → Steve Langasek (vorlon)
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package debian-installer - 20081029ubuntu96

---------------
debian-installer (20081029ubuntu96) lucid; urgency=low

  * build/config/armel/dove/netboot.cfg: set the right load address in the
    netboot image. LP: #541399.
 -- Steve Langasek <email address hidden> Fri, 09 Apr 2010 17:31:56 -0700

Changed in debian-installer (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Tobin Davis (gruemaster) wrote :

Moved back to in-progress. Fix above only fixes the kernel uboot loader issue. Now the system needs to know what to do once the kernel and initrd are loaded. Currently, with the same boot parameters as imx51 (console=ttyS0,115200 console=tty0), the kernel initializes the system properly, but dies trying to find the rootfs. More debugging needed.

Changed in debian-installer (Ubuntu):
status: Fix Released → In Progress
Revision history for this message
Oliver Grawert (ogra) wrote :

this is very likely caused by the fact that debian-installer does not build an initramfs but an initrd for dove (unlike the other armel architectures)

ogra@osiris:~/Devel/branches/debian-installer/ubuntu$ grep INITRD_FS ./build/config/armel/imx51/netboot.cfg
INITRD_FS = initramfs
ogra@osiris:~/Devel/branches/debian-installer/ubuntu$ grep INITRD_FS ./build/config/armel/omap/netboot.cfg
INITRD_FS = initramfs
ogra@osiris:~/Devel/branches/debian-installer/ubuntu$ grep INITRD_FS ./build/config/armel/dove/netboot.cfg
ogra@osiris:~/Devel/branches/debian-installer/ubuntu$

we will likely need to set the INITRD_FS variable here as well, else it will default to build an initrd which i'm not sure the dove kernel even supports.

Revision history for this message
Tobin Davis (gruemaster) wrote :

Here is the bootlog from the uImage and uInitrd downloaded from http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/20081029ubuntu97/images/dove/netboot/dove/.

Of note is line 299: [ 29.328117] RAMDISK: incomplete write (13368 != 32768)

Revision history for this message
Tobin Davis (gruemaster) wrote :

Resolved! For some reason, the uInitrd file from above is corrupted. Downloading http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/20081029ubuntu97/images/dove/cdrom/initrd.gz and running mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0 -e 0x0 -n "debian-installer ramdisk" -d initrd.gz uInitrd works. Please update debian-installer accordingly.

Revision history for this message
Oliver Grawert (ogra) wrote :

committed, will be fixed with the 20081029ubuntu98 debian-installer upload

Changed in debian-installer (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Oliver Grawert (ogra) wrote :

just for clearification:
the cdrom/initrd.gz uses INITRD_FS = initramfs in dove/cdrom.cfg
the applied fix adds the same variable to dove/netboot.cfg

Revision history for this message
Loïc Minier (lool) wrote :

Eric: could you confirm the correct values for the uInitrd as well?

Revision history for this message
Loïc Minier (lool) wrote :

Adding a kernel task to fix the ramdisk size which is currently 4096 in the config and should 65536 as in the other kernels.

@Oliver: I am not sure this is fix committed for debian-installer; Tobin did pass root=/dev/ram0 but that's not enough.

Apparently the initrd load address is incorrect in the generated uInitrd since it works if he generates the uInitrd himself.

affects: linux-ti-omap (Ubuntu) → linux-mvl-dove (Ubuntu)
Revision history for this message
Loïc Minier (lool) wrote :

@Eric: also, we currently use different load addresses in the live images:
        uboot_kernel_addr="0x00200000"
        uboot_ramdisk_addr="0x01100000"
        uboot_script_addr="0x1000"

the boot script being:
if test -n \${fs} && test -n \${interface} && test -n \${device}; then
        \${fs}load \${interface} \${device} $uboot_kernel_addr $uboot_kernel
        \${fs}load \${interface} \${device} $uboot_ramdisk_addr $uboot_initrd
        setenv bootargs quiet splash $DEFAULT_PRESEED $uboot_extra_cmdline
        bootm $uboot_kernel_addr $uboot_ramdisk_addr
fi

Do these need to be fixed as well?

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package debian-installer - 20081029ubuntu98

---------------
debian-installer (20081029ubuntu98) lucid; urgency=low

  [ Oliver Grawert ]
  * add boot.scr to boot OMAP netinst kernel and initrd from SD card
  * make sure dove also uses INITRD_FS = initramfs for netboot, else it fails
    to uncompress the initrd LP: #541399.
 -- Steve Langasek <email address hidden> Tue, 13 Apr 2010 12:54:36 -0700

Changed in debian-installer (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Eric Miao (eric.y.miao) wrote :

@lool: my understanding is this is specific to kernel uImage. uInitrd - when placed safely after any place the decompressed kernel image occupies, will be OK.

Revision history for this message
Loïc Minier (lool) wrote :

Ok; thanks

Revision history for this message
Loïc Minier (lool) wrote :

(Tobin confirmed that the d-i images work without rebuilding the uinitrd too)

Revision history for this message
Loïc Minier (lool) wrote :

Filed bug #563679 for the kernel config option.

Changed in linux-mvl-dove (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.