On Sat, 20 Mar 2021 16:24:45 +0000 Martin Gregorie wrote:

> On Sat, 20 Mar 2021 08:13:43 +0000, Markus Robert Kessler wrote:
>
>> On Sat, 20 Mar 2021 00:00:55 +0000 Martin Gregorie wrote:
>>
>> installation was end of November on a fresh 16 GB card.
>>
> OK, but is it a noname card or from one of the better brands? I've been
> using Sandisk for everything (RPi, camera, glider navigation system and
> flight logger) a few years now and have had no card-related problems.

I only use brands like Sandisk, Samsung EVO and similar.

It makes me cry to see that the card is totally ok,

# badblocks -vvv /dev/mmcblk0
Checking blocks 0 to 15446015
Checking for bad blocks (read-only test):
done
Pass completed, 0 bad blocks found. (0/0/0 errors)

and this seems to be one more ext4-issue.

In the meantime the filesystem was going more and more corrupted after I
tried to perform fsck.ext4.
Finally, there were errors in /home, and even /var was empty (!)...

So, the last thing I tried was to switch to NFS- or NAS-boot but I had to
see that the total storage space at that location was by far not
sufficient. Even worse, init didn't work either.

Since even /lib was more and more messed up, not even a shutdown / halt /
poweroff etc. was possible. So, I kicked it out in the firewall to
prevent it from doing unpredictable things after sshd also crashed and I
lost the connection.

So, end of the line here. Oh man...

>> As recommended in this group, I did not perform reboots every day /
>> night, since there are only some bash and python scripts running, which
>> consume only few resources and are ending after running properly.
>>
>> $ who -r
>>          run-level 3  Nov 30 09:21
>> $
>> $
>> $ df -h Filesystem      Size  Used Avail Use% Mounted on /dev/root
>>  15G  2.4G   12G  18% /
>> devtmpfs        184M     0  184M   0% /dev tmpfs           216M     0
>> 216M   0% /dev/shm tmpfs           216M   22M  194M  11% /run tmpfs
>>      5.0M  4.0K  5.0M   1% /run/lock tmpfs           216M     0  216M
>> 0% /sys/fs/cgroup /dev/mmcblk0p1  253M   54M  199M  22% /boot tmpfs
>>       44M     0   44M   0% /run/user/0 $
>> $
> OK - nothing wrong so far
>
>> $ cd /etc/resolvconf/update-libc.d $ ll ls: cannot access
>> 'avahi-daemon': Structure needs cleaning total 8.0K drwxr-xr-x 2 root
>> root 4.0K Feb 13  2020 ./
>> drwxr-xr-x 3 root root 4.0K Feb 13  2020 ../
>> -????????? ? ?    ?       ?            ? avahi-daemon $ cat
>> avahi-daemon cat: avahi-daemon: Structure needs cleaning $ fstrim -a -v
>> /boot: 197.4 MiB (206990848 bytes) trimmed on /dev/mmcblk0p1 /: 0 B (0
>> bytes) trimmed on /dev/mmcblk0p2 $ ll ls: cannot access 'avahi-daemon':
>> Structure needs cleaning total 8.0K drwxr-xr-x 2 root root 4.0K Feb 13
>> 2020 ./ drwxr-xr-x 3 root root 4.0K Feb 13  2020 ../
>> -????????? ? ?    ?       ?            ? avahi-daemon $
>>
> I think you'll find that avahi-daemon is only needed if your RPi needs
> to talk to some sort of Apple computer: here's  synopsis:
>
> The Avahi mDNS/DNS-SD daemon implements Apple's Zeroconf architecture
> (also known as "Rendezvous" or "Bonjour"). The daemon registers local IP
> addresses and static services using mDNS/DNS-SD and provides two IPC
> APIs for local programs to make use of the mDNS record cache the
> avahi-daemon maintains. First there is the so called "simple protocol"
> which is used exclusively by avahi-dnsconfd (a daemon which configures
> unicast DNS servers using server info published via mDNS) and nss-mdns
> (a libc NSS plugin, providing name resolution via mDNS). Finally there
> is the D-Bus interface which provides a rich object oriented interface
> to D-Bus enabled applications.
>
> So, it seems that if you are using Apple kit you need it, otherwise kill
> it. I only connect to my RPi from a Linux system, so I don't understand
> or use avahi-daemon.
>
>
>> Well, indeed, I never used fstrim so far.
>> But in this case it seems to do nothing, though.
>>
> OK
>
>> Data is received via I2C bus, processed and transmitted to a webserver
>> outside. These are only some Kilobytes, and there is no sensor data
>> stored on disk.
>>
> OK
>
> That looks like all the obvious stuff covered, then.
>
> If nothing else occurs to you or is suggested, check the SD card with
> fsck: "fsck -A -s" would seem appropriate and tell it not to fix any
> problems if it finds something and asks if it should repair it: IOW
> treat this as just a problem scan and only consider what to do if the
> complete fsck scan shows any errors.
>
> If errors are found, try to back up anything useful (code, scripts etc
> that aren't already backed up) and then, if you're feeling keen back up
> the SD card onto new backup media, i.e. don't overwrite a good backup.
>
> Then:
> - try using fsck to fix errors. If that works, great.
> - otherwise use gparted to clear the SD card, repartition and reformat
> it
>   and copy the backed up stuff back onto it and see if its now OK.
> - if still not fixed, repeat the last step with a new disk unless your
>   backup was to a new, freshly partitioned and formatted SD card, in
>   which case, use that as the RPi's main card and junk toe original.

B.t.w.,

I set up one more box here with ext3 rootfs to make some experiments.
It works perfectly, and if the installation survives the next days then I
will switch all of my machines to ext3 one after the other.

So, thank you all for the nice discussion!

Best regards,

Markus


--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm

--- SoupGate-Win32 v1.05