PDA

View Full Version : Netbooting piCorePlayer 3.x



epoch1970
2017-04-04, 02:29
(Summarized from posts in the pCP 3.10 announce/support thread. (http://forums.slimdevices.com/showthread.php?106755-Announce-piCorePlayer-3-10&p=880106#post880106))

A seemingly operational pCP player can be obtained via net booting, a Pi 3 feature only (https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md):

Take a linux server with disk space, install a tftp server to support Pi 3 net booting. I chose dnsmasq, the conf for the tftp server is extremely simple. "server=172.17.0.2" is the DNS/DHCP server on that network. There is no interference between the 2 machines:
server=172.17.0.2
dhcp-range=172.17.255.255,proxy
log-dhcp
enable-tftp
tftp-root=/tftp
pxe-service=0,"Raspberry Pi Boot"
The tftp tree structure is like this. 12345abc and abcde123 represent the serial number of 2 different Pi 3s. bootcode.bin has to be placed directly under the tftp root:
/tftp/
├── 12345abc
│ ├── bcm2708-rpi-0-w.dtb
...
│ └── start_x.elf
├── abcde123
│ └── Pls_bind_to_nfs_exported_boot_directory
└── bootcode.bin
The contents of the "12345abc" directory is the same as the first partition on a pCP image, with a custom cmdline.txt.
On that server, setup exports to provide the player with its data partition(s). The main export is the home of pCP, copied from the second partition of a pCP image. There is need for a secondary export, since pCP offers changing boot parameters and loading hardware firmware ("overlays") from the GUI. There has to be an automatic link between that export and the directory served by tftp in order for pCP to be able to reboot into new settings.
As of now I am using a single NFS export on the server.
/export 172.17.0.0/16(rw,sync,no_subtree_check,no_root_squash) Here is the tree:
/export/
├── 12345abc
│ ├── BOOT
│ │ ├── bcm2708-rpi-0-w.dtb
...
│ │ └── start_x.elf
│ └── TCE
│ └── tce
│ ├── mydata.tgz
...
├── abcde123
...
To link the /tftp directory with the updatable (exported) BOOT directory, I've chosen to setup a bind mount (e.g. "mount -o bind /export/12345abc/BOOT/ /tftp/12345abc"). The pCP machine reboots in new settings like on the regular SD-based version.
On the pCP instance, setup a custom /opt/bootlocal.sh script and save it ("pcp bu"):
#!/bin/sh
# put other system startup commands here

GREEN="$(echo -e '\033[1;32m')"

echo
echo "${GREEN}Running bootlocal.sh..."
#pCPstart------
/home/tc/www/cgi-bin/do_rebootstuff.sh 2>&1 | tee -a /var/log/pcp_boot.log
#pCPstop------

# NFS mounting. See http://forum.tinycorelinux.net/index.php?topic=19913.0
for i in `cat /proc/cmdline`; do
case $i in
nfsboot*)
# Allows to update pCP boot config over NFS
NFSBOOT=${i#*=}
BOOTMNT="/mnt/mmcblk0p1"
SERVER=$(echo $NFSBOOT | awk -F: '{ print $1 }')
DIR=$(echo $NFSBOOT | awk -F: '{ print $2 }')
OPTS=$(echo $NFSBOOT | awk -F: '{ print $3 }' | tr ',' ' ')
OPTS=$(echo defaults noauto nolock addr=${SERVER} ${OPTS} | tr ' ' ',')
echo "Creating directory ${BOOTMNT}"
sudo mkdir ${BOOTMNT} >/dev/null 2>&1
# pCP checks in fstab for device /dev/mmcblk itself so mounts fail...
# echo "Creating /etc/fstab entry for ${BOOTMNT} over NFS"
# ME="$0"
# sudo sh -c "cat << EOF >> /etc/fstab
## Added by $ME
#${SERVER}:${DIR} ${BOOTMNT} nfs ${OPTS} 0 0
#EOF
#"
# ... so instead we mount permanently as pCP won't mount/unmount
# if mounted already.
echo "Mounting ${SERVER}:${DIR} to ${BOOTMNT}"
sudo mount -t nfs -o ${OPTS} ${SERVER}:${DIR} ${BOOTMNT}
;;
nfsmount*)
# Keep pCP happy with a normal-looking SD mount
NFSMOUNT="/mnt/nfs"
TCEMNT="/mnt/mmcblk0p2"
echo "Creating directory ${TCEMNT}"
sudo mkdir ${TCEMNT} >/dev/null 2>&1
echo "Adding bind mount for ${TCEMNT}"
sudo mount -o bind ${NFSMOUNT} ${TCEMNT} >/dev/null 2>&1
;;
esac
done
This codes stays inactive until cmdline.txt includes the relevant boot parameters.
On the server, edit cmdline.txt to set the parameters, e.g.:
nfsmount=172.17.71.10:/export/12345abc/TCE nfsboot=172.17.71.10:/export/12345abc/BOOT:udp,vers=3,noatime

nfsmount is a true TCLinux bootcode, this is processed in /etc/init.d/tc-config. This export gets mounted under /mnt/nfs. It should support the form <server>:<export>:<mount options> but the script only looks for some special options (noping?) and doesn't apply generic ones, like udp. The bootlocal.sh script adds a bind mount from /mnt/nfs to /mnt/mmcblk0p2, to (marginally) improve system reporting on the pCP GUI.
nfsboot is implemented in bootlocal.sh, in the same fashion as tc-config except it processes mount options. This export contains the boot partition for configuration changes, and gets mounted to /mnt/mmcblk0p1 to let pCP work (almost) normally.
Boot the Pi player without an SD, and after a little while, the server shows:
Apr 3 23:30:23 luns dnsmasq-dhcp[425]: 653460281 available DHCP subnet: 172.17.255.255/255.255.0.0
Apr 3 23:30:23 luns dnsmasq-dhcp[425]: 653460281 vendor class: PXEClient:Arch:00000:UNDI:002001
Apr 3 23:30:23 luns dnsmasq-dhcp[425]: 653460281 PXE(eth0) b8:27:eb:01:02:03 proxy
Apr 3 23:30:23 luns dnsmasq-dhcp[425]: 653460281 tags: eth0
...
Apr 3 23:30:24 luns dnsmasq-tftp[425]: sent /tftp/bootcode.bin to 172.17.255.192
...
Apr 3 23:30:25 luns dnsmasq-tftp[425]: sent /tftp/12345abc/config.txt to 172.17.255.192
...
Apr 3 23:30:28 luns dnsmasq-tftp[425]: sent /tftp/12345abc/cmdline.txt to 172.17.255.192
...
Apr 3 23:30:48 luns rpc.mountd[502]: authenticated mount request from 172.17.255.192:920 for /export/12345abc/TCE (/export)
Apr 3 23:30:56 luns rpc.mountd[502]: authenticated mount request from 172.17.255.192:697 for /export/12345abc/BOOT (/export)

For what I've seen, pCP works normally. Some features like wifi setup, available space or partition resizing either don't make much sense anymore or quit. The routines that mount/dismount the boot partition around system updates are disabled due to the permanent NFS mount of /mnt/mmcblk0p1; They can't manage using an /etc/fstab entry for the NFS share (they look for /dev/mmcblk0 it seems).
In my use case, considering there is a good chance I will ultimately disable the web GUI on players, I feel like this solution works already. I will check it with the latest release, as I had to stuff pCP 3.10 with new firmwares taken from a Raspbian install to obtain the initial net boot attempt.

Given the tftp/nfs couple is relatively simple and lightweight, I have a feeling these could be installed on a "mothership" pCP instance. The server could be used to receive the contents of a running pCP player's SD, allowing it to net boot on the next reboot. Possibly, it could react to hits from unknown serial numbers and copy a netboot-ready instance of pCP in a new directory to allow a factory-fresh(*) Pi3 to boot as a pCP player. I will probably not use such things personally for now; in my case the server will be a Raspbian machine.
(*) AFAIK for now you need to boot once a factory-fresh Pi 3 from an SD with a config.txt file that includes "program_usb_boot_mode=1". Perhaps future batches of Pi 3 will have this flag set from factory.

If using an iSCSI LUN, moving from the network to an SD might be even simpler, as the LUN could be a pCP.img file with 2 partitions. I'm not sure this is needed and haven't checked if Pi 3/piCore can net boot from iSCSI.

Overall I am excited by this capability. Pi 3 netboot is great, and in the case of pCP, this more or less takes us back to the magic days of player auto-upgrade when installing a new version of LMS. It's been a long time since my SB3s haven't seen a firmware update :)

