Error when updating software with experimental Buster for Pi4

[Francesco_F]

after booting the Pi4 + BrickPy 3, and connecting with VNC, the first thing I have done was to issue

sudo apt full-upgrade

and I got the error:

Errors were encountered while processing:

dhcpcd5

E: Sub-process /usr/bin/dpkg returned an error code (1)

Ever since, every time I install a new package with apt install , the installation of the package completes, but returns the same error.

It is especially an issue when running installation scripts, such as for ROS, that install multiple dependencies, and after every installation stop reporting that same error, in spite of the fact that the dependency was installed correctly.

Please let me know if I can collect any useful information to troubleshoot the issue.

[cyclicalobsessive]

Does this work-around help?

Buster 2019/12/12 cannot update package dhcpd5 due to incompatible file-system

Issue In the latest Raspbian for Robots “Buster” beta release, it is not possible for apt to update the dhcpcd5 package. Attempting to upgrade this package returns the error: dpkg: error processing package dhcpcd5 (--configure) installed dhcpcd5 package post-installation script subprocess returned error exit status 1 Further examination of the /var/log/apt/term.log disclosed an additional error message: chown: changing ownership of '/etc/dhcpcd.conf' Operation not permitted. I examined …

[jimrh]

The “workaround” I proposed works.

Viz:

1. Open a terminal window and change to the /etc directory by typing "cd /etc "
2. Remove the symlink to the dhcpcd.conf by typing "sudo rm ./dhcpcd.conf "
3. Copy the actual file from the /boot/network/dhcpcd.conf by typing:
   "sudo cp /boot/network/dhcpcd.conf ./ "

Once that is done, you can re-run the apt and/or apt-get upgrade command and the update to dhcpd5 will finish normally.

@cleoqc mentioned to me earlier, (sorry if I didn’t pass this along), that the presence of the dhcpcd.conf file in the FAT formatted section of the file-system is actually by design.

The idea is that this allows the user to make modifications to the network configuration without having to boot the system since the dhcpcd.conf file is in a “Windows” readable part of the file-system. The symlink in /etc allows the normal dhcpcd5 package to read the file as if it were actually present there.

I would humbly beg to differ.

Before you read any further, I want to make it perfectly clear that I intend absolutely no disrespect to cleoqc, or anyone else at Dexter/Modular Robotics. They’ve done a wonderful job in a hardware and software space that takes NO PRISONERS! Screw-ups are remarkably easy, and there’s always a zillion pundits who know how to do it better.

I am remarkably grateful for the work they’ve done, and if this is their BIGGEST problem, we should all be so lucky!

IMHO, a design decision - any design decision - that breaks major functionality, (in this case the ability to update a necessary networking package), should probably be reviewed.

Please allow me to suggest a different approach that gives everyone what they want - both the ability to modify this file within the FAT formatted file-system and doesn’t break a major package update.

Viz.:

1. Remove the symlink in /etc and replace it with an actual file.
2. Create a special startup script, (or add to an existing script), that runs early in the boot process. This script would copy /boot/network/dhcpdc.conf to /etc/dhcpcd.conf, replacing it with any modifications the user might desire.
3. Create a special shutdown script, (or, again, add to an existing script), that reverses this - copies /etc/dhcpcd.conf back to /boot/network/dhcpcd.conf. preserving user modifications and package updates.

This would preserve the ability to modify this network file, and would not break updates on the dhcpcd5 package.