arox

Good question ! The name depends not only on boot but also change if you plug / unplug devices ... I have the same problem when I try to work with 2 micro-controllers at the same time. This can certainly be done with an "udev rule". There is some response here : https://www.domoticz.com/wiki/PersistentUSBDevices In section : filtering by "devpath" : SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", ATTRS{devpath}=="1.2", SYMLINK+="ttyUSB-arduino1" SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", ATTRS{devpath}=="1.5", SYMLINK+="ttyUSB-arduino2" The solution will depend on usage and usb hub configuration. And writing and debugging udev rules is not easy.

What happens if you just create it ? (sudo touch /var/log/wtmp)

"it should have plenty of power to run the board and hdd" This is a recurrent question on this forum. But the voltage available to the board always depends on the source voltage and also on the cable(s), contacts of connectors and internal circuits resistance, protection diodes and fuses, (and of the PSU mileage which is difficult to evaluate) ... When the board needs too much current, the total resistance can make the input voltage drop below the minimum needed for a time too short to see on a multimeter but that may cause any sort of hardware failure. If you never changed anything and never moves cables, forget that : but if you replugged the power connector of the BPI M1, be sure to use the one next to the SCSI connector and check that half the strands of your cable are not cut. (As it happened to me a lot of time). "PC power source" : A PC Power Supply has plenty of power but not a USB port which has current limitation and protection circuitry. I do not think your card could boot if the SBC and the disk were powered thru a single USB port. As tparys said, you should also check that fsck is requested at boot (kernel parameter "fsck.repair=yes" in "modern" linux - but yours - as mine - is perhaps a little less modern), because you always will face a power outage some time that the journalization of the fs cannot handle.

Thru which connector ?

BTW A possible cause of repeated fs corruption is the power supply. (Or power cables).

Hum ! A bit worrying that your second fsck complained. I do not understand why you couldn't unmount the fs or /dev/sda1 was not present and appeared the second time ? Did you run fsck with the fs mounted ro ? The fs is probably repaired now but you should check your logs and have an up-to-date backup during some times. There are commands to check disk errors recorded by firmware (but not controller or cables errors). Anyway I experienced your problems a lot of times and still use the board and cards without problem. Yes, BPI M1 with armbian was and always is a good solution. That is why I still use it although it is completely out-of-date. But I got the same sort of fs corruption case (triggered by usb bugs ?) with raspbian on RPI4.

fsck.repair=yes is normally set in distros. Nevertheless, it seems to me that the corruption of the fs is sometimes unnoticed with ext4 ? So a force option is needed, but a "force" is a bad idea in an automatic procedure because it may remove half the files. A manual procedure is necessary to allow the administrator to backup what can be save. And I also noticed that the boot procedure may perform a full boot with a corrupted fs. Then the problem is likely to become worse. Also if the root fs is write-locked, there is no point starting a full service witch will hinder system maintenance : the boot sequence should escape to a maintenance shell if the remount rw fail. (I say "seems to me" or "noticed", because when it happens to me on a system with a SSD, it is my desktop or my file server that is unavailable and I am more in a hurry to solve that investigate the problem, and with a headless server or without main desktop working it is also not easy.)

If you are not familiar with unix/linux : Do : - fsck /dev/sda1 If he seems to think nothing needs to be done, don't believe it, do : - fsck -f /dev/sda1 When he ask to confirm for inodes clear, say "y". You don't have much choice anyway. If he start asking for removing blocs, you may become worried, but you don't have much choice than agree. If the number of removal becomes important, you may become very upset. If he finished and leave a number of files without name in lost+found you have a problem. But generally you just have a pair of inodes and some pointers/counters that need to be fixed. In theory you should do a second fsck to be sure the fs is repaired. If this one needs action, your disk or controler has a problem. (The card or the disk ?) Before swapping sdcards and trying to boot on disk, do a mount - mount dev/sda1 /mnt - cat /mnt/etc/os-release (to reassure yourself) - umount /mnt (or you risk to damage your fs another time)

Of course, it is the simplest and so the best solution. Flashing a new SdCard take some times but at least, you should be able to repair your disk in 2 minits next time. For the distro, anything that can boot and is up-to-date with ext4 should do the trick. (This just mean not a five years old distro).

I have put a ferrite ring around the hdmi cable (one of those you can find on usb cables). So far I cannot trigger black screen any more.

