Updating Dietpi fails (even after reinstalling)

[cars11]

• Date | Tue 8 Oct 23:26:02 BST 2019
• Bug report | N/A
• DietPi version | v6.24.1 (MichaIng/master)
• Img creator | DietPi Core Team
• Pre-image | Raspbian Lite
• SBC device | RPi 2 Model B (armv7l) (index=2)
• Kernel version | General | Update VM images to Stretch #1219 SMP Tue May 14 21:20:58 BST 2019
• Distro | stretch (index=4)
• Command | G_AGI rsync
• Exit code | 100
• Software title | DietPi-Backup

Steps to reproduce:

run dietpi-update

Expected behaviour:

dietpi is updated

Actual behaviour:

runs until
"[FAILED] DietPi-Update | G_AGUP"

Extra details:

I've tried created the directories below (/var/lib/dpkg/lock and /status)
But it still fails, after that I get different errors:

after creating the above directories asdditional logs ( blue text) spits out:

Hit:1 http://raspbian.raspberrypi.org/raspbian stretch InRelease
Hit:2 https://packages.sury.org/php stretch InRelease
Hit:3 https://archive.raspberrypi.org/debian stretch InRelease
Reading package lists...
E: Read error - read (21: Is a directory)
E: The package lists or status file could not be parsed or opened.

Additional logs:

Log file contents:
E: Could not open lock file /var/lib/dpkg/lock - open (2: No such file or directory)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

Additional Information (if applicable)

• Can this issue be replicated on a fresh installation of DietPi? Yes

Kind of a noob with DietPi/Linux, hope I added enough info.
I've reinstalled once before and neither time was able to run the upgrade function

[MichaIng]

@cars11
Many thanks for your report.

The lock file error usually occurs when you call APT without root permissions. Please try:
sudo apt update
or
G_SUDO G_AGUP
if not logged in with root user.

The other error indeed looks very strange. /var/lib/dpkg/lock and /var/lib/dpkg/status are files and no dirs. If those are dirs now (after you created them), please remove them. The lock file should be removed in any case, since it is only a tmp file during APT calls happen. Then retry the above. If it still fails, please paste the full output of the command.

[cars11]

Thanks, Michalng!

Unfortunately, that did not work either. Removed the directories and the lock file, ran both commands to not avail (ofc as root)

root@DietPi:/# sudo apt update
Get:1 http://raspbian.raspberrypi.org/raspbian stretch InRelease [15.0 kB]
Get:2 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages [11.7 MB]
Get:3 https://packages.sury.org/php stretch InRelease [6,760 B]
Get:4 https://archive.raspberrypi.org/debian stretch InRelease [25.4 kB]
Get:5 https://packages.sury.org/php stretch/main armhf Packages [129 kB]
Fetched 11.8 MB in 59s (200 kB/s)
Reading package lists... Error!
E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory)

then running the other command:

root@DietPi:/# G_SUDO G_AGUP
[ OK ] Root access verified.
[ INFO ] APT update, please wait...
Hit:1 http://raspbian.raspberrypi.org/raspbian stretch InRelease
Get:2 https://archive.raspberrypi.org/debian stretch InRelease [25.4 kB]
Hit:3 https://packages.sury.org/php stretch InRelease
Fetched 25.4 kB in 2s (11.7 kB/s)
Reading package lists...
E: flAbsPath on /var/lib/dpkg/status failed - realpath (2: No such file or directory)
E: Could not open file - open (2: No such file or directory)
E: Problem opening
E: The package lists or status file could not be parsed or opened.
[FAILED] G_AGUP

I'm starting to think my Raspberry Pi is defective. It always has wonky behavior when there is a powerloss or when it loses connection to the router (using it as a pihole)

[MichaIng]

@cars11
Btw just rechecked and the status file contains the info about currently installed packages. That should definitely not being empty or removed. But there seem to be backups created. Can you please try:

cp -a /var/lib/dpkg/status-old /var/lib/dpkg/status

Otherwise check /var/backups/, I am currently not at home but will check back later where/how the backups are stored.

[cars11]

root@DietPi:~/var/lib# cp -a /var/lib/dpkg/status-old /var/lib/dpkg/status
cp: cannot stat '/var/lib/dpkg/status-old': No such file or directory