EDIT. 3.20beta netboots without further need to fiddle with firmware. The analog output sounds as good as possible, and sync seem fine too :)

sbp
2017-04-04, 05:35
Hi epoch1970.

This is great news, thank you very much for your hard work and for the detailed documentation of the steps.

So I will have to try this out and let us see if there is a demand for this method then it might slip into pCP.
Regarding disabling the webGUI I agree that after you have set up your pCP you usually can forget about it as you don't need to change anything.

Steen

epoch1970
2017-04-04, 07:16
Sure, glad to be of help. I hope others will find the idea interesting ;) and the explanation clear enough. (Let me know)

My use-case is a set of players in a public place, my drivers to want this were: a. scrape a few bucks per player, b. remove a cause of failure, c. allow remote "bare metal" players administration, d. save the planet (one less part to source), e. a tiny bit less smoke in case the player somehow catches fire.

pCP 3.20 looks/sounds good, btw. Thanks!

th00ht
2017-04-10, 11:45
Very interesting thread. Something I thought of doing but was scared by the amount of work. Good description. Getting away from that fiddling with SD cards that need not more than a view MB is good riddance.

huxmut
2017-04-12, 02:51
hey epoch1970, thanks a lot for this. this idea has interested me for a while ...

this question is more for steen and pCP dev guys, is it possible to have to have a pi3 (or other NAS/server) as a LMS and a netboot master of everything ?

