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

Re: network-console on armhf



On Sun, 2016-01-03 at 14:41 -0800, Martin Michlmayr wrote:
> I'm in the process of adding support for some NAS devices that use
> armhf.  They will use network-console for the installation.
> 
> I have 2 questions I wanted to discuss:
> 
> 1) Preseeding the network: on armel, we use oldsys-preseed to read the
> existing network configuration file from the firmware to create a
> preseed file.  Originally, I thought this was an elegant solution but
> over the years I've come to doubt whether this approach makes sense and
> think we should just default to DHCP with a fallback IP address.

I think this makes sense.

> So imho we have three options:
> 
> 1) Use oldsys-preseed and add "fake" entries for new devices that will
> just default to DHCP (as done for LaCie on armel recently)
> 
> 2) Add a preseed file to the ramdisk that will do DHCP
> 
> 3) Do nothing and require users to add a preseed file
> 
> I don't like 3) since that would require users to unpack and repack
> the ramdisk.

FWIW you can append new initrd's together and the kernel will do the right
thing, which is probably the best way for any user to add a preseed (for
this or any other purpose).

(only gotcha I know of is that if you want to include foo/bar/baz.conf in
the cpio then you must include foo and foo/bar as explicit directory
entries too, I never looked up if this was a part of the cpio spec or a
consequence of the implementation of Linux's unpacker).

> Do you have any preferences?  And is anyone using network-console on
> armhf yet? (Just wondering if I can make changes without breaking
> things)

Hector added it along with all the other armhf images way back. I suspect
this was just because armel had them rather than a specific need, but maybe
he can comment.

I've also added Karsten because I have a vague feeling he was interested in
network-console for sunxi at some point (or maybe I saw a thread between
him and someone who was interested, or maybe I'm making things up).

> 2) Kernel/ramdisk and uImages
> 
> At the moment, armhf requires users to append the DTB and generate an
> uImage.

I don't think all platforms require this. Many more modern ones (i.e. all
sunxi ones, I think) support separate DTB and booting direct from the
zImage without a uImage wrapper.

>   Obviously, the same approach would work for these NAS devices
> but I'd like to make it as easy for users as possible.  So I was
> thinking of generating uImage/uInitrd files as part of the d-i
> process.  But if I do it for these NAS devices, you could argue we
> should do it for all devices and that would be a lot of images.  So,
> again, I wanted to hear what people think.

Karsten made the SD-card images[0] consist of a base + platform specific
thing which the user cats together to avoid the enormous amount of space
duplication here. I think network-console should probably follow suite.

It might even be possible to have the need for a separate network-console
installer flavour go away by concatenating the normal netboot initrd with a
one containing the preseeding to enable network-console and the platform
specific bits.

(I just now had a little idea for a webservice which has drop downs for
arch, suite, platform etc which cats the relevant bits together
automatically for you on the fly, hrm, wonder if that can be done while
causing the actual data to go direct from the mirror to the client browser
without laundering through the web machine, probably not due to XSS
protections etc).

Ian.

[0] ftp://ftp.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/


> (I should add that for these devices you need a tool that probably
> only works on Linux to configure u-boot, so maybe it's not too much to
> expect users to generate their own uImage.)
> 


Reply to: