Netboot: Use of Serial Number as Image Identifier

[Synoia]

We like to request a modification the the file path naming approach in the netboot function of the PI. The approach, using the serial number imposes very difficult and expensive requirements on an enterprise (large number of PIs).

Model number or model number-rev number to identify the firmware kernel would be a better approach.

If a PI does not work, that is it does not have a directory in the file service, the serial number needs to be visible on an unpowered machine. If the serial number is burnt into the silicon, or NVRAM on the board, how does the use access the serial number when on the phone to the help desk?

Silkscreen on the board is a bad idea. Now the user has to open the case. Labels which peel off do not help, inconsistencies happen.

We believe the serial number based solution does not scale, managing the boot directories for 500 or 1,000 people would create a new industry by itself.

We should not confuse asset management with version management.

[ghollingworth]

I don't actually understand what it is that you are trying to do, why would you want a different firmware/kernel dependant upon the version of the Raspberry Pi?

[Synoia]

The current netboot implementation, or implementation proposal, appears to use the pi serial number in the path get to a directory/file for the correct firmware.
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md
For large installations serial numbers appear to have difficulties. If one has 500 PIs, the the serial number approach to firmware path location on the file server results on 500 directories, many duplicated.
We are asking for the directory path to be ../pi-model, or ../pi-model/rev instead or ../serial-number to reduce the number of directories on the file server for large networks of netboot PIs.
Serial number are problematic also because the serial number might not be available to a user in a lage department with a PI that will not netboot, and the only way to identify the actual PI is to read the serial number, which might be impossible in a powered off state.
Thanks
Duncan Hare

714 931 7952

  From: Gordon Hollingworth <notifications@github.com>

To: raspberrypi/firmware firmware@noreply.github.com
Cc: Synoia dh@Synoia.com; Author author@noreply.github.com
Sent: Friday, August 26, 2016 11:34 AM
Subject: Re: [raspberrypi/firmware] Netboot: Use of Serial Number as Image Identifier (#648)

I don't actually understand what it is that you are trying to do, why would you want a different firmware/kernel dependant upon the version of the Raspberry Pi?—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Synoia]

On consideration based on our focus on the enterprise market we'd prefer the start.elf to be on the sd card and use the DHCP parameters to download the kernel & dtb, and then the kernel mount the filesystem when the kernel starts.
Logistically the Pis go directly from the factory (or warehouse) to the customer and are fitted with the correct sd card, and then placed in service, and are touched individually by human hands once only.
Having to boot all the Pis and then attach to the network for boot opens up great avenues for the installers to make mistakes.

We'd live with being unable to update the firmware. We not replace the SDCards for the life of the PI, which we estimate at 3 years.
 Duncan Hare

714 931 7952

  From: Gordon Hollingworth <notifications@github.com>

To: raspberrypi/firmware firmware@noreply.github.com
Cc: Synoia dh@Synoia.com; Author author@noreply.github.com
Sent: Friday, August 26, 2016 11:34 AM
Subject: Re: [raspberrypi/firmware] Netboot: Use of Serial Number as Image Identifier (#648)

I don't actually understand what it is that you are trying to do, why would you want a different firmware/kernel dependant upon the version of the Raspberry Pi?—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[ghollingworth]

But you don't have to use a serial number, you can just put all the files into the base tftpboot directory along with the bootcode.bin and every device will pick it up from there...

So you only need one copy of the firmware.

Is there any reason why you would need different firmware for different versions of Pis? Currently all Raspbian releases will run equally well on all models of Raspberry Pi so you don't need different versions of the software for different versions of the hardware.

Otherwise it would be possible to create a special linux build that you put into the base directory that is used for Raspberry Pis that have no serial number stored on the server. This build boots up and automatically executes a script (you can I think just do this using a cmdline parameter of init=myscript.sh) which can then check the revision number and log into the server to create a new symbolic link for it's serial number, then reboot...

I'd rather not add another method for doing this since it delays booting to check every possible place for a build

[Synoia]

Gordon
Thanks. My misunderstanding. I believe after reading the spec the serial number was required in the path.
Yes we will want to run different copies of firmware, under change control procedures, test, pilot and deploy, for rev 1, rev 2, rev 3 and so on.

Introducing changes, is an incremental, phased and careful process. Roll forward and roll back are requirements, because changes have the potential to be disruptive, and need to be managed. Symbolic links provide such a mechanism.
This means some group of PIs will have a different keyword in the directory path than others, a pilot group for example, so keywords could be one of "Test, Pilot, Production" and configuring that keyword, and a cache for monitor configurations in the PI seems to then drag in the requirement for an sdcard.
Different keywords need to be visibly distinguishable by installation people on unpowered machines in a easy manner. Differently colored sd cards help here, and the configuration process does not impose inventory management problems on a supply of spare PIs, any PI can be assigned any role with the appropriate sd card.

The process to configure a PI to netboot, we also need to discuss. Our potential customers cannot use a product with two modes of operation, netboot and non-netboot which are visibly indistinguishable, and again we want to both make an inventory of spares easy to manage, for both us and our customers, there is but one part, and it is configured by the appropriate colour coded sd card, or equivalent.
Yes, one has to control an inventory of sd cards. In an emergency, have a sd card color code which means "temporary fix" rules, or break the rules, and go back and resolve it later.
Duncan Hare

714 931 7952

  From: Gordon Hollingworth <notifications@github.com>

To: raspberrypi/firmware firmware@noreply.github.com
Cc: Synoia dh@Synoia.com; Author author@noreply.github.com
Sent: Friday, August 26, 2016 11:02 PM
Subject: Re: [raspberrypi/firmware] Netboot: Use of Serial Number as Image Identifier (#648)

But you don't have to use a serial number, you can just put all the files into the base tftpboot directory along with the bootcode.bin and every device will pick it up from there...So you only need one copy of the firmware.Is there any reason why you would need different firmware for different versions of Pis? Currently all Raspbian releases will run equally well on all models of Raspberry Pi so you don't need different versions of the software for different versions of the hardware.Otherwise it would be possible to create a special linux build that you put into the base directory that is used for Raspberry Pis that have no serial number stored on the server. This build boots up and automatically executes a script (you can I think just do this using a cmdline parameter of init=myscript.sh) which can then check the revision number and log into the server to create a new symbolic link for it's serial number, then reboot...I'd rather not add another method for doing this since it delays booting to check every possible place for a build—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[ghollingworth]

Please open a different issue if you have other requests.