i guess i'd love if the client Pi's could have a uSD card with the basic info to get it started, like wifi password and i2s dac config and whatever else might be different across the clients.
that way i only need to update a single Pi when there is a new version of pCP

i realise that you guys are super busy with other things. maybe add it to the "one day i'll get around to it" list :)

thanks again

edit- just thinking more about this ... my NAS/LMS server runs XPenology (synology nas) which has the ability to do LUNs.
So, can i make an image of an existing pCP uSD card and drop that into a LUN and then have a little netboot code on the client Pi uSD card.
i'm not worried about leaving a card in the client Pi's (that may be a way of getting Pi 2's up and running also ??)
feel free to push me in the right direction :)

22490

epoch1970
2017-04-12, 12:48
Yes a Pi 3 can netboot clients, I can't tell how many because atm I have a single Pi serving alternatively as client and server... But since the OS is light, the Pi should be able to manage quite a few clients simultaneously. I expect to be able to test for 5 clients booting simultaneously.

You can't netboot from wifi on Pi 3. With an external ethernet-wifi bridge that should work, though. Actually I have an old "gaming adapter" somewhere, I could verify that...

If you keep a system on an SD, then I think you're somewhat looking at an upgrade system like pCP has already.

huxmut
2017-04-12, 19:21
thanks epoch


If you keep a system on an SD, then I think you're somewhat looking at an upgrade system like pCP has already.

it's probably me justing wanting to do it for the sake of doing it rather than any logical reason, but I do like the idea of having a boot file on the sd card and the 'core' OS and config files hosted on my nas.

now, just wondering aloud here - for those updates that currently require a total rewrite of the uSD card, would this allow me a 'no easy access' build eg. the Pi could be buried in an amplifier, where access to the SD card is time consuming/PITA.
and, if config changes were required would it be a case of SSH into the client Pi or would it be better if the config was also remote and a plain text file for easy updates ??
or is it more likely a case of having seperate images for each client hosted on the NAS therefore defeating my desire to have a singular pCP image hosted ??

Again, thanks for your efforts, I've started reading up on U-boot and other ideas like that, it's quite mad what a little Pi is capable of these days :)

epoch1970
2017-04-13, 00:44
I don't know u-boot, tinycore and pCP enough to say what is possible in terms of updates when the system runs from the SD.