[cars11]

creating the directory dpkg doesn't fix it wither

I have the feeling my raspi is busted. It's behavior is just too erratic.
When I lose power it won't accept my password until I cycle power 3-5 times.
Sometimes it will rejust refuse ssh connections alltogether. Way too wonky.
Must be broken. Don't want to waste more of your time

[MichaIng]

@cars11
Please do not create directories manually as long as you're not sure that they are really correct. As you see above it can break things.

So backups indeed are done to /var/backups/, and the lock file exists by default.
Please try:

cp -a /var/backups/dpkg.status.0 /var/lib/dpkg/status
> /var/lib/dpkg/lock
chmod 640 /var/lib/dpkg/lock

Verify that /var/lib/dpkg/status is a file now, starting with content:

Package: adduser
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 849
Maintainer: Debian Adduser Developers [email protected]
Architecture: all
Multi-Arch: foreign

Compare this with: head -8 /var/lib/dpkg/status

[cars11]

cp: cannot stat '/var/backups/dpkg.status.0': No such file or directory

[MichaIng]

@cars11
Hmm very strange, any other file inside? There should be 7 backup iterations: ls -l /var/backups

[cars11]

no backups

[cars11]

root@DietPi:/var# ls -l
total 16
drwxr-xr-x 3 root root 4096 Oct 8 23:20 cache
drwxr-xr-x 6 root root 4096 Oct 8 23:28 lib
lrwxrwxrwx 1 root root 11 Oct 8 19:17 lock -> ../run/lock
drwxr-xr-x 4 root root 220 Oct 10 00:17 log
lrwxrwxrwx 1 root root 6 Oct 8 19:17 run -> ../run
drwxr-xr-x 3 root root 4096 Oct 8 23:05 spool
drwxr-xr-x 4 root root 4096 Oct 10 15:39 tmp

[cars11]

my pihole is shot again too, can't access the web interface.

I am going to conclude the rasbpi is broken.
It's just so odd to me it can run stable for almost a year, but as soon as there is one power loss or even router connection loss it'll start all sords of odd behavior until I flash the SD card again.
Bust be a hardware defect, as I can't imagine power loss could corrupt anything when nothing is being written

[MichaIng]

@cars11
Okay then indeed there must have gone something wrong. These backups are created daily by this cron job: /etc/cron.daily/dpkg, indeed only IF the dir /var/backups exists. But this is the case by default.

Do you face power losses regularly due to unstable power supply at your location? Indeed this can be a reason for SDcard corruptions and then boot failures or random file losses. In such case I suggest to use a battery/accumulator to power your Pi until static power supply is up again.

If your Pi cashes, assure that there is an fsck done on boot (check journalctl logs for it) or force one on next boot via > /forcefsck. Check /lost+found dir then for unlinked files (that still exist physically on drive, but lost their inode link, thus are not available via file system).
Also run dmesg from time to time to check if the kernel faced any I/O errors due to e.g. corrupted files.

[cars11]

no, no regular power losses at all. But sometimes when I change a lightbulb or something I'll cut the power and then RIP my raspbi, or my cat will pull the on the cable or something.

so they really are that sensitive to power loss?
it never crashes when it is running. just goes berserk when it loses power
Seems odd to me that an SD card can corrupt itself when nothing is being written and the system is more or less idle

in that case it might not make sense to order a new raspbi, which I have just done..

thanks for all your help!

[MichaIng]

@cars11
Yeah indeed from my experience it is indeed quite sensitive to power losses. Although in my case I am not sure if it is the SDcard that has some dirty blocks. Note that it is being written to quite constantly due to logs and certain background processes, e.g. when you run a database on it and such. iotop is a tool that can be used to monitor the disk writes and from which processes they are done. So yeah indeed the RPi itself is high likely not the problem.

What I would always try first when issues occur regularly, is to reflash the SDcard with a fresh image or test another high quality SDcard.
And as mentioned above, running fsck for file system check & repair can often repair the system successfully after power losses and in the first place reveals if there is even any data corruption present of the issue is of another kind.

[MichaIng]

I mark this issue as closed now, feel free to reopen if required.