When that sort of things happen to me, I need to plug the disk on another computer and do an fsck with force (-f) option. Not fair an be aware that an fsck may have to remove half your files if the cause is a disk failure ... I don't know how to force an fsck elseway if you cannot switch to a shell during boot sequence ? You could try : mount -o remount, rw / But it surely will fail. Since you use a BPI M1, I guess the boot loader is on the sdcard. And if you do always have a valid root fs on sd card, you could modify the loader to mount the root fs from the sdcard.

"i am not so familiar with MQTT - protocolls." MQTT is the most simplistic protocol that can exist : you say you want to send (publish) or receive (subscribe), about what (topic) and what (message). The only problem you can encounter in python is to provide an event loop for receiving messages. Messages are handled by a function defined as a handler. You just need to call "client.loop_forever()" or "client.loop_start()" at interval in another loop if you want to do other stuff in a subscribing client. The protocols that handle sensors are much more problematic : they need precise timing to send receive/receive data on gpio, which is not so easy in "not real time" OS and then with SBC. So microcontrollers are great for sensor driver and MQTT publisher. SBC are great for broker because you will want a log to see connection / disconnection events and you need storage if you want persistent messages (*). But the most basic SBC do the trick : my brocker run on a tiny H3 nanopi which handles all communication functions (firewall, http proxy and filter, mail relay, DNS, NTP server ...) Mosquitto is perhaps the more easy to install and reliable server I have ever used. The fun resides in MQTT subscriber : you can analyse data, command electrical circuits with 2N7000 Mosfet and arduino relay boards, drive LED strips with PWM, stepper motors or anything you want for a couple of bucks, a soldering iron and a lot of time ... Of course, SBC are more suitable for data analysis and microcontrollers for hardware interfacing. All in all, I spend 5 more time for hardware than for software and 5 more time for software than for design. And no time for "protocols" because they are implemented in drivers or libraries. So don't dwell on it but go for it ! (*) there are just 2 options in MQTT 3.11 : persistent messages keep messages and deliver them to new clients that connect and subscribe after publication, qos indicates whether you can afford to drop a message in case of delivery failure, accept duplication or want a unique delivery. And one more option to adjust the "keep alive" / disconnect time (an "integrated ping" between client and broker that I never bothered to change).