The Pi has no traditional BIOS, the only thing it can do by itself is test the SD, the USB and the network for boot media. The media includes firmware and OS.
Since TinyCoreLinux is so compact, I don't think you can find much gain in using some pivot OS on an SD.

Now, according to the Pi 3 boot description (https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/bootflow.md), if the OS on your SD (pCP) had a "suicide" option that would remove bootcode.bin, then on reboot the machine would look for media on the USB or network to boot from.
And if such media was available and held a new version of the OS that had a "persist to SD" option, you could reboot and write the new OS to the SD. Unplug USB or ethernet, reboot again and you're done.
EDIT: I've tested renaming "bootcode.bin" to "bootcode.hid" in an SD, and installing it in a Pi 3. It boots from the network. Then I renamed .hid into .bin, on reboot it ran from the SD. So a flip-flop from SD to network/USB with the SD in place is possible.

Many devices have some "maintenance" USB port, with Pi 3 you theoretically could have either an USB or ethernet maintenance port.

M-H
2017-04-14, 17:06
...., would this allow me a 'no easy access' build eg. the Pi could be buried in an amplifier, where access to the SD card is time consuming/PITA. ....

Hi Humax.
The TF card swap in systems with embedded raspberries indeed does hinder upgrades.
When I bought a deluxe casing for my Pi , I was pleasantly surprised it came with a 'sd card extender'.
Searching with this string on some sites will give you more info instantly.
I do recommend you use this knowledge for any embedded pi you have already or will build in the future.

Greetz , MH

M-H
2017-04-14, 17:26
Further reading on the other bootmodes of the pi 3, made me aware on USB boot options.
It seems the USB boot from a regular msd is possible, and this should also be possible for small tf card readers.
So for embedded systems that have exposed USB / ethernet ports of a rpi3 , there is a < 1 Euro solution to boot over the USB port.

I am not sure if PCP has been tested successfully with usb boots sofar. I might have missed the discussion on this.
Please update me with a link if this is already documented .

MH

huxmut
2017-04-14, 20:44
Hi M H, yes i've seen those extenders. Also the way some of the cases mount the Pi and Hats away from the LCD display etc look good (but expensive)
I thought (for my situation) a network solution would be best as it means there is one single location/folder/NAS/LUN/TFTP server to put an image in and have it work for every pCP client on the network.

I'll be happy with whatever the pCP devs and epoch1970 comeup with though :D
I'm just throwing ideas around :)

edit -
cases like this one from audiophonics is what i'm referring to above
http://www.audiophonics.fr/en/boitiers-diy-boitiers-divers/rasptouch-black-chassis-and-accessories-kit-diy-p-11248.html
http://www.audiophonics.fr/en/boitiers-diy-boitiers-divers/rasptouch-chassis-and-accessories-kit-diy-p-11249.html

M-H
2017-04-15, 15:37
Hi Huxmut,

Indeed the case you linked is the one that allowed me to have a pi in the living room, and does use the sd-extender.

On the subject of netbooting ; it would be awesome to have an empty pi to learn all configuration over the network.
Firmware, OS, configuration and executables all over the net. A central server, preferably a PCP , with the needed services and storage could centralise all that.
Unfortunately it would be wired ethernet only at this moment. And I use all my players and LMServer wireless at this moment. ( I know the disadvantages and risks, but it works for me )
I have been thinking about wifi booting, but that would be quite more complex ( SSID, passwords, chipsets supported ) and impossible until the bootloader is extended for this. And frankly I do not expect the raspberry foundation to put time into that wifi-netbooting concept. A recently purchased wifi printer however showed me it is possible to recognise and configure a factory default node to work on the wifi network without memorycard, USB connection or key input on the device. So technically it is not impossible.

Still parts of the central repository can be done with scripting and pushing config files to a central node. It would be similar to the insitu upgrades and also have the same drawbacks.
For me it is a nice thing to debate, but in my situation I would stay with card swapping, as it almost as easy and flexible. Only a full USB boot would help ease the handling.

Regards MH

Wetty
2017-04-16, 07:58
Hi,
with an empty SD card with only bootcode.bin on it, even a Raspberry Pi 2 can netboot picoreplayer. But Rpi2 does not look into the serialnumber folder, he searches the boot files in the pxe root. Took me a day to find that problem.

It is also possible to boot from a USB Stick. I just write the piCorePlayer img to the stick as I would do with an SD card and it worked out of the box. Even mydata.gz gets written to sda2. But config.txt changes are written back to the bootcode.bin sd card, which then brakes the booting.

epoch1970
2017-04-28, 08:32
Howdy, netbooters everywhere.

I am testing now with 5 clients (pcp3.20beta5) and a Raspbian Lite server. I'm trying to boot all 5 at once, with mixed results. Here is what I can report for now:

It looks like Pi 3 clients send discovery packets as soon as they have powered up, so if they are behind a switch that takes its time booting, like learning network topology for STP, then the packets are lost and the Pis stay put for a while. Don't know how long, it is not my test case. The solution seems to be configuring the switch to "fast-open" some ports to let the traffic go through.
My Pis wear Justboom amp HATs, for the moment I use two 24V PSUs, one 18V, one 12V and one 5V "official" Pi 3 PSU. I *think* that if the Pis are not totally powered down when they regain power, they don't boot so well. I have 1 of the Pis on nylon stand-offs, the 4 others on brass standoffs, no difference. The one with the "official PSU" is powered via -USB, the others via the DC barrel connector on the amp, no difference.
I am testing with 2 switches on the path: one giga integrated to a router, another next to the clients. For this one I test mainly with an old no-name fast switch: boot is not consistent, and sync sometimes suffers. I've also tested with a brand new Netgear GS108T v2: sync seems flawless, boot better but not perfect.
The setup I used initially (described above) was to automount a bind mount between /exports and /tftp. I found out the mounts would expire or not come up at the appropriate time, so I have replaced that with symbolic link. This clearly improved the boot success rate.
I *suspect* that the discovery protocol of LMS might cause some players to stall during boot. I have anecdotal evidence players boot better (if not perfect?) with LMS stopped. Supposedly broadcasts can stop a Pi from TFTP-booting, if you have more info on that I'm interested.

ian_heys
2017-04-29, 01:05
Howdy, netbooters everywhere.

Hi Epoch, I hadn't realised the relevance of your signature before I composed my first post to you.

I wasn't considering Net Booting as I was quite happy with my set-up, but yesterday, on one of my Pi's, the SD card latch broke, which prompted a few questions about Net Booting.

1. Do all the players have to be the same Pi Version and all be players?
2. Is the operating system/squeezelite/LMS upradeable once the OS has loaded and does the player have to go back to base OS if one of the players stops?
3. I suppose if all the players had identical hardware and DAC's etc then the updated image could be kept on the central server?

Sorry for the basic questions.

epoch1970
2017-04-29, 04:36
1. Do all the players have to be the same Pi Version and all be players?
2. Is the operating system/squeezelite/LMS upradeable once the OS has loaded and does the player have to go back to base OS if one of the players stops?
3. I suppose if all the players had identical hardware and DAC's etc then the updated image could be kept on the central server?
1. Yes, netbooting is a Pi 3 specific feature, AFAIK. Something to do with the chipset model used.
2. According to my tests, you can boot, configure pCP and reboot into the new config like if the OS was installed on the SD.
3. The OSes don't need to be the same, they are stored in the server. The Pi 3 client boots the OS it fetches via TFTP under a path that includes its serial number, e.g. "/tftp/123456/". Then in the OS config you specify an NFS export to serve as root directory, e.g. "/export/123456/pCP".
So you need a bit of room on the server (but in the case of pCP the OS is so small it just doesn't matter). And you can access a machine's system right away under /tftp or /export. Very easy compared to using an SD.

As I mentioned, boot reliability is not good enough in my case. If there is no solution to this, then I don't think the setup is viable.

ian_heys
2017-04-29, 05:48
Thanks for that - very clear.

I may go on to try it out - but just a little busy with other LMS matters at the moment.

Will post here if I do find it useful.

epoch1970
2017-04-30, 13:20
I am done with it.
I fiddled with every possible aspect of the software and hardware on my test setup, and my conclusion is that it is not possible to get 5 players to boot together, repeatably, with a Pi 3 as the server.

Perhaps there is still room for improvement in the firmware, but it's possible we'll have to wait for Pi 4 to get netbooting to work in real life...

ian_heys
2017-05-01, 00:11
I am done with it.

That's good enough for me. Glad I didn't start.

It's fantastic that this forum generates so many diverse functions and facilities.

Personally I haven't had any SlimDevices/Logitech products for at least two years but the infrastructure is so good, thanks to all the great developers, that I wouldn't think of going anywhere else.

And when I can get a true audiophile quality server/player for about 100.00 it's hard to imagine moving away from this system.

Keep on trucking.

epoch1970
2017-05-01, 02:02
Yeah I'm pretty miffed by the situation.

For those who'd like to get rid of the SD and do not mind attending reboot and power cycle the machine if it doesn't come alive, here is the last configuration I was running on the Raspbian server.
It runs good, but not reliably enough for me. I was targeting unattended reboot after general power failure (the Pi 3 server being protected by an UPS)

This setup was running on "Linux srv 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7l GNU/Linux" (Raspbian lite) on Pi 3. All wired network, DHCP server on an ISP router box, 2 switches: one close to the players, one in the router box (Pi 3 server connected to it).

1. Install atftpd in addition to dnsmasq. For me dnsmasq has a bug in its tftp server and often sends files that belong to the wrong player. The symptom is the player doesn't boot and blinks its green led 3 times repeatedly. This is solved by using atftpd.

2. Configure both to work together. For atftpd I have boosted the number of threads to improve processing of parallel booting of multiple players. The timeout option computed by the client is disregarded as I read there was a bug there in the Pi 3 firmware, but these tweaks might be useless. This is /etc/default/atftpd:
USE_INETD=false
OPTIONS="--user=root.root --retry-timeout=30 --maxthread=200 --no-timeout --verbose=3 --listen-local /tftp"
3. As clients would still randomly decide to sit on their butt doing nothing, I decided in a last-ditch effort to supersede the router's built-in DHCP server with dnsmasq in the Pi 3 server. So dnsmasq no longer works in proxy mode, but as an authoritative DHCP server. Having 2 active DHCP servers would disrupt networking, so dnsmasq is configured to respond only to a specific set of Pi clients. This is /etc/dnsmasq.conf:
log-dhcp # Debug mode
log-async=50 # Weak IO/s on Pi
dhcp-no-override # Safe behaviour
dhcp-ignore=tag:!known # Only known Pis (below)
pxe-service=0,"Raspberry Pi Boot" # Boot service for Pi 3
dhcp-option=66,"192.168.1.161" # Inform clients of the TFTP server name, ourselves
# Needed for atftpd. Mind the quotes
dhcp-authoritative # Try to help Pi3s get an address to boot...
dhcp-range=192.168.1.100,192.168.1.175
# ... and its still not enough. It's broken.

# Known hosts
dhcp-host=b8:27:eb:01:02:03:04,player1,192.168.1.162
...
Once booted, I had excellent sync over my 5 test players (pcp3.20beta5). Reboot usually works, as it is easier to get a single Pi to boot compared to 5 at the same time. Rebooting the server puts players in stasis while they try to regain their root filesystem over NFS. After a few minutes, the players are operational again and sync fine.

Finally be aware that switches on the path may affect the players boot behaviour, especially if they are power cycled as well. "Smart" switches that take their time to boot and activate their ports have an adverse effect, possibly also switches with "green" features that activate ports on demand. YMMV, and good luck.

jmccoy555
2018-03-28, 06:07
Hello all.....

I'm trying to get this going, following Post 1 I have got the kernel to load and end up with a terminal session. PiCorePlayer is not yet loading.

I'm a bit lost at point 3, where do I put the script?

I've had a bit of a poke around and have found the default /opt/bootlocal.sh, but I think this is read only and lost on a reboot. I cant see where this is loaded from or how to replace it with epoch1970's?

Some pointers would be great....

Thanks.

epoch1970
2018-03-28, 11:00
Hello all.....

I'm trying to get this going, following Post 1 I have got the kernel to load and end up with a terminal session. PiCorePlayer is not yet loading.

I'm a bit lost at point 3, where do I put the script?

I've had a bit of a poke around and have found the default /opt/bootlocal.sh, but I think this is read only and lost on a reboot. I cant see where this is loaded from or how to replace it with epoch1970's?

Some pointers would be great....

Thanks.
I don't have a local pCP machine to look at, but I dont remember that script was read-only. It belongs to root, probably, but you can "sudo vi" or "sudo chmod a+rw" I suppose.
Once you've added stuff to it, run "pcp bu" as the normal tc user. This pcp command executes a backup of some files to mydata.tgz.
IIRC "pcp bu" is a wrapper around the standard OS backup script "filetool.sh". There is a file (/opt/.filetool.lst?) configuring what gets included to mydata.tgz. /opt/bootlocal.sh is among the files that get saved.
At boot, mydata.tgz is uncompressed and content is restored.

If you forget to "pcp bu" before rebooting, you lose your modifications. You have been warned.
I was warned too, many times, and I still forget to commit my changes from time to time... :)

(Since everything is in the server you could also uncompress mydata.tgz on the server, do your mods and recompress. But you have to get the paths/file ownerships exactly right, otherwise piCore won't like that and boot will possibly fail. I think it is much safer to edit directly on the live client and save with pcp bu.)

EDIT1:
Also, I revisited the thread quickly, I haven't seen mention of replacing the bind mounts with simple symbolic links. I used bind mounts because I wanted them to get automounted (don't remember why). But in the end, the automounter was a bit too slow to react and that helped boot fail... So I dropped that plan and from there, symlinks were simpler and as effective as bind mounts.

EDIT2:
I've also played with netbooting Pi3s again recently. To improve your boot success rate, the number of switches (and their settings) in the path between client and server seems important. Basically, you want the proxy DHCP server to reply before the standard DHCP server. With a server inside an ISP box that includes the switch, to make that happen you basically have 2 options:
- best solution: disable the main DHCP server in the ISP box and give the job to your netboot server (dnsmasq is very fine),
- alternative: add another switch on the path, so that your netboot server and clients are all connected to the same switch, and the ISP box is one hop further away (should work if the DHCP server in the netboot server is itself fast enough.)

Using a Pi3 to run the netboot server, given its slow network and I/O performance, is not really the best way to see your Pi3 clients boot reliably...

It is said that the new 3B+ is better at netbooting; it uses a revised chipset, the claim makes sense. On the RPF's forums you can find one thread about the 3B+ having problem rebooting after netbooting (https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=208692) (booting up and going down ok but not booting up again), that's a new one. There is hope this is a software (OS or firmware) problem and not another hardware issue.

jmccoy555
2018-03-29, 07:47
Hi epoch1970,

Thanks for the detailed response(s!).... I may have another go at this over the weekend.

If you forget to "pcp bu" before rebooting - think I fell victim to this one..... my knowledge of TC is zero!!!

You could also uncompress mydata.tgz on the server, do your mods and recompress. But you have to get the paths/file ownerships exactly right, otherwise piCore won't like that and boot will possibly fail - I also tried this after my post but guess that I didn't put it all back together again with the correct permissions etc.

As you say, its a bit of an art getting the pi's to get a DHCP address and then boot, I think they like this to be all from one machine. I was trying with pfSense and FreeNAS as the TFTP and NFS server, which didn't really happen!! In the end I stuck my pi's and PiServer (doing DHCP and everything) on their own vlan which worked much better, although they are still connected via a string of 3 UniFi switches (temporary arrangement).

I find PiServer to work quite well, although you have to do some fudging with mounts and json files etc to allow anything more than one version of Rasbian at a time, and have had good success with getting the pi's to boot just about every time. I haven't flashed them to boot mode, I'm just using the sdcard method with just bootcode.bin on it (mainly in case this idea doesn't work I can still easily reverse my experiment!).

My aim is basically to get all my Squeezelite clients to be easily updatable, as there are about 6 scattered around my house and not all easily accessible. I did manage to get Squeezelight with HiFi Berry cards running on Rasbian-lite via PiServer, but it just feels so big compared to piCorePlayer, so I think there is defiantly a solution out there!!!

Time for some more playing and testing!

Cheers.