timebertt / pi-cloud-init Goto Github PK

Any plans to support a docker vagrant environment? The virtualbox dependency breaks for anyone using an M1 architecture.

When trying to build the an image, step "Installing core packages..." fails:

I: Installing core packages...
W: Failure trying to run: chroot "/home/vagrant/pi-gen/work/stage0/rootfs" dpkg --force-depends --install /var/cache/apt/archives/base-files_10.3+rpi1+deb10u11_armhf.deb
W: See /home/vagrant/pi-gen/work/stage0/rootfs/debootstrap/debootstrap.log for details (possibly the package base-files is at fault)
rmdir: failed to remove '/home/vagrant/pi-gen/work/stage0/rootfs/debootstrap': Directory not empty
[22:46:11] bootstrap failed: please check /home/vagrant/pi-gen/work/stage0/debootstrap.log

The log contains:

Setting up base-files (10.3+rpi1+deb10u11) ...
dpkg: error processing package base-files (--install):
 installed base-files package post-installation script subprocess was killed by signal (Segmentation fault)
Errors were encountered while processing:
 base-files

I'm not sure whether this a fault of the upstream builder or this script, but because I can't find something upstream and it seems I can just build an image with pi-gen on bare metal I suspect that this might be an issue with the build script/vagrant.

If additional sources are added in the user-data file cloud-init will overwrite the sources.list file(which is the expected behavior). Unfortunately the new file is for debian an not raspbian.
This results in some errors regarding the sources in cloud-init.

Perhaps I missed something but the README.md file probably needs updating with references to this project's missing prebuilt images and the download directory https://github.com/timebertt/pi-cloud-init/releases/download/.

Looks like permissions are not being set correctly for /dev/rfkill on boot. If I call rfkill as would done on boot, or during an ssh connect, as part of the /etc/profile.d/wifi-check.sh script I get the following errors,

rfkill: cannot open /dev/rfkill: Permission denied
rfkill: cannot read /dev/rfkill: Bad file descriptor

Looking at /dev/rfkill when this happens I see that only root has permissions and that it's accessible by the root group. In this circumstance the permission errors make sense since my user isn't root or in the root group.

thomasga@rpi-carbon-00:~ $ ls -lah /dev/rfkill
crw------- 1 root root 10, 242 May 11 04:21 /dev/rfkill

Experimentally I found that I can clear the error until the next reboot by calling sudo rfkill this causes the permissions on /dev/rfkill to change to root:netdev and my user is part of the netted group (shown below).

thomasga@rpi-carbon-00:~ $ sudo rfkill
thomasga@rpi-carbon-00:~ $ ls -lah /dev/rfkill
crw-rw-r-- 1 root netdev 10, 242 May 11 04:25 /dev/rfkill

I haven't gone back to a version of the software that had dhcpcd unmasked but I didn't see this error in that case so something in the boot sequence with dhcpcd active is more better...

Being explicit about downloading this git repo for Step 2 in 'How to build the image' may be helpful.

The Readme.md instructions said, "Mount the boot partition (of the .img file) to add user-data, meta-data and optionally network-config files to the root of it. Unmount it again, once added."

Are those filenames simply user-data, meta-data and network-config without the suffixes or are they user-data.yaml, meta-data.yaml and optionally network-config.yaml as listed in this project's root and examples directories?

Thanks for doing the work to get RaspiOS lite running with cloud-init! The 64-bit image is almost exactly what I need.

When trying to provision a unit with a static IP per your example I'm seeing the device get both a static IP and a dynamic one assigned, I saw this with ip address show. A little more digging shows that the dhcpcd service is still running and is why the second dynamic IP is being assigned. Locally I was able to stop this by running sudo systemctl stop dhcpcd and sudo systemctl mask dhcpcd to prevent the service from restarting, doing so forces network-config to be the sole source of configuration.

While I think you could add these commands in the user-data I think a more generalized answer would be good but I'm not quite sure where to add this in the scripts. I'd be happy to help test this further and will keep poking myself.