[opensuse] I should know this ... how to resume boot after emergency shell?
I have Leap 15.0 running on an ARM board and something got screwed up a couple of days ago. Boot-up fails : [FAILED] Failed to start udev Coldplug all Devices. I am not sure it is related, but after this, four other services or devices fail: [ TIME ] Timed out waiting for device dev-ttyS0.device. [DEPEND] Dependency failed for Serial Getty on ttyS0. [ TIME ] Timed out waiting for device dev-mmcblk0p1.device. [DEPEND] Dependency failed for File System Check on /dev/mmcblk0p1. [DEPEND] Dependency failed for /boot/efi. [DEPEND] Dependency failed for Local File Systems. [DEPEND] Dependency failed for Early Kernel Boot Messages. [ TIME ] Timed out waiting for device dev-disk-by\x2dlabel-SWAP.device. [DEPEND] Dependency failed for /dev/disk/by-label/SWAP. [DEPEND] Dependency failed for Swap. and I am given the emergency shell over the serial interface. It seems odd that "dev-ttyS0.device" times out - as I am using it :-) Even after mounting /boot/efi and adding swap, and I hit Control-D or type "systemctl default", the system will just hang. Is there a better/correct way? While in the emergency shell, I have even re-built the initrd, sort of just in case, but that only made things worse. -- Per Jessen, Zürich (4.2°C) member, openSUSE Heroes. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/12/2019 15.15, Per Jessen wrote:
I have Leap 15.0 running on an ARM board and something got screwed up a couple of days ago. Boot-up fails :
[FAILED] Failed to start udev Coldplug all Devices.
I am not sure it is related, but after this, four other services or devices fail:
[ TIME ] Timed out waiting for device dev-ttyS0.device. [DEPEND] Dependency failed for Serial Getty on ttyS0. [ TIME ] Timed out waiting for device dev-mmcblk0p1.device. [DEPEND] Dependency failed for File System Check on /dev/mmcblk0p1. [DEPEND] Dependency failed for /boot/efi. [DEPEND] Dependency failed for Local File Systems. [DEPEND] Dependency failed for Early Kernel Boot Messages. [ TIME ] Timed out waiting for device dev-disk-by\x2dlabel-SWAP.device. [DEPEND] Dependency failed for /dev/disk/by-label/SWAP. [DEPEND] Dependency failed for Swap.
and I am given the emergency shell over the serial interface. It seems odd that "dev-ttyS0.device" times out - as I am using it :-)
Maybe the service can not start precisely because it is already in use since booting, by the kernel.
Even after mounting /boot/efi and adding swap, and I hit Control-D or type "systemctl default", the system will just hang. Is there a better/correct way?
^D is the correct way, I understand. Probably typing "exit" would do the same. But can fail if the issues were not solved. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXePN9gAKCRC1MxgcbY1H 1XrtAJ4k11YCqqSBNQLuxwgTuqlBxQEtiACcC46bDQFbfkz4pIgb9zrGlE0DSlU= =wxq4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/12/2019 15.15, Per Jessen wrote:
I have Leap 15.0 running on an ARM board and something got screwed up a couple of days ago. Boot-up fails :
[FAILED] Failed to start udev Coldplug all Devices.
I am not sure it is related, but after this, four other services or devices fail:
[ TIME ] Timed out waiting for device dev-ttyS0.device. [DEPEND] Dependency failed for Serial Getty on ttyS0. [ TIME ] Timed out waiting for device dev-mmcblk0p1.device. [DEPEND] Dependency failed for File System Check on /dev/mmcblk0p1. [DEPEND] Dependency failed for /boot/efi. [DEPEND] Dependency failed for Local File Systems. [DEPEND] Dependency failed for Early Kernel Boot Messages. [ TIME ] Timed out waiting for device dev-disk-by\x2dlabel-SWAP.device. [DEPEND] Dependency failed for /dev/disk/by-label/SWAP. [DEPEND] Dependency failed for Swap.
and I am given the emergency shell over the serial interface. It seems odd that "dev-ttyS0.device" times out - as I am using it :-)
Maybe the service can not start precisely because it is already in use since booting, by the kernel.
Sounds like a possible, I'll try without the serial console. Does not explain why it would not mount swap and /boot/efi though.
Even after mounting /boot/efi and adding swap, and I hit Control-D or type "systemctl default", the system will just hang. Is there a better/correct way?
^D is the correct way, I understand. Probably typing "exit" would do the same. But can fail if the issues were not solved.
Okay, I have tried all of those - Ctrl-D, "systemctl default", exit etc. I only get a confirmation that systemd is starting "default" target. -- Per Jessen, Zürich (3.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
I have Leap 15.0 running on an ARM board and something got screwed up a couple of days ago. Boot-up fails :
Correction, it got screwed up last night, at 17:30. Not that I know what happened. I was working on a webpage with thttpd. -- Per Jessen, Zürich (3.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
01.12.2019 17:15, Per Jessen пишет:
I have Leap 15.0 running on an ARM board and something got screwed up a couple of days ago. Boot-up fails :
[FAILED] Failed to start udev Coldplug all Devices.
I am not sure it is related, but after this, four other services or devices fail:
[ TIME ] Timed out waiting for device dev-ttyS0.device.
Yes, it is related.
[DEPEND] Dependency failed for Serial Getty on ttyS0. [ TIME ] Timed out waiting for device dev-mmcblk0p1.device. [DEPEND] Dependency failed for File System Check on /dev/mmcblk0p1. [DEPEND] Dependency failed for /boot/efi. [DEPEND] Dependency failed for Local File Systems. [DEPEND] Dependency failed for Early Kernel Boot Messages. [ TIME ] Timed out waiting for device dev-disk-by\x2dlabel-SWAP.device. [DEPEND] Dependency failed for /dev/disk/by-label/SWAP. [DEPEND] Dependency failed for Swap.
and I am given the emergency shell over the serial interface. It seems odd that "dev-ttyS0.device" times out - as I am using it :-)
systemd is only aware of devices that have been announced by udevd and "udev Coldplug all Devices" ensures udevd sends these announcements for devices that became available before udevd started ("cold boot"). So if this service failed, udevd is not aware of devices and so is not systemd.
Even after mounting /boot/efi and adding swap, and I hit Control-D or type "systemctl default", the system will just hang. Is there a better/correct way?
Well, nothing changed from systemd point of view, so it likely continues to wait for missing devices. Anything in logs? This service calls "udevadm trigger" which simply walks /sys and writes into .../uevent file. The only reason for it to fail would be either out of memory or failure to load/execute binary. It really looks like hardware issue to me (corrupted files or flaky memory).
While in the emergency shell, I have even re-built the initrd, sort of just in case, but that only made things worse.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
01.12.2019 17:15, Per Jessen пишет:
I have Leap 15.0 running on an ARM board and something got screwed up a couple of days ago. Boot-up fails :
[FAILED] Failed to start udev Coldplug all Devices.
I am not sure it is related, but after this, four other services or devices fail:
[ TIME ] Timed out waiting for device dev-ttyS0.device.
Yes, it is related.
[DEPEND] Dependency failed for Serial Getty on ttyS0. [ TIME ] Timed out waiting for device dev-mmcblk0p1.device. [DEPEND] Dependency failed for File System Check on /dev/mmcblk0p1. [DEPEND] Dependency failed for /boot/efi. [DEPEND] Dependency failed for Local File Systems. [DEPEND] Dependency failed for Early Kernel Boot Messages. [ TIME ] Timed out waiting for device [ dev-disk-by\x2dlabel-SWAP.device. [DEPEND] Dependency failed for /dev/disk/by-label/SWAP. [DEPEND] Dependency failed for Swap.
and I am given the emergency shell over the serial interface. It seems odd that "dev-ttyS0.device" times out - as I am using it :-)
systemd is only aware of devices that have been announced by udevd and "udev Coldplug all Devices" ensures udevd sends these announcements for devices that became available before udevd started ("cold boot"). So if this service failed, udevd is not aware of devices and so is not systemd.
Got it.
Even after mounting /boot/efi and adding swap, and I hit Control-D or type "systemctl default", the system will just hang. Is there a better/correct way?
Well, nothing changed from systemd point of view, so it likely continues to wait for missing devices.
Anything in logs? This service calls "udevadm trigger" which simply walks /sys and writes into .../uevent file. The only reason for it to fail would be either out of memory or failure to load/execute binary.
I have just found it - udevadm core dumps. SEGV. (from the systemctl status systemd-udev-trigger output).
It really looks like hardware issue to me (corrupted files or flaky memory).
I'm beginning to wonder about that too. If maybe the SD flash has gone bad. -- Per Jessen, Zürich (3.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
I'm beginning to wonder about that too. If maybe the SD flash has gone bad.
Just in case anyone is following this - it does indeed look like a problem with the SD flash. I did a complete restore from another system copy, somewhat older. I got it to boot, it looked okay at first, but as I was fiddling with a few things, it threw a whole load of IO errors and mounted root read-only. It is a 16Gb Kingston card, probably a couple of years old, I'm not sure. This is really my only worry with these ARM boards (I have a few in production) - the long-term stability/reliability of the flash cards. -- Per Jessen, Zürich (3.7°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 18.09, Per Jessen wrote:
Per Jessen wrote:
I'm beginning to wonder about that too. If maybe the SD flash has gone bad.
Just in case anyone is following this - it does indeed look like a problem with the SD flash. I did a complete restore from another system copy, somewhat older. I got it to boot, it looked okay at first, but as I was fiddling with a few things, it threw a whole load of IO errors and mounted root read-only.
It is a 16Gb Kingston card, probably a couple of years old, I'm not sure.
This is really my only worry with these ARM boards (I have a few in production) - the long-term stability/reliability of the flash cards.
What could you do for testing it, I wonder? -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sun, 1 Dec 2019 19:22:37 +0100 "Carlos E.R." <robin.listas@gmx.es> wrote:
On 01/12/2019 18.09, Per Jessen wrote:
Per Jessen wrote:
I'm beginning to wonder about that too. If maybe the SD flash has gone bad.
Just in case anyone is following this - it does indeed look like a problem with the SD flash. I did a complete restore from another system copy, somewhat older. I got it to boot, it looked okay at first, but as I was fiddling with a few things, it threw a whole load of IO errors and mounted root read-only.
It is a 16Gb Kingston card, probably a couple of years old, I'm not sure.
This is really my only worry with these ARM boards (I have a few in production) - the long-term stability/reliability of the flash cards.
What could you do for testing it, I wonder?
Well apart from the recent discussion of how to test for fake cards, the main way to ensure longevity is to NOT test it! i.e. the fewer writes the better. Are openSUSE ARM versions configured for low-write? e.g. storing logs in RAM etc etc. I have one Raspbian system that hasn't written a log entry since July :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/12/2019 21.11, Dave Howorth wrote:
On Sun, 1 Dec 2019 19:22:37 +0100 "Carlos E.R." <robin.listas@gmx.es> wrote:
My thunderbird has crashed and does not allow me to recover the draft. It is encrypted, and crashes. Suddenly it has a problem with encryption? :-? Let's see if I can remember what I said.
What could you do for testing it, I wonder?
Well apart from the recent discussion of how to test for fake cards, the main way to ensure longevity is to NOT test it! i.e. the fewer writes the better.
It should not harm a single write to all blocks. Now, I'm unsure how to do that - perhaps a dd of a huge file with write block set to the same as the physical write block size of the card. Which is... what? :-?
Are openSUSE ARM versions configured for low-write? e.g. storing logs in RAM etc etc. I have one Raspbian system that hasn't written a log entry since July :)
I prefer a permanent log, but written, say, once per hour. The laptop-mode-tools had scripts to do that. And now Tunderbird says it can not use Enigmail. WTF? Then crashes. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 12/01/2019 02:11 PM, Dave Howorth wrote:
Well apart from the recent discussion of how to test for fake cards, the main way to ensure longevity is to NOT test it! i.e. the fewer writes the better. Are openSUSE ARM versions configured for low-write? e.g. storing logs in RAM etc etc. I have one Raspbian system that hasn't written a log entry since July :)
I guess I can add a datapoint at least to the "how long can it last" discussion. I've got an older Pi 2B that has been running continually since Nov. 2016 without any issues -- so I know they last that long :) Though it does look like I get daily log messages written. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On Sun, 1 Dec 2019 19:22:37 +0100 "Carlos E.R." <robin.listas@gmx.es> wrote:
On 01/12/2019 18.09, Per Jessen wrote:
Per Jessen wrote:
I'm beginning to wonder about that too. If maybe the SD flash has gone bad.
Just in case anyone is following this - it does indeed look like a problem with the SD flash. I did a complete restore from another system copy, somewhat older. I got it to boot, it looked okay at first, but as I was fiddling with a few things, it threw a whole load of IO errors and mounted root read-only.
It is a 16Gb Kingston card, probably a couple of years old, I'm not sure.
This is really my only worry with these ARM boards (I have a few in production) - the long-term stability/reliability of the flash cards.
What could you do for testing it, I wonder?
Well apart from the recent discussion of how to test for fake cards, the main way to ensure longevity is to NOT test it! i.e. the fewer writes the better.
Hehe, yeah.
Are openSUSE ARM versions configured for low-write?
I doubt it - I have not looked at it in any detail, but my impression is they are just standard Leap built for ARM, prepared as a JeOS image.
e.g. storing logs in RAM etc etc. I have one Raspbian system that hasn't written a log entry since July :)
My systems need to write something every minute. They're generally monitoring various sensors. I've just ordered some new SD cards, 16Gb Sandisk, about 8francs apiece. I would not mind paying double or triple that, if I could be certain I'd be getting longer-lived, more reliable cards. -- Per Jessen, Zürich (3.7°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Op maandag 2 december 2019 09:17:01 CET schreef Per Jessen:
My systems need to write something every minute. They're generally monitoring various sensors.
I've just ordered some new SD cards, 16Gb Sandisk, about 8francs apiece. I would not mind paying double or triple that, if I could be certain I'd be getting longer-lived, more reliable cards.
I did have the same problem with this SanDisk micro-SD card. The system does not see the card at all. It has been in use for at least one year in a Tumbleweed ARM system as the main storage system. It has a five year guarantee, so my supplier will replace the card. I only lost half a day of collected data; backup was once a day, is now once per hour. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/12/2019 à 11:11, Freek de Kruijf a écrit :
It has a five year guarantee, so my supplier will replace the card.
but the price dropped since then :-( looks like somebody renamed the thread, I can't find the start in list archives :-( (arm problem?) I'm really interested to know if there is a tool to know the sd card state (without burning it), but some search on the net seems to say there is none (an atp one is no more available AFAIK). That said I found some "industrial" grade sd card that may be better (probably at a high price) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 11.47, jdd@dodin.org wrote:
Le 02/12/2019 à 11:11, Freek de Kruijf a écrit :
It has a five year guarantee, so my supplier will replace the card.
but the price dropped since then :-(
looks like somebody renamed the thread, I can't find the start in list archives :-( (arm problem?)
Month change? <https://lists.opensuse.org/opensuse/2019-12/msg00005.html>
I'm really interested to know if there is a tool to know the sd card state (without burning it), but some search on the net seems to say there is none (an atp one is no more available AFAIK).
That said I found some "industrial" grade sd card that may be better (probably at a high price)
Ah, that's interesting. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeTwUQAKCRC1MxgcbY1H 1bwNAJ9fR0v8eUrrXAF82h1fNyXrj+ZxnACeOnx3FxnV+//sRGSgSB3baCchlPs= =PmZK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd@dodin.org wrote:
Le 02/12/2019 à 11:11, Freek de Kruijf a écrit :
It has a five year guarantee, so my supplier will replace the card.
but the price dropped since then :-(
looks like somebody renamed the thread, I can't find the start in list archives :-( (arm problem?)
Yes, I renamed it, sorry.
That said I found some "industrial" grade sd card that may be better (probably at a high price)
Would you mind sharing the information with us? -- Per Jessen, Zürich (3.5°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/12/2019 à 12:12, Per Jessen a écrit :
jdd@dodin.org wrote:
That said I found some "industrial" grade sd card that may be better (probably at a high price)
Would you mind sharing the information with us?
simply searching google https://www.atpinc.com/products/industrial-sd-cards https://www.kingston.com/en/memory-cards/industrial-temperature-microsd-uhs-... https://www.rs-online.com/designspark/are-you-using-the-right-sd-card pretty expensive for the capacity https://www.amazon.fr/s?k=industrial+sd+card&i=computers&__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&ref=nb_sb_noss jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd@dodin.org wrote:
simply searching google
Good point - I was not aware there would be cards out there. Hmm - Transend 16Gb Industrial - 368.00. Only about 46 times more than for the "regular" kind. However, Swissbit 16Gb card - 46.00. That's more in my range, but I don't like that they talk about "industrial temperature range" only. That is the normal -40 to +85, but that's not the requirement I have. -- Per Jessen, Zürich (3.3°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/12/2019 à 13:05, Per Jessen a écrit :
jdd@dodin.org wrote:
simply searching google
Good point - I was not aware there would be cards out there.
Hmm - Transend 16Gb Industrial - 368.00. Only about 46 times more than for the "regular" kind.
I see sometime such prices, not sure they are real. May be just not available or dot error jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2019-12-02 08:56 AM, jdd@dodin.org wrote:
Hmm - Transend 16Gb Industrial - 368.00. Only about 46 times more than for the "regular" kind.
I see sometime such prices, not sure they are real. May be just not available or dot error
Several years ago, I used to work with VoIP PBXs. The manufacturer had their own version of flash card, which was not avaiable elsewhere. They were expensive. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed? - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeTumgAKCRC1MxgcbY1H 1XSJAJ9WOf1TKgtw7ZtpavqNDdQTIP1WWQCeOWFXxIJivKEe7AANOQI7SdzJf4Q= =gr+A -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Perhaps, but at the risk of losing the data. -- Per Jessen, Zürich (3.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/12/2019 à 12:12, Per Jessen a écrit :
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Perhaps, but at the risk of losing the data.
data may be loosed on the two situations :-( but is there not an usb plug allowing to use real ssd? (msta, for example)? jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd@dodin.org wrote:
Le 02/12/2019 à 12:12, Per Jessen a écrit :
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Perhaps, but at the risk of losing the data.
data may be loosed on the two situations :-(
but is there not an usb plug allowing to use real ssd? (msta, for example)?
Actually, not on these boards - https://www.friendlyarm.com/index.php?route=product/product&product_id=151 They _do_ have USB functionality, but it would make the whole setup bigger and bulkier. -- Per Jessen, Zürich (3.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 02 Dec 2019 12:56:56 +0100 Per Jessen <per@computer.org> wrote:
jdd@dodin.org wrote:
Le 02/12/2019 à 12:12, Per Jessen a écrit :
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Perhaps, but at the risk of losing the data.
data may be loosed on the two situations :-(
but is there not an usb plug allowing to use real ssd? (msta, for example)?
Actually, not on these boards -
https://www.friendlyarm.com/index.php?route=product/product&product_id=151
They _do_ have USB functionality, but it would make the whole setup bigger and bulkier.
If size is everything I suppose there's less choice, but a pi zero W seems a lot cheaper. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On Mon, 02 Dec 2019 12:56:56 +0100 Per Jessen <per@computer.org> wrote:
Actually, not on these boards -
https://www.friendlyarm.com/index.php?route=product/product&product_id=151
They _do_ have USB functionality, but it would make the whole setup bigger and bulkier.
If size is everything I suppose there's less choice, but a pi zero W seems a lot cheaper.
Size isn't everything, but it is an important factor. I didn't know about the pi zero w, looks neat. I don't think the single cpu is much of an issue, but I wonder about the lack of (possibility for) an external wifi aerial. I do have a Raspberry running too, but wlan reception is pretty good where it is sat. The nanos require an external aerial. Pricewise, the pi zero w is 30 with a 24pin header, I might have to take a closer look. -- Per Jessen, Zürich (2.8°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 02 Dec 2019 15:58:30 +0100 Per Jessen <per@computer.org> wrote:
Dave Howorth wrote:
On Mon, 02 Dec 2019 12:56:56 +0100 Per Jessen <per@computer.org> wrote:
Actually, not on these boards -
https://www.friendlyarm.com/index.php?route=product/product&product_id=151
They _do_ have USB functionality, but it would make the whole setup bigger and bulkier.
If size is everything I suppose there's less choice, but a pi zero W seems a lot cheaper.
Size isn't everything, but it is an important factor. I didn't know about the pi zero w, looks neat. I don't think the single cpu is much of an issue, but I wonder about the lack of (possibility for) an external wifi aerial. I do have a Raspberry running too, but wlan reception is pretty good where it is sat. The nanos require an external aerial.
https://hackaday.com/2017/03/07/adding-an-external-antenna-to-the-raspberry-...
Pricewise, the pi zero w is 30 with a 24pin header, I might have to take a closer look.
Eh, 30 what? It's £13 or $14 with header, which is 40-pin BTW. Another possibility is to use an Arduino-based board or similar. There are various boards like https://www.banggood.com/Wireless-NodeMcu-Lua-CH340G-V3-Based-ESP8266-WIFI-Internet-of-Things-IOT-Development-Module-For-Arduino-p-1420166.html?rmmds=buy&cur_warehouse=CN Then connect sensors to it and transmit the data to a bigger system somewhere more convenient and store the data there. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On Mon, 02 Dec 2019 15:58:30 +0100 Per Jessen <per@computer.org> wrote:
Dave Howorth wrote:
On Mon, 02 Dec 2019 12:56:56 +0100 Per Jessen <per@computer.org> wrote:
Actually, not on these boards -
https://www.friendlyarm.com/index.php?route=product/product&product_id=151
They _do_ have USB functionality, but it would make the whole setup bigger and bulkier.
If size is everything I suppose there's less choice, but a pi zero W seems a lot cheaper.
Size isn't everything, but it is an important factor. I didn't know about the pi zero w, looks neat. I don't think the single cpu is much of an issue, but I wonder about the lack of (possibility for) an external wifi aerial. I do have a Raspberry running too, but wlan reception is pretty good where it is sat. The nanos require an external aerial.
https://hackaday.com/2017/03/07/adding-an-external-antenna-to-the-raspberry-...
Nice - makes you wonder why they didn't just add that socket.
Pricewise, the pi zero w is 30 with a 24pin header, I might have to take a closer look.
Eh, 30 what? It's £13 or $14 with header, which is 40-pin BTW.
Here it is SFr30 with the 40pin header. Slightly less without :-) The nanopi is slightly more, but includes two headers and an aerial.
Another possibility is to use an Arduino-based board or similar. There are various boards like
Yes - I've seen the solution with ESP8266. A couple of things that keep me away: a) learning curve, lack of experience. b) they don't run Linux The nanopis are really easy to use, they run openSUSE, and I just treat them like any other system (ignoring the SD card issue). I did consider something Arduino-like in the beginning - I wanted to read my electricity meters - it just seemed too much hobby, not enough utility. https://www.jessen.ch/electricity/
Then connect sensors to it and transmit the data to a bigger system somewhere more convenient and store the data there.
Yes, we do that too although up to minute data is available directly from the Nanopi. -- Per Jessen, Zürich (1.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 12.12, Per Jessen wrote:
Carlos E. R. wrote:
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Perhaps, but at the risk of losing the data.
Linux never crashes :-p I read about I think it was Teslas being out of service precisely because the computer could not write any more. Failed flash "disk". Excessive logging being blamed. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E.R. wrote:
On 02/12/2019 12.12, Per Jessen wrote:
Carlos E. R. wrote:
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Perhaps, but at the risk of losing the data.
Linux never crashes :-p
Of course not :-) , but the power might disappear. -- Per Jessen, Zürich (4.1°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 12.54, Per Jessen wrote:
Carlos E.R. wrote:
On 02/12/2019 12.12, Per Jessen wrote:
Carlos E. R. wrote:
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Perhaps, but at the risk of losing the data.
Linux never crashes :-p
Of course not :-) , but the power might disappear.
Bring an UPS line to it from somewhere else? These tiny computers can probably run directly from a battery, that could be charged on standby. Or... have a huge capacitor, and on power failure issue an emergency write everything order, then halt. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeT82AAKCRC1MxgcbY1H 1aVHAJ9FRKZOvo9h5OBXk6FyTjxZM/B53wCfTz/DEFWCofjG+MyGVh0fu3Efrok= =NZ/b -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 12.54, Per Jessen wrote:
Carlos E.R. wrote:
On 02/12/2019 12.12, Per Jessen wrote:
Carlos E. R. wrote:
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Perhaps, but at the risk of losing the data.
Linux never crashes :-p
Of course not :-) , but the power might disappear.
Bring an UPS line to it from somewhere else?
It totally ruins the idea of a neat and tiny device being hidden away in a corner. The ARM board is only 50x50, the power supply is already bigger than the board :-)
These tiny computers can probably run directly from a battery, that could be charged on standby.
The project is growing :-)
Or... have a huge capacitor, and on power failure issue an emergency write everything order, then halt.
Yes, I have actually wondered about that, using a supercap. I think I'll stick to writing to the SD card. -- Per Jessen, Zürich (3.1°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 13.36, Per Jessen wrote:
Carlos E. R. wrote:
On 02/12/2019 12.54, Per Jessen wrote:
Carlos E.R. wrote:
On 02/12/2019 12.12, Per Jessen wrote:
Carlos E. R. wrote:
On 02/12/2019 09.17, Per Jessen wrote: > My systems need to write something every minute. > They're generally monitoring various sensors.
Can't the writing be delayed?
Perhaps, but at the risk of losing the data.
Linux never crashes :-p
Of course not :-) , but the power might disappear.
Bring an UPS line to it from somewhere else?
It totally ruins the idea of a neat and tiny device being hidden away in a corner. The ARM board is only 50x50, the power supply is already bigger than the board :-)
I know, but you have to connect it to the mains. Bring a mains line from the house that comes from an UPS :-) (Years ago I contemplated running a 12 volt line on the house...)
These tiny computers can probably run directly from a battery, that could be charged on standby.
The project is growing :-)
:-D
Or... have a huge capacitor, and on power failure issue an emergency write everything order, then halt.
Yes, I have actually wondered about that, using a supercap. I think I'll stick to writing to the SD card.
Tsk tsk... I was looking forward to the photos :-D - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeUNZAAKCRC1MxgcbY1H 1RDuAJwOba5t1zUynPUpA6pd7kABt+PfIgCgjnrjpfMkN2jbj1hpZLSZatf7MMs= =HsZN -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 13.36, Per Jessen wrote:
Carlos E. R. wrote:
On 02/12/2019 12.54, Per Jessen wrote:
Carlos E.R. wrote:
On 02/12/2019 12.12, Per Jessen wrote:
Carlos E. R. wrote:
> On 02/12/2019 09.17, Per Jessen wrote: >> My systems need to write something every minute. >> They're generally monitoring various sensors. > > Can't the writing be delayed?
Perhaps, but at the risk of losing the data.
Linux never crashes :-p
Of course not :-) , but the power might disappear.
Bring an UPS line to it from somewhere else?
It totally ruins the idea of a neat and tiny device being hidden away in a corner. The ARM board is only 50x50, the power supply is already bigger than the board :-)
I know, but you have to connect it to the mains. Bring a mains line from the house that comes from an UPS :-)
Mains wiring is way too much effort - for each and every system. I have three sofar, one or two in planning. Nonono.
Or... have a huge capacitor, and on power failure issue an emergency write everything order, then halt.
Yes, I have actually wondered about that, using a supercap. I think I'll stick to writing to the SD card.
Tsk tsk... I was looking forward to the photos :-D
It's an entirely feasible solution, you can find them on-line, https://www.bicker.de/index.php/eng/Company/News/DC-UPS-with-SuperCaps-for-u... -- Per Jessen, Zürich (3.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 02 Dec 2019 15:34:16 +0100 Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 13.36, Per Jessen wrote:
Carlos E. R. wrote:
On 02/12/2019 12.54, Per Jessen wrote:
Carlos E.R. wrote:
On 02/12/2019 12.12, Per Jessen wrote: > Carlos E. R. wrote:
>> On 02/12/2019 09.17, Per Jessen wrote: >>> My systems need to write something every minute. >>> They're generally monitoring various sensors. >> >> Can't the writing be delayed? > > Perhaps, but at the risk of losing the data.
Linux never crashes :-p
Of course not :-) , but the power might disappear.
Bring an UPS line to it from somewhere else?
It totally ruins the idea of a neat and tiny device being hidden away in a corner. The ARM board is only 50x50, the power supply is already bigger than the board :-)
I know, but you have to connect it to the mains. Bring a mains line from the house that comes from an UPS :-)
Mains wiring is way too much effort - for each and every system. I have three sofar, one or two in planning. Nonono.
Or... have a huge capacitor, and on power failure issue an emergency write everything order, then halt.
Yes, I have actually wondered about that, using a supercap. I think I'll stick to writing to the SD card.
Tsk tsk... I was looking forward to the photos :-D
It's an entirely feasible solution, you can find them on-line, https://www.bicker.de/index.php/eng/Company/News/DC-UPS-with-SuperCaps-for-u...
Ouch! €265 I'm surprised I haven't found 3.3V or 5V USP supplies intended to keep IoT devices working through power cuts. In particular, security cameras either seem to be just mains or just battery. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On Mon, 02 Dec 2019 15:34:16 +0100 Per Jessen <per@computer.org> wrote:
It's an entirely feasible solution, you can find them on-line,
https://www.bicker.de/index.php/eng/Company/News/DC-UPS-with-SuperCaps-for-u...
Ouch! €265
Yeah. :-(
I'm surprised I haven't found 3.3V or 5V USP supplies intended to keep IoT devices working through power cuts. In particular, security cameras either seem to be just mains or just battery.
PoE ? -- Per Jessen, Zürich (2.4°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2019-12-02 11:58 AM, Per Jessen wrote:
I'm surprised I haven't found 3.3V or 5V USP supplies intended to keep IoT devices working through power cuts. In particular, security cameras either seem to be just mains or just battery. PoE ?
I have worked with PoE cameras and never seen one that could be USB powered. Also, a camera would be pretty much useless if the switch and recorder were down due to power failure. So, if you're worried about that, just provide a UPS for that equipment and the cameras will remain up, so long as there is PoE power. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2 Dec 2019 12:05:41 -0500 James Knott <james.knott@jknott.net> wrote:
On 2019-12-02 11:58 AM, Per Jessen wrote:
I'm surprised I haven't found 3.3V or 5V USP supplies intended to keep IoT devices working through power cuts. In particular, security cameras either seem to be just mains or just battery. PoE ?
I have worked with PoE cameras and never seen one that could be USB powered. Also, a camera would be pretty much useless if the switch and recorder were down due to power failure. So, if you're worried about that, just provide a UPS for that equipment and the cameras will remain up, so long as there is PoE power.
Sorry my 'USP' was a typo for 'UPS' rather than 'USB' :( I'm not thinking of cameras wired to a switch and recorder. Rather a local SD card and cloud storage to guarantee against the equipment being stolen at the same time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 03/12/2019 à 12:55, Dave Howorth a écrit :
local SD card and cloud storage to guarantee against the equipment being stolen at the same time.
solution can be a powerbank changed periodically jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 3 Dec 2019 13:14:53 +0100 "jdd@dodin.org" <jdd@dodin.org> wrote:
Le 03/12/2019 à 12:55, Dave Howorth a écrit :
local SD card and cloud storage to guarantee against the equipment being stolen at the same time.
solution can be a powerbank changed periodically
'changed periodically' or even 'charged periodically' implies maintenance. The goal is the thing should just sit there and do its job.
jdd
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 03/12/2019 à 14:16, Dave Howorth a écrit :
On Tue, 3 Dec 2019 13:14:53 +0100 "jdd@dodin.org" <jdd@dodin.org> wrote:
Le 03/12/2019 à 12:55, Dave Howorth a écrit :
local SD card and cloud storage to guarantee against the equipment being stolen at the same time.
solution can be a powerbank changed periodically
'changed periodically' or even 'charged periodically' implies maintenance. The goal is the thing should just sit there and do its job.
jdd
well... you have to recover the data :-) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 3 Dec 2019 15:00:37 +0100 "jdd@dodin.org" <jdd@dodin.org> wrote:
Le 03/12/2019 à 14:16, Dave Howorth a écrit :
On Tue, 3 Dec 2019 13:14:53 +0100 "jdd@dodin.org" <jdd@dodin.org> wrote:
Le 03/12/2019 à 12:55, Dave Howorth a écrit :
local SD card and cloud storage to guarantee against the equipment being stolen at the same time.
solution can be a powerbank changed periodically
'changed periodically' or even 'charged periodically' implies maintenance. The goal is the thing should just sit there and do its job.
jdd
well... you have to recover the data :-)
Not in the normal course of events, no. Only if there is a break-in or similar event that requires video evidence.
jdd
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2019-12-03 10:14 AM, Dave Howorth wrote:
well... you have to recover the data:-) Not in the normal course of events, no. Only if there is a break-in or similar event that requires video evidence.
Assuming they don't steal the camera! ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 3 Dec 2019 10:26:47 -0500 James Knott <james.knott@jknott.net> wrote:
On 2019-12-03 10:14 AM, Dave Howorth wrote:
well... you have to recover the data:-) Not in the normal course of events, no. Only if there is a break-in or similar event that requires video evidence.
Assuming they don't steal the camera! ;-)
That's the point of the cloud storage. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/12/2019 18.05, James Knott wrote:
On 2019-12-02 11:58 AM, Per Jessen wrote:
I'm surprised I haven't found 3.3V or 5V USP supplies intended to keep IoT devices working through power cuts. In particular, security cameras either seem to be just mains or just battery. PoE ?
I have worked with PoE cameras and never seen one that could be USB powered. Also, a camera would be pretty much useless if the switch and recorder were down due to power failure. So, if you're worried about that, just provide a UPS for that equipment and the cameras will remain up, so long as there is PoE power.
Why have a an UPS at mains voltage instead of a 12 volt one? Low voltage solutions can keep running for a day or more on battery. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeZQXwAKCRC1MxgcbY1H 1WUWAJ9V9XEAYpeXWb8n2OZcs4Vw4+4fjQCfXhBAhHQ73XHtiUF+/3OVHo+xCho= =vl1k -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 18.05, James Knott wrote:
On 2019-12-02 11:58 AM, Per Jessen wrote:
I'm surprised I haven't found 3.3V or 5V USP supplies intended to keep IoT devices working through power cuts. In particular, security cameras either seem to be just mains or just battery. PoE ?
I have worked with PoE cameras and never seen one that could be USB powered. Also, a camera would be pretty much useless if the switch and recorder were down due to power failure. So, if you're worried about that, just provide a UPS for that equipment and the cameras will remain up, so long as there is PoE power.
Why have a an UPS at mains voltage instead of a 12 volt one? Low voltage solutions can keep running for a day or more on battery.
Because 1 UPS for 1 PoE switch with 48 PoE-powered cameras is much easier than 48 individual UPSes. -- Per Jessen, Zürich (3.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/12/2019 13.36, Per Jessen wrote:
Carlos E. R. wrote:>> On 02/12/2019 18.05, James Knott wrote:
On 2019-12-02 11:58 AM, Per Jessen wrote:
I'm surprised I haven't found 3.3V or 5V USP supplies intended to keep IoT devices working through power cuts. In particular, security cameras either seem to be just mains or just battery. PoE ?
I have worked with PoE cameras and never seen one that could be USB powered. Also, a camera would be pretty much useless if the switch and recorder were down due to power failure. So, if you're worried about that, just provide a UPS for that equipment and the cameras will remain up, so long as there is PoE power.
Why have a an UPS at mains voltage instead of a 12 volt one? Low voltage solutions can keep running for a day or more on battery.
Because 1 UPS for 1 PoE switch with 48 PoE-powered cameras is much easier than 48 individual UPSes.
Well, yes. I have a commercial alarm system that that has all the (still) cameras powered by AA cells. No wires. Only the control box has mains power with internal rechargeable AA size batteries. No UPS at mains. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXeZZLAAKCRC1MxgcbY1H 1TaaAJ9jC6I+IoYNk6zUErHJM84+W+587ACfVu9D2hYqKitx5fn3bId1iGBDtTk= =Dm4j -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 17.14, Dave Howorth wrote:
On Mon, 02 Dec 2019 15:34:16 +0100 Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
It's an entirely feasible solution, you can find them on-line,
https://www.bicker.de/index.php/eng/Company/News/DC-UPS-with-SuperCaps-for-u...
Ouch! €265
I'm surprised I haven't found 3.3V or 5V USP supplies intended to keep IoT devices working through power cuts. In particular, security cameras either seem to be just mains or just battery.
Yes, DC power supplies combined with 12 or 6V batteries. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 02/12/2019 15.34, Per Jessen wrote:
Carlos E. R. wrote:
On 02/12/2019 13.36, Per Jessen wrote:
I know, but you have to connect it to the mains. Bring a mains line from the house that comes from an UPS :-)
Mains wiring is way too much effort - for each and every system. I have three sofar, one or two in planning. Nonono.
It is what I would consider first... Less technology.
Or... have a huge capacitor, and on power failure issue an emergency write everything order, then halt.
Yes, I have actually wondered about that, using a supercap. I think I'll stick to writing to the SD card.
Tsk tsk... I was looking forward to the photos :-D
It's an entirely feasible solution, you can find them on-line,
https://www.bicker.de/index.php/eng/Company/News/DC-UPS-with-SuperCaps-for-u... Wow.
:-o -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
On 02/12/2019 15.34, Per Jessen wrote:
Carlos E. R. wrote:
On 02/12/2019 13.36, Per Jessen wrote:
I know, but you have to connect it to the mains. Bring a mains line from the house that comes from an UPS :-)
Mains wiring is way too much effort - for each and every system. I have three sofar, one or two in planning. Nonono.
It is what I would consider first... Less technology.
But _much_ more effort. Drilling holes through walls, putting in conduits, putting in separate sockets etc etc. Nonono. Much cheaper and faster to get SD cards that work. -- Per Jessen, Zürich (2.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/12/2019 à 13:36, Per Jessen a écrit :
Yes, I have actually wondered about that, using a supercap. I think I'll stick to writing to the SD card.
using bigger card to reduce the wearing seems a good idea. May be use a 4kb data form factor also to use full cell writer? (just wild guesses) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 2 Dec 2019 11:59:41 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Depends what you're doing. IMHO, systemd's way of writing to the journal is smart enough to make the journal persistent, but there's lots of other logging, such as apache access logs, that can safely be done to RAM. There's a project called log2ram that's quite useful - there are various flavours of it. Another way to minimise writes is to use bigger SD cards. I've standardised on 32GB Sandisk cards at the moment since they seem to be a reasonable price. Lots of spare space means lots of wear-levelling. My data logging system OpenEnergyMonitor (OEM) uses redis to buffer data and reduce the frequency of writes to SD card. That seems to work quite well. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 12.51, Dave Howorth wrote:
On Mon, 2 Dec 2019 11:59:41 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Depends what you're doing. IMHO, systemd's way of writing to the journal is smart enough to make the journal persistent, but there's lots of other logging, such as apache access logs, that can safely be done to RAM. There's a project called log2ram that's quite useful - there are various flavours of it.
Another way to minimise writes is to use bigger SD cards. I've standardised on 32GB Sandisk cards at the moment since they seem to be a reasonable price. Lots of spare space means lots of wear-levelling.
My data logging system OpenEnergyMonitor (OEM) uses redis to buffer data and reduce the frequency of writes to SD card. That seems to work quite well.
There is some trick I read years ago, but I do not remember the details. It is done by the laptop-mode-tools package; it configures the kernel to delay all writes for some time, then write them all in a burst. The idea, when I read that, was to power down the rotating hard disk for minutes, even an hour, to conserve battery power; they were not thinking of flash media at the time. It seems curious we have not heard of a kernel tuning for flash write media :-? Mount option? Google "linux kernel tuning for flash media write" finds some, not recent. For the Pi: <https://www.raspberrypi.org/forums/viewtopic.php?t=850> Wild idea: have /var/log in tmpfs completely, then rsync to flash on another dir periodically :-? But this is absurd, the syslog daemon should have a tuning to do the same thing. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Mon, 2 Dec 2019 13:15:51 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 02/12/2019 12.51, Dave Howorth wrote:
On Mon, 2 Dec 2019 11:59:41 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/12/2019 09.17, Per Jessen wrote:
My systems need to write something every minute. They're generally monitoring various sensors.
Can't the writing be delayed?
Depends what you're doing. IMHO, systemd's way of writing to the journal is smart enough to make the journal persistent, but there's lots of other logging, such as apache access logs, that can safely be done to RAM. There's a project called log2ram that's quite useful - there are various flavours of it.
Another way to minimise writes is to use bigger SD cards. I've standardised on 32GB Sandisk cards at the moment since they seem to be a reasonable price. Lots of spare space means lots of wear-levelling.
My data logging system OpenEnergyMonitor (OEM) uses redis to buffer data and reduce the frequency of writes to SD card. That seems to work quite well.
There is some trick I read years ago, but I do not remember the details. It is done by the laptop-mode-tools package; it configures the kernel to delay all writes for some time, then write them all in a burst. The idea, when I read that, was to power down the rotating hard disk for minutes, even an hour, to conserve battery power; they were not thinking of flash media at the time.
It seems curious we have not heard of a kernel tuning for flash write media :-?
Mount option?
Google "linux kernel tuning for flash media write" finds some, not recent.
For the Pi: <https://www.raspberrypi.org/forums/viewtopic.php?t=850>
Wild idea: have /var/log in tmpfs completely, then rsync to flash on another dir periodically :-? But this is absurd, the syslog daemon should have a tuning to do the same thing.
Yes, that's what log2ram does. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/12/2019 13.29, Dave Howorth wrote:
On Mon, 2 Dec 2019 13:15:51 +0100 "Carlos E. R." <> wrote:
Wild idea: have /var/log in tmpfs completely, then rsync to flash on another dir periodically :-? But this is absurd, the syslog daemon should have a tuning to do the same thing.
Yes, that's what log2ram does.
Not found: <https://software.opensuse.org/search?p=1&baseproject=openSUSE:Leap:15.1&q=log2ram> -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Dave Howorth wrote:
Another way to minimise writes is to use bigger SD cards. I've standardised on 32GB Sandisk cards at the moment since they seem to be a reasonable price. Lots of spare space means lots of wear-levelling.
That's a good point - I'm using 16Gb sofar, with about 20% in use. Should also give plenty of space for wear-levelling? -- Per Jessen, Zürich (3.5°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 02/12/2019 à 13:40, Per Jessen a écrit :
Dave Howorth wrote:
Another way to minimise writes is to use bigger SD cards. I've standardised on 32GB Sandisk cards at the moment since they seem to be a reasonable price. Lots of spare space means lots of wear-levelling.
That's a good point - I'm using 16Gb sofar, with about 20% in use. Should also give plenty of space for wear-levelling?
but did you really have sd card failures? How often? If the card is not full, this should not come from card wear, may be other factor jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd@dodin.org wrote:
Le 02/12/2019 à 13:40, Per Jessen a écrit :
Dave Howorth wrote:
Another way to minimise writes is to use bigger SD cards. I've standardised on 32GB Sandisk cards at the moment since they seem to be a reasonable price. Lots of spare space means lots of wear-levelling.
That's a good point - I'm using 16Gb sofar, with about 20% in use. Should also give plenty of space for wear-levelling?
but did you really have sd card failures? How often? If the card is not full, this should not come from card wear, may be other factor
This thread was started because my ARM board started misbehaving, almost certainly due to a failure of the card. -- Per Jessen, Zürich (3.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E.R. -
Dave Howorth -
David C. Rankin -
Freek de Kruijf -
James Knott -
jdd＠dodin.org -
Per Jessen