I don't understand your point. The problem when designing a distributed system is to ensure reliability when systems crash, reboot or the network disconnects. For systems like SBC or microcontrollers, you have to detect crash and assure recovery, maintenance and debugging on system without screen and keyboard - and avoid corrupted storage problems. For network, you must provide reconnect procedures (witch also suppose that the disconnection has been detected), frequents with over-the-air networks, or in case of peer restart. I use (and you were aiming to do so ?) MQTT with a local broker for that reason. I first so that others used it on this forum and initially thought I didn't need it. But I changed my mind : MQTT allows to deploy a multiple "publisher" / "subscriber" loosely connected network with a trivial message protocol and some option to control reliability of message delivery. Even with that, you will have to carefully design your agents to handle crash, disconnections, sensor errors or network failures. At least, I have found that the Eclipse MQTT broker "mosquitto" is reliable. Basically you can handle MQTT disconnects at application level with a 15 lines of python code MQTT client (if you don't bother to have some samples lost). Sensors error handling is more difficult (often needs reboot). Wifi problems depends on drivers and hardware (so carefully choose the SBC and wifi controller). To ensure reliability of unattended systems connected by wifi is even more difficult in particular with SD cards, rw root fs and OS targeted at graphical UI use case ... I am not sure smtp is a good idea for IoT. It is reliable but slow. MQTT is a messaging protocol with open subscription (no recipient list) and 1 second latency if you implement your broker. Much more like a "software bus". Ideal in a local network behind a firewall were you don't even need to bother with credentials. If you like complex and heavy solutions or like to be worked up, try Nodered in a Docker container. Well, that is just my point of view ... but I have lost track of the number of agents at my home for a long time. Fortunately, bugs (hardware, software or design) remind me of some regularly.

Tell us if you get some improvement. But I think EMI can be propagated by every ground loop in your hardware ...

Well, for once he has a chance to implicate some other armbian SBC as a client ... And in response to the "question", I have been doing this for 4 years with mosquitto (compiled without websocket) and MQTT clients in python, tcl, C, golang ... on raspbian, armbian, debian, RTOS ... So I think it **may** work, as it is designed to do so.

My hdmi-vga adapter also do that, but for me it is clearly caused by EMI : I can trigger it with a piezo-electric lighter.

Thanks to tparys : I had forgotten the /sys path. I **never** check the cpu temp : with the aluminium cases availables for RPI4 which press the cpu, the RPI4 provide an excellent passive cooling solution. On the contrary, I wish raspbian would not corrupt the root file system (on USB3 bus) when there is a USB error (on USB2 bus) ?!?

cat /sys/class/hwmon/hwmon0/temp1_input give exactly the same result than 'vcgencmd measure_temp' Thanks to tparys : I h

" as I am Debian guy anyway ..." I am not so happy as you with Debian. But I ditched Crux a long time ago anyway for the same reason. I notice a lot of problem in the forum with network. I am struggling with the same sort on problems on Raspbian because they are Debian related, but not even Debian but upstream related. Anyway, I won't precise my mind because it generally hurt some feelings. What imports is : - is the system usable, - can it be tweek with workarounds because the same problems will probably be present in other distributions. (Thanks anyway to report your experience).

I think Armbian is more a Release Management System than an Operating System. It targets an upper level of abstraction and so needs to comply with other constraints. Porting Debian to RPI is more easy than porting Debian thru an automated process on different platforms. And supporting RPI is to much specific for the interest. But you are right anyway : Raspbian do the job, RPI is not evil and has is strengths and weaknesses. It can then be a reference of what should be reach in matter of stability and avoided in other domains. As long as Armbian works on the same upward distribution (Debian), I don't think that supporting RPI is fundamentally important. Working at an upper level of software management allow to provide a solution for basic users and justify restrictions for more advanced users. Armbian may explore some specific software implementation. If that implementations prove their usefulness, it is much easy to tweek Raspbian for adding them than tweek Armbian to support RPI. (So we should better ask Raspberry Pi foundation to adopt Armbian choices than the opposite). Support exactly the same software on very different platforms (in term of architecture, usage and power) has always be a bad idea.

Have you ever thought of a web server ? (Like cups, openwrt or others ...) You need of course some basic configuration utility in case the network connection can't be automatically established.

The big problem for me is their business model. Collect information ! Which implies that they push to centralize all data, they multiply ten times the network traffic necessary pour anything, they make you dependant of their service, their availability and the response time, they force you to be always connected, to open a mail account, to accept unreasonable permissions and rights, they lock their apps on devices, and of course they do not want you to put your nose in the system. I bought an Android tablet years ago. The virtual keyboard was a tragedy so I searched a better one in the store. All apps required privileges that implied they would know everything you typed on the keyboard. It is just an example but it show how they put little concern on the real security - because real security would prevent them to develop their business model. (I received yesterday a notice from RPI french official reseller that they had been hacked and my name, address, mail address and password was available on the Darknet). So either I get an Iphone, either I get something like an ubuntu phone if I can really tailor the system and reliably invest time in that task.

My concern is primarily the bootloader and the associated flash tools. I cant do anything with complex, work-in-progress basic tools as my goal is to develop personal applications and maintain them for a long time after the seller has gone bankrupt. Anything bugged and/or based on specific browser or complex virtualizer cannot do it. I cannot spend more time and money in installing and maintaining the development platform than in device and (personal) app development. I have a lot of "CHIP" devices in my drawers and always some instances in "home production environment" (of course the more critical ones). I cannot maintain them because the boot loader was browser based and bugged. (And the seller disappeared before I could provision spares). So there are migrating on esp32 microcontrollers because I can maintain them with a basic SBC with frozen OS and tools and a reasonable provision of spares. Those migrations have a high cost because it implies electronic, wiring, housing, network and organisation changes, testing, debugging, logging ... Purchase price and easy and quick setup is meaningless if you spend months to debug and cannot use it 2 years after.

I have a "firefox OS" smartphone. I developed some app for my personal usage, such as an openstreetmap app that use local offline maps ... My goal was to have a pocket computer with simple but useful and personal apps. As you can imagine, I am no longer able to develop or even maintain it since several years ! Because the SDK was part of Mozilla browser. So all in all, I could buy Linux smartphone if and only if I get an SDK for linux (on an inexpensive dedicated board), the source code, and a viable base (Kernel, GUI, phone app, wifi/bt).

When that sort of problem happens to me, it is generally caused by a worn SD Card (which ack writes but do not update) or a dirty root fs that needs fsck.