<Xogium>
kernel versions don't really anything significant, no, its just a version count
<peterm6881>
okie dokie, noted, thanks
<Xogium>
that's a corruption error due to being the power being cut
<Xogium>
v3s will most likely end up doing it to
<Xogium>
*too
<peterm6881>
no it comes about ever 10 seconds
<peterm6881>
every
<Xogium>
yes and its corruption, as I'm saying
<peterm6881>
let me time it
<Xogium>
your fs is corrupted and linux is telling you so
<peterm6881>
oh i see what you mean
<peterm6881>
understood
<peterm6881>
will it do that even if i do a clean reboot
<Xogium>
probably, the corruption errors won't be fixed
<peterm6881>
whats happening in your world?
<Xogium>
if you want to fix those errors, you have to burn the micro sd again, and there's clearly no point doing that since you are going to cut out the power again anyway
<peterm6881>
lol
<Xogium>
not much going on here atm
<peterm6881>
i wonder if thers a way we can tidy that up
<peterm6881>
there's
<Xogium>
fat32 is known for being, well. Very bad with corruption
<peterm6881>
ok i did a crash power cut on the lichee
<Xogium>
if you do them often enough it will also have this issue
<peterm6881>
ive logged in, still waiting for an error
<peterm6881>
can we use ntfs?
<Xogium>
but I suspect the fs it complains about isn't the boot partition but rather where the gps logs is stored which isn't very cool. Power cut causing corruption to the gps logs = possible data loss, which means it could be impossible to retrieve the logs and use them later
<peterm6881>
ive power cycled the lichee a second time, ill keep trying it
<peterm6881>
could ntfs be better?
<Xogium>
it could be also more sneaky than you'd think, silent data corruption is a nightmare
<Xogium>
ntfs might be better, however we don't have the rights on that, it is still protected by microsoft patants as far as I know so we don't have the right to build a commercial product that uses ntfs
<Speedsaver`>
Title: NTFS driver for Linux full guide in questions and answers | Paragon Software (at www.paragon-software.com)
<peterm6881>
ntfs3 is part of the kernel
<Xogium>
yeah, but I think it is unstable
<Xogium>
its a young project and it hasn't seen a lot of evolution, besides ntfs being part of the kernel doesn't mean much when you know the kernel is free software. The patant might not prevent you from using ntfs in that context, but selling a product which uses ntfs might be completely different
<peterm6881>
where are you getting that information?
<Xogium>
based myself on the time it took for the patants to expire on fat32 heh
<peterm6881>
if its in the kernel, you can use it, its bound to adhere to the open source license
<Xogium>
hmm
<Xogium>
probably ? I'll have a look anyway
<Xogium>
see if ntfs would even help with data corruption
<peterm6881>
Otherwise nobody would sell anythin using the linux kernel, it would be a legal nightmare if it had licensed shit at its core
<peterm6881>
FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
<peterm6881>
i got this during boot of the lichee, but it still doesnt print errors
<Xogium>
yup its not corrupted enough yet
<peterm6881>
i remember the orange pi always printed crap, even with a fresh sd card
<peterm6881>
or at least maybe after the first power interruption, it was normal
<peterm6881>
we discussed cleaning that up before, if you recall
<peterm6881>
the lichee build does seem to be more robust
<peterm6881>
ill keep killing it
<Xogium>
we did discusse cleaning up the messages like directory already present ! And a couple other that did show up
<peterm6881>
mwhuahahaha
<Xogium>
but never found what to do to clean them
<peterm6881>
yeah i just meant Opi has always printed crap we could do anything about
<peterm6881>
couldnt
<peterm6881>
ill keep killing lichee, but so far im convinced its better
<Xogium>
nah its not, you just get lucky
<peterm6881>
as you wish ;)
<Xogium>
data corruption has the same laws on any device. Especially if both devices use the same filesystems
<peterm6881>
im delighted with Gadget Serial
<peterm6881>
outstanding Xogium
<peterm6881>
im gonna do a fresh sd card both and see which one i can kill first
<Xogium>
LOL
<Xogium>
@phoog The ExFAT and VFAT patents prevented companies from producing products that used ExFAT and the VFAT extensions without a licence. Microsoft even sued one company, TomTom, for failing to obtain a licence. –
<peterm6881>
do you use dcfldd?
<Xogium>
what's that ?
<Xogium>
that dd that can do 3 tons of copy at once ?
<peterm6881>
but was tomtom using linux, or embedded windows?
<Xogium>
no idea, that isn't mentioned
<Xogium>
but it just made me laugh
<peterm6881>
i bet its embedded windows
<peterm6881>
i think if its in the kernel, im happy to go with it
<peterm6881>
yes the thing is dcfldd is way faster even for burning one card
<Xogium>
I just do the dd way, personally
<peterm6881>
would be worth you trying it
<Xogium>
I don't trust that other dd, hasn't been worked on for years and has some issues
<peterm6881>
ok as you wish
<Xogium>
besides here it takes like... 20 to 30 seconds to burn a lichee card
<Xogium>
This tool is not suitable for imaging faulty drives:
<Xogium>
dcfldd is based on an extremely old version of dd: it's known that dcfldd will misalign the data in the image after a faulty sector is encountered on the source drive (see the NIST report), and this kind of bug (wrong offset calculation when seeking over a bad block) was fixed for dd in 2003 (see the fix in the mailing list);
<Xogium>
similarly, dcfldd can enter an infinite loop when a faulty sector is encountered on the source drive, thus writing to the image over and over again until there is no free space left.
<Xogium>
mm hmm
<Xogium>
last update: 2013-04-22. Ouch
<peterm6881>
ok ok lol
<Xogium>
I mean I knew it was old, but didn't think *that* old
<Xogium>
almost 9 years
<peterm6881>
its about 3 seconds for one card, 372 MByte
<peterm6881>
if there is a way to do multiple cards with dd id prolly use it
<Xogium>
yeah but fast doesn't always means reliable. I'm sure some of the weird issues you've had with some of your micro sd could be explained because of dcfldd
<peterm6881>
i wonder if dd does work now the same way, i might try it
<peterm6881>
for production ill probably get a proper duplicator
<Xogium>
dd is one device at a time
<Xogium>
but for me it doesn't matter much, cause my sd card adapter has only one slot for each type, full sd and micro sd, and guess what ? You can't insert both type of cards at once
<peterm6881>
:)
<peterm6881>
ok both survived crash 1
<peterm6881>
ok both survived crash 2
<peterm6881>
Opi0 errored at crash 3
<Xogium>
started to error out with fat32 stuff ?
<peterm6881>
hmm....Opi0 seems to have recovered, bizarrely
<peterm6881>
i'll keep up the killing spree
<peterm6881>
im a serial killer
<Xogium>
lol
<Xogium>
literally so
<peterm6881>
i spoke too soon , OPi0 printed the error before I have a chance to disconnect it, its definitely corrupt
<peterm6881>
not as often as before, so you're right on the money about why it happens
<peterm6881>
ill keep killing Lichee
<Xogium>
yeah its hmm
<Xogium>
its definitely the data partition, not the boot one
<peterm6881>
lichee survived crash 4
<peterm6881>
lichee survived crash 5
<Xogium>
nice
<peterm6881>
lichee survived crash 6
<Xogium>
did both boards have a gps fix or none them didn't ?
<peterm6881>
i really dont think its luck. I believe it will error, but im certain its more robust than OPi0, even though i accept that makes no sense
<peterm6881>
hmm...the OPi0 has a fix but the lichee doesnt
<peterm6881>
but i think both will be writing to the log
<peterm6881>
but i like the way you're thinking
<peterm6881>
the nmea sentences dont stop just because there's no fix
<Xogium>
can you try with a fix on the lichee ?
<peterm6881>
i cant because of the laws of physics, the NEC is too far from the window and i cant talk to it over a usb extension cable
<Xogium>
wellp damn
<peterm6881>
although im not sure if I tried that with gadget....
<peterm6881>
let me try
<Xogium>
would be good to test that case as well.. Hmm
<peterm6881>
yeah its good thinking
<peterm6881>
still no errors after crash 6
<peterm6881>
im using a different board and card, so I'll burn it fresh
<Xogium>
good thinking, fresh data for such a test is essential
<peterm6881>
burning now
<peterm6881>
i may not be able to talk to it, ill know in a sec
<peterm6881>
great news, I can talk to it over a usb extension cable using gadget serial. I know for a fact I could never do that powering and trying to connect with the Prolific bridge
<Xogium>
niceness
<peterm6881>
we have a fix
<peterm6881>
now to crash it into the wall
<peterm6881>
BRACE! BRACE!
<Xogium>
BRACE FOR IMPACT !
<Xogium>
lol I'm saying that while meanwhile Simon is playing 1000 miles
<peterm6881>
hehe
<peterm6881>
ok im logged in
<peterm6881>
no errors so far but ill wait a while
<Xogium>
you can also run something like dmesg -t to print the entire kernel logs on screen, just in case they don't print on gadget for some reason
<peterm6881>
def no errors so far, so lichee survived crash 1 with a fix
<peterm6881>
here we go again, hold on tight
<peterm6881>
loving Gadget Serial, its really coming into its own now
<peterm6881>
lichee survived crash 2
<peterm6881>
lichee survived crash 3
<Xogium>
nice
<peterm6881>
lichee survived crash 4, still no errors. Makes no sense , agreed, but it already does appear to be more robust than OPi0
<peterm6881>
Last login: Fri Mar 11 07:34:51 UTC 2022 on ttyGS0
<peterm6881>
#
<peterm6881>
Last login: Fri Mar 11 07:35:12 on ttyGS0
<peterm6881>
sitting quite happily
<peterm6881>
annoying errors on the console was a normal thing for OPi0
<Xogium>
strange but seems to be the case indeed
<Xogium>
I have no explanation
<peterm6881>
whats that uptime command you use
<peterm6881>
yeah things are looking REALLY good Xogium
<Xogium>
you just named it ;)
<Xogium>
uptime
peter_ has joined #Speedsaver
peter_ is now known as Guest4456
Guest4456 has quit [Client Quit]
peter__ has joined #Speedsaver
peterm6881 has quit [Read error: Connection reset by peer]
<peterm6881>
do those load figures look good, whts the range?
<peterm6881>
whats *
<peterm6881>
i'll leave it running after crash 7 to see if it errors after an extended uptime
<peterm6881>
should i log in, or leave it at login prompt?
<peterm6881>
should i log in, or leave it at login prompt?
<peterm6881>
oops
<peterm6881>
sry
<peterm6881>
wrong window
<peterm6881>
I'll log in, because thats were id always have seen the errors before. But I dont think it actually matters
<Xogium>
well load average being 0.50 means that the cpu is loaded 50% since its a single core
<Xogium>
for a 16 cores machine, 0.5 load would be 50% of one single core. Full cpu load would be 16.0
<peterm6881>
u flexing?
<peterm6881>
up 5:15, 0 users, load average: 0.49, 0.54, 0.54
<peterm6881>
not a single error message
<peterm6881>
ive crashed it again now it has a nice fat log file
<Xogium>
hmm
ChanServ has quit [*.net *.split]
peterm6881 has quit [*.net *.split]
<Xogium>
I get your point that somehow the lichee seems more resistant and stable tha nthe orange pi, but I think it would be fair to check out some other solution that would at minimum make it harder for the filesystem to get corrupted, or at least make it able to fix itself when damaged
peterm6881 has joined #Speedsaver
ChanServ has joined #Speedsaver
<peterm6881>
wb
<peterm6881>
50% average is pretty much ideal, it proves we arent overpowered or underpowered
<Xogium>
well its fine for our use case, certainly
<peterm6881>
quite :)
<peterm6881>
seems like a good choice for Speedsaver
<Xogium>
my stm32mp157 based player for the house uses about 25% cpu load on average when plauing music
<Xogium>
which is good too, this thing is a dual core
<Xogium>
*playing
<Xogium>
staying at around 0.20 when idling
<peterm6881>
so bizarre fat32 file system plays up on OPi0 after the 3rd crash, and i havent got Lichee to error yet
<Xogium>
I suspect you got errors but they are not fatal
<Xogium>
like invisible corruption that doesn't affect the fs too much
<peterm6881>
i decided not to look for invisible errors ;)
<peterm6881>
hope you dont mind
<Xogium>
the big problem with fat32 isn't that its corrupts easily, but the fact that once it corrupted it can't be fixed
<Xogium>
fsck might help a little but it just solves common issues, its not a full filesystem checker like there is for ext4
<peterm6881>
i think we're in a good spot. Just a couple of software tweaks for Steve
<Xogium>
and as mentioned earlier the no journal thing is real bad for filesystem integrity
<peterm6881>
what about your idea to use mtp?
<peterm6881>
abstraction
<peterm6881>
sounds like fun :)
<Xogium>
well with mtp, we could potentially expose the content of the data directory over usb, the same as with a gadget for serial, in fact there's probably a way to have the board do all 2 of them at once
<Xogium>
but the data directory itself could be formatted in ext4, or some other filesystem that have a better chance at dealing with corruption
<Xogium>
the fact it is abstracted means it would also work in windows, even if windows itself is a dummy and doesn't handle ext4
<peterm6881>
sounds like its worth exploring#
<peterm6881>
exploring
<Xogium>
that's not to say ext4 is indestructible. You can really do a number on it if you're not careful
<Xogium>
but it should be a lot harder
<peterm6881>
brb
<Xogium>
the last time I did a real number on a ext4 filesystem was during an update of my router, power outage happened at exactly the wrong moment. It didn't just fuck up the installation of the new systemd version, no sir. It went so bad the whole filesystem was corrupted and fsck didn't even recognize the journal that would allow to fix it
<Xogium>
that was before I switched to buildroot and decided the worse a power outage could do is a) reset my router to a sane and default state because read-only filesystem combined with running everything in ram and b) possibly damage the hardware with a power surge. Lucky that never happened
<peterm6881>
espressobin
<peterm6881>
up 2:07, 0 users, load average: 0.56, 0.56, 0.55
<peterm6881>
no errors
<peterm6881>
cant make it happen
<peterm6881>
yeah we have a lot to thank that espressobin for :)
peterm6881 has quit [Remote host closed the connection]