SDCard -- install here and deploy there?

Hi all,
I have Raspberries in different locations. One of them, more than 100
miles away didn't come back from a reboot. Hence, I suspect the SDCard to
be corrupted. This one worked one and a half year without any trouble,
but now its time seems over.
I have to install a new one. Well. But:
Since I have only little time when visiting, I'd like to prepare a fresh
install and put the card into the RPi when I am there.
Reason for asking is, that I have different machine type, and not two are
the same.
The card I have to install now is for machine type "Raspberry A" (SDCard /
Micro-SD with adapter), and the machines on which I could do the setup
here are "Raspberry 3 / quad core proc." or "Raspberry Zero / WLAN".
Can this work at all -- according to you experience -- to install on one
machine type and use in a completely different one?
Thanks for info!
Best regards,
Markus

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

If you're using Raspbian, it will probably work - other OSs may not. Why not hedge your bets (it could be an RPi complete failure) and get a new one to set up from scratch.

--

Chris Elvidge, England

100 SDCard That would be wise. A Zero is not exactly expensive... Also "didn't come back from a reboot" is a bit vague. Is that just waiting after issuing a reboot command or after a shut down and power cycle? Has it been power cycled? Has the SD card been reseated and the power cycled? Is there a micro SD to SD card adpater in use?

--
Cheers 
Dave.

Hi, what I've done in short:
I start a python script via crontab every 10 minutes which reads I2C data from a BME280 sensor. This script calculates the temperature, relative humidity and relative air pressure and sends it to a webserver.
This works perfectly.
To be on the safe side I make / made a reboot every night. From this the questioned machine didn't return, now. I see in the log that the last transmission was ok, then the reboot was started and the connection was lost. So, I doubt that the machine completely broke down. Most likely the SDCard gave up.
So, I also have to re-think if it is a good idea to make daily reboots even though the resources are not locked or eaten up. Maybe one reboot per week will also do?
P.S. I'd rather prefer to use "Raspberry Zero / WLAN" only for installation, since it has only Wifi and the network there is cable based.
Best regards,
Markus

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

1st rule of Linux :- Reboots are for hardware changes only

--
The people rule.

Or a kernel upgrade

Yes, yes, or for glibc upgrades. Well. But there are special cases where the USB (2.0) bus hangs if making snapshots from a webcam with fswebcam.
Then the machine has to be rebooted to reanimate the bus.
Best regards,
Markus

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

