Re: Help with a touchless, netbooted, preseeded installation of squeeze on lots of plugs
On 16/05/2012 19:39, Philip Hands wrote:
This is odd -- I preseed OpenRD systems, and don't seem to have this
problem.
Are you installing the uboot-mkimage package?
It seems that linux-image-2.6.32-5-kirkwood calls mkimage in its
postinst, so if you make sure your kernel does the same thing, and
ensure that that package is already installed, you may find that the
uImage& uInitrd get generated for you automatically.
Hi Phil,
thanks for your quick reply! I don't actually need a uInitrd - all the
requisite hardware support is compiled into my kernel. Also, due to the
non-standard way my kernel is installed (ie: the very last thing... in
the late_command with an in-target apt-get), it is not in place when the
installer gets around to the flash-kernel-installer stuff tries to do
its work (and fails). The installer does seem to install uboot-mkimage
but it fails because there is no kernel at the point where it is looking
for a "/vmlinuz or /boot/vmlinuz". In the preseed kernel selection bit,
I am using the options:
d-i base-installer/kernel/image string none
d-i base-installer/kernel/skip-install boolean true
... but this then leads on to the "Make the system bootable" error,
which I can't seem to preseed away.
Your line 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 :)
Sorry to be vague, but it all just worked on the OpenRD.
Anyway, if that works, you might be able to do your VFAT trick with a
symlink in /boot -- but actually that just sounds like you're using the
stock uboot, which is why you're restricted to VFAT (I'm assuming that
the uboot they put on dreamplugs at the factory is as decrepit as the
one on the OpenRD).
I'm not familiar with OpenRD but your assessment sounds about right...
For that reason, my automated installer includes an expect script that
uses the JTAG (helpfully provided as a mini-USB on OpenRDs) to flash a
more recent uboot onto the box, then set its defaults to boot from (in
my case) SATA, then tell the new uboot to PXE boot from the install
server, and the rest of the install goes through as a full preseed that
gets enough of cfengine onto the box to then install the services I
need.
Sadly, the dreamplug does not include JTAG by default -- otherwise I'd
have published all this already, as it would surely be useful for people
then, but I'm dubious that it's that useful if step 1 is "buy the dev
board" -- it's all very site specific at present too, so would need a
fair amount of work for anyone else to use.
Ah don't worry I have a JTAG - the Dreamplug has no on-board graphics so
everything is done via serial console (one of the reasons why the stock
kernel fails - it doesn't have support for this by default).
Also, I'm not necessarily recommending replacing the stock uboot. uboot
is a pain to get working quite often, and I wasted an inordinate amount
of time trying to get all of SATA, SD and flash booting working -- IIRC
the uboot I have now doesn't support SD booting on the OpenRD (it sees
the SD, but always gets CRC errors on the images), whereas the other one
I could have used doesn't support SATA -- so perhaps the quickest route
is to live with the VFAT limitation, and add a hook somewhere that
copies the images after they've been generated.
I'd rather avoid replacing the uboot if possible - it may be a bit
rubbish, but it works fine once you manage to get a uImage on the vfat
partition.
HTH
You did indeed :)
Cheers,
Dan
Cheers, Phil.
--
Senior Systems Administrator
NSMS (Network Systems Management Service)
Oxford University Computing Services
Reply to: