Error on network boot because of missing symbolic links

[jps229]

Hello,

I am currently trying to set up a network boot for a Raspberry Pi 4B using my TrueNAS Scale (latest Version).
The NAS is reachable at 192.168.1.2, and a TFTP server is running as a container pointing to the path /mnt/SNAS/Boots.
The Raspberry Pi has the IP 192.168.1.199.
NFS shares exist on /mnt/SNAS/Boots. The boot dataset has "everyone" permissions (NFSv4) for testing.
dnsmasq is working on my dd-wrt-router and pointing to the tftp-server.

I am using the latest RaspOS Lite 64bit image, which I have downloaded and extracted. I mounted the image and tried to copy the boot and root files to my NAS using the following commands:

Code:

sudo rsync -av --progress /home/user/Downloads/RaspOSlite64/boot/* /mnt/truenas/SNAS/Boots/07535901/
sudo rsync -av --progress /home/user/Downloads/RaspOSlite64/root/* /mnt/truenas/SNAS/Boots/07535901/root/

But not everything could be synced....

The Raspberry Pi successfully finds the boot and root files, but then the boot process aborts because it cannot find sbin and other symbolic links. These are the same links that caused issues during the copy process ("operation not supported"-errors)

I have not yet tried to use the -L option with rsync to dereference the symbolic links, as I am concerned it might cause more issues down the line.

I would appreciate any help or suggestions on how to correctly handle the symbolic links during the copy process to allow the Raspberry Pi to boot successfully.

Thank you.

 

[jgreco]

Why wouldn't you just copy the symlinks as symlinks (rsync -l flag)?

If your OS is expecting things to be in certain places relative to other things, you need to take responsibility to make certain that those things are actually in the expected places when accessed by the NAS. It is generally recommended to use relative links (i.e. "../../other/dir/file") rather than absolute links for this kind of thing, but really it only matters that the client receives an appropriate link from the server when requested. Since there are several ways this can be done, you need to examine your source tree, your NFS tree, and then what your client sees.

 

[jps229]

I had to skip the ACL-rights in total and go back to permission editor (nobody/nogroup).
After that, I was able to copy everything.
Still errors with booting (signatures for apt-get), but at least some advance....