Can't help think why you start the script every 10 mins instead of having in a loop with a 10 minute sleep. If you want *exactly* 10 minutes between each sample one would have to code around the (variable) time taken for the data sampling, processing and up load but that's not difficult.
So it hasn't been power cycled and/or the SD card reseated? It could just be a build up of corrosion in the slot connections. Almost all Rapsberry boot problems I've had have been down to the latter or a bad micro SD to SD adapater.
Not sure why you think you need to reboot if it's only running a simple script. A Pi Zero here:
pi@PiZ-StoveB:~ $ w 19:37:30 up 49 days, 10:24,
That Pi has extra hardware attached: An ENC28J60 ethernet port, ex nokia LCD phone display (both on SPI buses), a rotary encoder and a PWM driven solid state relay (4 GPIO's). It's talking on two 1-Wire buses (2 more GPIO's) with eight or so devices across the two buses. Every minute it reads all the 1-Wire devices, updates the display, logs the data (over ethernet and locally), decides if the PWM drive to the SSR is correct for the data it gathered and adjusts as required. The display has an animated "heartbeat" symbol that shows the system is alive when the PWM is off. If the PWM is on it rotates the symbol at the appropiate speed. This is all under a multi threaded python script. Oh almost forgot a bi-color LED that flashes green as the 1-Wire buses are read or pulses red at rate determined by the PWM.
It's also running a web server (nginx) that can produce plots of the logged data on demand.
It's also running pi-hole.
As you can see it's doing all that and been up nearly 50 days... I've never known it crash in use.
Don't follow that either. B-) How does the WLAN help with getting an ethernet connection?

--
Cheers 
Dave.

WLAN doesn't help at all since at that site Wifi is deactivated. So, replacing an RPI-A with a RPI-Zero means one has to attach an eth-to-usb module. Better use it just for installing a new SDCard and then put this card into the RPI-A.
Well, some months ago I wrote here about lost SDCards during reboot on RPI-Zero. Every 10 or 20 reboots the card was no longer found during reboot and had to be put into a desktop Linux PC. Then the partitions on the card were found instantly and the card worked again even in a RPI- Zero. Whoever I asked -- no clue why.
So I decided to use RPI-Zero only for testing purposes and for logging data I use RPI-A, RPI-B and RPI-3.
So, still interested in getting infos about if or not it is possible to install a new SDCard in a different RPI and then just put it into the mentioned RPI-A and it works?
Thanks again, best regards,
Markus

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

On Thu, 22 Oct 2020 20:11:45 +0100 (BST), "Dave Liquorice" declaimed the following:
That aspect is quite logical... Using a crontab entry means if the script failed at some point for some reason, a fresh process will be started 10 minutes later (give or take OS overhead).
While an internal loop might support more precise 10-minute intervals, if the script dies then nothing will be left running.
For a remote sensor node that relays readings to another server, I do think I'd want as many temporary files as possible to be running in RAM disk, and not off the SD card.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Hi,
on my RPI-3 I used to have a watchdog service. But by some reason the system hung instead of doing a hardware-reboot. Maybe there was a kernel module mismatch. So, I switched it off.
Besides this, a watchdog may put your SDCard in a state where an fsck is demanded for. So, the system does not start non-interactively next time.
best regards,
Markus

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

Sorry, forget to mention:
Yes, I try to install Raspbian OS.
Reason for asking all this, is, that once I saw a warning saying that installing newer Raspberry machines like "Rpi-Zero" will only be possible by using the most recent Raspbian versions. Older ones cannot do.
So, it seems that there are indeed some differences regarding accessing the hardware architecture, but hopefully newer OS-es -- once installed -- can serve older hardware like "RPI-A" as well.
Let's see.
Best regards,
Markus

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

On Thu, 22 Oct 2020 22:15:44 -0000 (UTC), Markus Robert Kessler declaimed the following:
The 4B has a significantly different boot process, only supported with the Raspbian based on Debian 10 (Buster). The foundation actually released a Raspbian version some two weeks before Buster went official -- just because the 4B had been released, and no earlier Raspbian would support its boot.
The 3B+, I believe, also required some additions to the boot system, but I think that was still in the late Debian 9 (Stretch) period.
ALL Raspbian releases contain the boot configuration files needed by all Raspberry Pi models at the time of its release. The boot loader selects the correct file once it determines which board it is running on. Just look at all the bcm####*.dtb files in the FAT partition.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

I agree with that. The majority of downtime across my dozen Pis are issues after reboots. It ranges from network dropping out while booting, to hardware not being ready, and of course the SD card throwing a wobbly.
If the system is remote, I would not automatically reboot. If it needs rebooting, have someone there power cycle it, and wait until it has rebooted in case it needs another power cycle.
You can configure it to do an automated fsck on every reboot, which doesn't need any interaction. It can add a minute or two to the boot time, and you need to check the logs regularly as if the card is starting to get dodgy it can struggle on fixing itself up to the point where it dies completely. What you should do is replace it immediately there is any doubt.
But the best solution (if not using a Pi A or Zero) is to use something other than SD for the root filing system.
---druck

I've been doing that for all my Pi's for over 4 years now. I've got a BME280, lots of htu21df (temp and humidity) and a few DS18B20s (temp only).
I use crontab for all my discrete sensor measurement scripts, which run at 5 and 15 minute intervals.
If you register your script as a service with systemd you can get it to automatically restart after a crash.
I use looping for things which run more often than a minute, for example my CPU temperature averaging code takes reading every second, and produces a rolling 5 or 15 minute average, min and max values - which are then picked up by the cron script.
Yes. Its a compromise though, most of the 2MB to 10MB that my Pis write to the card every day is logging (the higher number on log rotates), so logging to RAM would make the SD card last a lot longer. But in the event of a crash resulting in a reboot, I wouldn't know what happened.
There is a lot of scope to turn off logging you don't need, and to set critical logging to SD card or a remote server, and not critical stuff to RAM. I haven't got around to sorting that out though,
---druck

Actually, that's been a rule for just about any serious professional shop since time immemorial. It was Microsoft who introduced the concept of re-booting anytime for the hell of it. Making spontaneous reboots part of computing culture is one more of their crimes against humanity.

--
/~\  Charlie Gibbs                  |  "Some of you may die, 
\ /        |  but it's sacrifice 

Go easy on him, he probably started out as a Microsoft vict^H^H^H^Huser.

--
/~\  Charlie Gibbs                  |  "Some of you may die, 
\ /        |  but it's sacrifice 

These days, where so much hardware is hot swappable (even on little computers, where USB is how much hardware is attached), I find kernel / low level software / underlying hypervisor issues to be the main reasons to reboot.
I attach and detach sound "cards" and disks with USB regularly on personal and $WORK laptops. The rack mounted $WORK servers get non-USB disks, power supplies, and network devices swapped without reboots. But all of them need reboots for kernel changes.
Elijah ------ the k8s pods get restarted on new hosts regularly as hardware needs work

You should always do a fresh install with the latest version in any case.
However, you may want to move an existing set up to a newer Pi, and this can be done even if that older install wouldn't work on the new Pi. What you need to do while running on the old Pi is to do a:-
sudo rpi-update
This will install all the newer components in /boot to allow use of any Pi. There is one gotcha though, you need to ensure your boot partition is big enough for al the new files. Older installs may have only had a 64MB boot partition, but 256MB is recommended now.
You can use gparted to enlarge the boot partition, but that requires moving the root partition upwards, which may take a long time for a large card. It may then be quicker to reformat and reinstall.
---druck