- What can be done remotely now to "repair" the FS? -- I can hardly pull
the card out of it and run an fsck on a second machine via VPN.
B.t.w., badblocks came back with 0 errors, the SD card seems still ok.
On Fri, 19 Mar 2021 22:55:43 +0000, Markus Robert Kessler wrote:
- What can be done remotely now to "repair" the FS? -- I can hardlyA few questions:
pull the card out of it and run an fsck on a second machine via VPN.
B.t.w., badblocks came back with 0 errors, the SD card seems still ok.
- How full is the card? "df -h" should show that.
- How long has thus card been in use?
- Are you running 'fstrim' on the card and, if so , how frequently?
-- but see below ---
- Can you describe how you collect and store data on the Pi4 - by that I
mean how big are the files, how many are held on the Pi, how long is
each file held, or are you using a database?
- If you're using files, how is each written to? IOW is it left open and
data added until it hits a preset limit and a new one is opened, or is
the file normally closed and every so often the file is opened, data
appended to it and the file closed again. How often are old files
discarded to make room for more data and how are the old files chosen
for deletion?
- How easy is it to change the maximum number and size of files [or
rows in the database table(s)] on the Pi?
** Guess **
Could it be that you have never run fstrim? If so, running it may help: something like "sudo fstrim -v /home" should do the trick - however I've
just tried it on a Pi 2B running Buster and, since I don't usually run
fstrim on the Pi, I thought it would do its thing (I run it weekly on a Lenovo laptop with a Sanyo 120 GB SSD and Fedora Linux; several Kb of
blocks are trimmed each time fstrim is run. However, on the Pi 2 (16GB
SD card fitted) 'fstrim' just reports zero bytes trimmed, i.e. it didn't
do anything.
I assume from this that by design fstrim does nothing when pointed at a partition on and SD card. Can anybody confirm this? The manpage is
silent about using in on SD cards.
However, the other stuff I asked about should let us make sensible suggestions.
I assume from this that by design fstrim does nothing when pointed at a >partition on and SD card. Can anybody confirm this? The manpage is silent >about using in on SD cards.
On Sat, 20 Mar 2021 00:00:55 -0000 (UTC), Martin Gregorie <martin@mydomain.invalid> declaimed the following:
are,I assume from this that by design fstrim does nothing when pointed at a >>partition on and SD card. Can anybody confirm this? The manpage isIt does, however, state:
silent about using in on SD cards.
"""
-a, --all
Trim all mounted filesystems on devices that support the
discard operation. The other supplied options, like
--offset, --length and --minimum, are applied to all these
devices. Errors from filesystems that do not support the
discard operation, read-only devices and read-only
filesystems are silently ignored.
"""
I would suspect SD cards do not have "discard" (after all, they
for the most part, optimized for FAT file systems)
On Sat, 20 Mar 2021 00:00:55 +0000 Martin Gregorie wrote:
installation was end of November on a fresh 16 GB card.
As recommended in this group, I did not perform reboots every day /OK - nothing wrong so far
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 $
$
$ 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 $
Well, indeed, I never used fstrim so far.
But in this case it seems to do nothing, though.
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.
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:OK, but is it a noname card or from one of the better brands? I've been
installation was end of November on a fresh 16 GB card.
using Sandisk for everything (RPi, camera, glider navigation system and flight logger) a few years now and have had no card-related problems.
As recommended in this group, I did not perform reboots every day /OK - nothing wrong so far
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 $
$
$ cd /etc/resolvconf/update-libc.d $ ll ls: cannot accessI think you'll find that avahi-daemon is only needed if your RPi needs
'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 $
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.OK
But in this case it seems to do nothing, though.
Data is received via I2C bus, processed and transmitted to a webserverOK
outside. These are only some Kilobytes, and there is no sensor data
stored on disk.
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.
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...
So, what exactly did you run? Just fsck.ext4? If so, with what options?
Did you make a backup copy, as I also suggested, before running
fsck.ext4?
/dev/sdb' (stopping after some seconds) on a linux machine, then createa Win95 partition with 256MB and the whole remaining space with linux filesystem using fdisk.
ext3 wont stop you getting these problems, but rather they will cause
serious corruption, so stick with ext4.
Hi all,
I have several Raspberries running. One of them is used to collect sensor data, and since it is located > 100 miles distant, it is currently only accessible via VPN.
Last reboot was end of November and now I have to see that a stat, ls
etc. to some directories on the ext4 partition return an error alert "structure need cleaning".
Reading in some RPi fora it looks like this is a common problem related
to ext4.
So, some questions (since I don't have the chance to drive to that
location now and replace the SD card / installation):
- Has someone already installed Raspbian (Buster) on ext3 instead of ext4, and if so, will this prevent the card from further problems like this?
- What can be done remotely now to "repair" the FS? -- I can hardly pull
the card out of it and run an fsck on a second machine via VPN.
B.t.w., badblocks came back with 0 errors, the SD card seems still ok.
I assume that the next reboot will be the last one...
So, any ideas highly appreciated. -- Thanks!
snip [...]
To make things easier, some weeks ago I started with setting up one
sample machine very carefully, I installed everything needed, created
the necessary users, made all updates, and then I created two tgz-balls,
one for boot and one for rootfs.
Making a new instance out of it can now be easily done by taking a new
SD card out of the box, overwrite the first hundred MBs with 'cat
/dev/zero
/dev/sdb' (stopping after some seconds) on a linux machine, then createa Win95 partition with 256MB and the whole remaining space with linux filesystem using fdisk.
Afterwards I only have to format both partitions with the appropriate filesystem type and restore the backups.
Of course, the machine name has to be changed in /etc/hosts and /etc/ hostname, the most recent updates have to be applied and so on.
That makes sense. Thanks.
It appears that the R-Pi organization has dropped the NOOBS installer, and only provides downloads for each specific OS.
Sysop: | Rempala |
---|---|
Location: | Richlands, NC |
Users: | 106 |
Nodes: | 10 (0 / 10) |
Uptime: | 217:27:01 |
Calls: | 216 |
Files: | 6 |
Messages: | 110,983 |