Just got a Pi1B. What can you actually do with it these days?

My main reason to pick a Pico over a Zero is reliability: I can be sure a Pico will boot up every time, but I find it a lottery whether a Pi will successfully boot or whether it's corrupted its SD for some reason or another and won't boot. I thought PiOSs was supposed to automatically fsck the disc and reboot with everything clean if a problem was detected, but for whatever reason this doesn't work - I have to keep pulling cards and fscking them before the Pi will boot again.

Anyone have any insights into why this is? These Pis are getting power pulled from them rather than a proper shutdown, but in the case where they're sensors or whatever it's just a fact of life they get power interrupted without shutdown sometimes.

One of my Pis has OpenWRT which I thought would help the corruption issue as it's designed for routers which don't modify their flash very often, but even that's got to the state of not booting - I need to investigate further.

Pi1B has 100M ethernet, but things get more awkward if you're on a Zero or a

Theo

I’ve just restored a Pi which had been gradually accumulating filesystem damage (without any reboots/power cycles) over time. It’s not the first time. My interpretation is that commodity micro-SD cards are mostly designed and tested on the assumption that the user will be storing a lot of smartphone photos on them, not a live root filesystem, and accordingly wear out disappointingly fast. But this is just guesswork.

Never had a problem. Mind you I do work to ensure my SDcards are 'read only..' by and large, and buy good ones

Yiou do. I have not hears that issue before ever

Indeed.

It's supported by evidence Many cards are basically made as WORM drives.

To get full RW performance takes a bit more

Had a look at this source file

Would be better to use poll(2) instead of select(2), to avoid the limitations of the latter. I notice you only handle one connection at a time.

Also, in the Check_restriction() function, you have

b = strdup( restrict );

but I never see anywhere that the string allocated in b is freed.

This is the kind of thing I would write in Python, rather than C. It would be a lot less code, and a lot less trouble worrying about memory.

There are filesystems available on a standard Linux kernel that include wear-levelling explicitly in their allocation algorithms. Maybe one of those would be better suited to an SD card than the usual default ext4.

While I'm sure that's sometimes the case, I don't think that's what's happening here. The SD card itself is fine - no read/write errors, no long pauses - but the filesystem is broken. Which is to be expected if it wasn't properly unmounted, but for some reason the automatic fsck-and-reboot mechanism in PiOS doesn't seem to work. I end up having to pull the SD, plug it into another machine, fsck it (both the FAT and the ext4), put it back into the Pi and then it boots.

If I don't do that and I have video attached to the Pi (ie I have already pulled the machine to connect to a monitor) the boot stalls somewhere but without a clear log as to why.

I also have this with a USB SSD, so I don't think it's a hardware problem. (although that one runs Ubuntu, maybe it's not so good at fsck-and-reboot?)

Theo

Fsck on reboot is not guaranteed. There are many ways to enforce this. Google them

I don’t cut power to my Pis regularly but when we’ve had power cuts here, they’ve come back cleanly as far as I remember.

Ubuntu and Raspberry Pi OS are both Debian variants, so a shared software issue is plausible. Saying anything beyond that would be guesswork though.

Yes. Although mine are relatively low usage so don't write to filesystenms aq lot

There isn’t actually a need to do an fsck normally. If you were using ext4 (or even ext3), that includes a journal. On reboot, you should see a message “replaying journal”, after which the filesystem should be back to a consistent state. This should be very quick, much quicker than a filesystem integrity check.

Back in the days when fsck was necessary, the OS would refuse to mount a volume if it was too badly damaged.

I've had times where it's the FAT partition that's been corrupted, which has resulted in a boot failure. I can't say for sure (because they're usually headless and I can't SSH in to check anything) but I suspect this is potentially a reliability problem - bad FAT partition means never booting as far as being able to run anything.

Theo

Always keep a copy of the files on the first partition of the SD card. They (copies) don't need to be on a FAT filesystem. Better even cross-copy the boot files to another machine (rsync?).

They're just the kernel and firmware, so trivial to recreate. But you can't do that on a headless machine that doesn't boot.

Theo

Ah, OK. FAT has no journal, of course, and being a simplistic filesystem design originating from the 8-bit era, it is particularly prone to corruption.

Does the FAT partition need to be writable, at all? It seems to me you want to put as little stuff on there as possible.

Yes it does, because unattended-upgrades will install kernel updates there.

Ideally you want it mounted read-only the rest of the time, but that's not what the OS does. You could have pre-/post- apt hooks for that, but it's getting into custom hackery territory. Because I tend to reflash from scratch with minimal config, I just want it to be reliable out of the box.

Theo

I have a few (dozen) of these - 1B and 1B+ (40 pin GPIO header). I run an older Debian Jessie on them for Linux and am experimenting with Devuan, but I also have my own bare-metal framework under which I run either my own RTB Basic (a modern basic where line numbers are optional) which supports high resolution graphics but not (yet) sound. I can also run my own OS under the same framework which is written in BCPL which allows local editing and compiling of BCPL programs.

What I don't have is good USB support, so no USB serial, Ethernet/Wi-Fi. Keyboard and mouse is the limit. The filing system is VFAT but the SD card driver is somewhat creative and really needs more work, but it's all a matter of time & energy.

I'm using the BCPL OS as the front-end to my campervan sensors and monitoring project but that's just a personal thing so I can have nice graphics, but again things I can't do (yet) is read the touchscreen in a nice way, so I'm looking at actually running the BCPL OS under a Linux that does support nice USB things. (The core of it all is really just a big (well, about 12KB) ARM32 assembler program that creates a VM for the compiled BCPL code)

So that's something that the old Pi's are good for I guess.

-Gordon

If you're going non-Linux, RISC OS runs well on the Pi1. It was designed for an 0.5MB 8MHz ARM2, so a 512MB 700MHz Pi1 is ample. It can't use multiple cores so the Pi1 being single core is no problem. Also it doesn't do wifi so you'll have to use the ethernet anyway. Most apps are designed to run on 1990s CPUs so a Pi is no sweat.

The main issue is likely to come for heavyweight apps like web browsers, but then you aren't running an ultra lightweight OS on underpowered hardware to surf the web anyway.

Theo