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

Re: (SOLVED) Help with a touchless, netbooted, preseeded installation of squeeze on lots of plugs

On 16/05/2012 17:17, Dan Tomlinson wrote:
Hi all,

I am trying to do something relatively advanced with the
debian-installer netboot and preseed. I have been charged with the
commissioning of a large number of Dreamplug armel machines with a
Debian squeeze installation and I am attempting to get a completely
touchless netboot install setup. I have achieved this to a large degree
but there are a few pesky key presses that I can't seem to preseed away.

This project, on the face of it should be simple, but the specifics of
the Dreamplug hardware have caused some problems for me:

- Stock Debian stable kernels do not work on this hardware. I have been
forced to patch, build and package my own kernel. My kernels work but I
can't install them via the normal preseed kernel selection for the
following reasons...

- The Dreamplug uboot bootloader needs a uImage installed into a special
vfat partition on its internal SD card, with the rest of the OS
installing to other partitions on the SD card.

- Debian's kernel package system does not seem to support building and
packaging uImages.

- The d-i will not allow /boot to be vfat anyway so my special vfat
partition needs to be mounted as something else (I chose /uboot).

To get around all of the above, I have created a rather simple kernel
package that just installs my custom uImage into /uboot and this is
"apt-get installed" from my own repo in my late_command (to allow me to
ignore the fact that my package is unverified).

This all works but for the following error that pops up at the end of
the installation:

┌─────────────────┤ [!!] Make the system bootable ├─────────────────┐
│ │
│ Installation step failed │
│ An installation step failed. You can try to run the failing item │
│ again from the menu, or skip it and choose something else. The │
│ failing step is: Make the system bootable │
│ │
│ <Continue> │
│ │

... and syslog reports:

May 16 16:16:33 in-target: Setting up uboot-mkimage (0.4) ...
May 16 16:16:34 in-target: Cannot find a default kernel in /vmlinuz or
May 16 16:16:34 flash-kernel-installer: error: flash-kernel failed
May 16 16:16:34 main-menu[805]: WARNING **: Configuring
'flash-kernel-installer' failed with error code 1
May 16 16:16:34 main-menu[805]: WARNING **: Menu item
'flash-kernel-installer' failed.

These errors are from the pre-built debian-installer from squeeze. I
have also tried building the the one from svn but this fails due to
uboot-mkimage changing to u-boot-tools and hence not being available in

Once I have navigated through the error and selected "Continue with no
boot loader" from the menu, the installation finishes without any
further issues and the installed system boots fine.

A colleague and someone on the IRC suggested trying the nobootloader
package so I put an "anna-install nobootloader" line in my early_command
but aside from syslog reporting that it is queued and then retrieved, it
doesn't make the problem go away.

So ... my question is - does anyone have an easy way to do one of the

a) Prevent the whole bootloader and kernel installation parts of the
installer from running and just go straight onto running late_command
and reboot.

b) Turn off that *** warning and get the installer to just fail quietly
then continue into late_command and reboot.

I realise I am well out of documented preseed territory here and any
solutions may require me to modify d-i source and build my own installer
- this is fine. I just thought I would ask the developers before I dived
into trying to hack this myself.

Many thanks in advance,

Dan Tomlinson

PS: I may have to commission hundreds of these plugs so I really is
worth my while to get this installation completely automated!

Hi all,

thanks to a quick reply off list from Philip Hands, I have found a solution to this!

He mentioned something about about the stock kernel install automatically calling uboot-mkimage made me think I should stop fighting the installer... let it do what it wants to do and install a non-working kernel, then just fix it up at the end :)

So - I found the solution! I let it install a stock kirkwood kernel (which wont work for this hardware), let the flash-kernel-installer do its stuff as it is supposed to, then in my late command I could remove the stock kernel and install mine instead - a quick switcheroo before reboot ;)

I wanted a more elegant solution, but at this stage *any* solution that doesn't involve hacking "exit 0" into installer modules seems desirable :)


Senior Systems Administrator
NSMS (Network Systems Management Service)
Oxford University Computing Services

Reply to: