pfeerick
-
Posts
148 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by pfeerick
-
-
@Igor I've edited both announcements a bit, see what you think of the changes. And please, please, please change "Before you think to report a problem with your board running Armbian' to something a little less... sharp? I know I would do that tongue in cheek (and do... hence why you sometimes see strikethroughs in my text)
, but that could be a little less unfriendly... "Before reporting problems with your board running Armbian" or ""Before reporting problems with your board running Armbian, check the following" ... something like that?
-
@prahjister Have you set up Avahi on that image? Just wondering if something like http://octoprint.local would work with your image, making IP addresses not necessary? Otherwise it's probably either setting a fixed address on your router, using (sudo) nmtui to configure the connection (assuming network manager is managing the connection) or some ugly /etc/network/interfaces edits.
-
@Yuan I can't say I'd agree with that voltage... I think it's a little too high. 5.3v is the highest I generally go at the power supply. Keeping in mine the USB spec tolerances of 4.75V-5-25V, so if the 5v rail is also providing the USB voltage (and it often does), you're in danger of pushing a higher voltage than what devices are expecting, unless you get enough of a voltage sag over the leads. Whether that is enough to blow up a USB device when you plug it in, I couldn't say as I haven't tested every device under the sun. However, I would expect it to shorten the live of some devices. What I would recommend is also measuring the voltage at the device, both with no load, and when the CPU is loaded, and making sure the voltage doesn't fall below 5.00v minimum, maybe even 5.10v, depending what it shoots back up to when not loaded.
-
25 minutes ago, tkaiser said:
The other problem -- underpowering -- we can not detect and provide a nice notification and some polite guidance since on the vast majority of boards we can not measure voltage/current. IMO it's way better to create a worst case scenarion already at first boot (starting cpuburn from firstrun task and do a 'pkill cpuburn' at the end of it) so boards that suffer from severe underpowering simply will never boot unless this problem is fixed.
That was what I was proposing... sort of. I fully understand due to different board configurations and architectures that board specific methodologies are too varied and complex, assuming all the information needed is exposed. I was thinking the cpuburn type task, coupled with a token, so that say if the system does that sort of power on b0rkage that after a couple of cycles it could let up and basically tell you your power system is broken. Because end-less boot loops aren't user friendly either. Part of the the change in thinking that is needed here is acceptance of the fact that a lot of people won't read the documentation, no matter how well it is written, unless they are forced to (or just plain want to). So making the system itself as robust as possible to the most common of issues should be a major goal. Those more technically inclined of us don't need that, we can just look at it and diagnose the problem, or perform a few 'simple' tests. Not the average joe though.
21 minutes ago, tkaiser said:Collecting various user threads here and there that are short and understandable is something completely different than a forum post made by a moderator. Let's call it success stories: people who report weird failures, get Etcher / SD card recommendation, come back immediately with 'That made it!'. If we have at least 10 of them instead of lenghty explanations no one reads or wants to accept it's simply a pinned two liner like this 'Please be aware that crappy SD cards (example, example, example, example, example, example, example, example, example, example) and insufficient power supply (example, example, example, example, example, example, example, example, example, example) are reason N° 1 why things are failing' (example all the time just the link to such a success story).
Then it's not a 'them vs me' issue but turns into a 'me being part of the same community and learning from other's mistakes'.
That is what I intend it to look like. I'm just in the process (when I have the time and desire to go back to the post and do a bit more) of collecting what appear to be the more to the point threads, and then the short piece for the top. As you say... not them vs me.
-
18 hours ago, martinayotte said:
We should probably split that into 2 threads.
Done. I had been avoiding this as I didn't want to edit the original post (in the new split thread) which was the only way I know of to contextualise the thread on this forum system. However, I've done that, and the new thread is here. I think I've pulled all the more board specific posts out, leaving this thread to focus on the proposal.
-
6 minutes ago, tkaiser said:
And zero responses to 'preventing boards to boot when rootfs is read-only and executing cpuburn-a7 or cpuburn-a53 as part of firstrun crashing/freezing underpowered boards' reminds me why I consider this babbling here a waste of time.
Sorry about that, I only just caught up with the thread, so I didn't many to reply to that before now.
Hm... first boot checks? Do some basic 'has the user used a crappy or faulty SD card, or using unreliable power (i.e our old favorite microUSB with a phone charger) at first boot, and basically say... if you continue past here, don't come near the forum or expect support? And have a reminder as part of the MOTD of this flawed configuration? If that essentially what you are proposing, I second that.
But I'm not part of the inner circle, so my vote probably doesn't count for anything!And as far as information regarding SD card issues and power issues, I have started work on two posts which will probably be merged into one and used for an announcement at the top of the board pages as a 'basic troubleshooting' methodology. It'll be a few days before I finish it, and get it how I want it though. So you're not alone in thinking this needs fixing, and I am working on it.
-
Sounds nice in principle, but I'm with Zador... Christmas tree clutter, and just makes things more confusing to newcomers, who are the ones who are the ones most likely to post stuff in the wrong place. Enough moderators who pay attention (duly slapped by Igor and Thomas) make this a relative non-issue. But please keep the suggestions coming!
-
2 minutes ago, Igor said:
Keep it minimalist and keep in mind that wall of text is never / rarely read, especially not by those which we are addressing
I can relate to that... give me a wall of text and I go to sleep... or go looking for a better guide. MORE PICTURES!
I need to clean up the other thread and use links instead of those weird embedded forum link things... that makes a relatively short post look download scary.
-
-
My apologies on that last point... I fully deserved that... I keep thinking that the misleadingly named GPU is actually the GPU, instead of just the 3D accelerator. I'll stop there though, as this is getting away from the OT. I just wanted to bite that bullet publicly!
-
You forgot to mention that fact that the GPU won't be that far off the CPU temperature anyway, since they're on the same die.
It may be interesting though if you do hardware assisted encode/decode stuff, whoever is daft enough to use the pine64 for that :-/
-
Only adding this as I did look at it and 'fixed' the problem, which was indeed simply wrong pattern match, due to how ubuntu's free formats things different of recent times. However, I do agree with tkaiser, it isn't really needed, as linux is supposed to use 'free' memory for caching... unused memory isn't wasted! I just didn't like the broken stats!
in /etc/rpimonitor/template
Modified swap.conf is like this.
Modified memory.conf is like this.
I also added more stuff to my Allwinner_A64.conf file, which may or may not be the right filename, I might have renamed that in the process of cleaning stuff up. I added the GPU temps since the health monitor was doing that. Still need to go back and pull the PMIC temp and battery stuff in, and then update my script. It'll happen sometime soon.
-
9 hours ago, martinayotte said:
I've copied the same xenial mate into eMMC, tweak the /boot/extlinux/extlinux.conf to point to mmcblk1, and now it boot from eMMC.
Woohoo! Nice to know it will that easy... my chinglish android eEMMC install might die a sudden death now and be reborn with linux... after a backup, of course!
I still find the android OS handy for usage as dumb TV box! This is the pinout document for the rock64 - hopefully it's all correct!
The boot sequence on the RK3328 is external eMMC, SPI Nor Flash, SPI Nand Flash(not fitted to rock64), external SDMMC card, USB (FEL/OTG). So unfortunately eMMC before SD
I hate to ruin my uptime of 1 day, 4:16, 2 users, load average: 0.00, 0.00, 0.00, but needs must. I usually use the eMMC jumpter to boot from the SD instead of the eMMC, but I just unplugged the eMMC, removed the jumper, and tried a clean boot of the rock64, and it's up again, so I'm not sure what's going in with yours not booting when you have the eMMC removed and not booting from the microSD. This is with the 2GB model.
As far as the partition layout, mine (running 0.2.0) is:
SpoilerDisk /dev/mmcblk0: 29.8 GiB, 32010928128 bytes, 62521344 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 98C438D0-B528-49FA-834D-91E86BA4E3E7 Device Start End Sectors Size Type /dev/mmcblk0p1 64 8063 8000 3.9M Linux filesystem /dev/mmcblk0p2 8064 8191 128 64K Linux filesystem /dev/mmcblk0p3 8192 16383 8192 4M Linux filesystem /dev/mmcblk0p4 16384 24575 8192 4M Linux filesystem /dev/mmcblk0p5 24576 32767 8192 4M Linux filesystem /dev/mmcblk0p6 32768 262143 229376 112M Linux filesystem /dev/mmcblk0p7 262144 2359295 2097152 1G EFI System -
And you wonder why the user couldn't be faulted for plugging in a 12v 2A PSU into a product that has a 5v 700ma requirements :-P I smell lots of burning boards and refunds in the air! Confusion to be had all around. You'd think they'd know better now... tkaiser is not to be messed with... listen to him or all hell will break loose... :-P And it's not like you're doing it to for fun or are sadistically inclined (much!)... you're just trying to tell them how stupid a mistake they're making before they can fix it and are committed on the production run and the mere mortal users (like me) get to enjoy the lemon and whinge at you lazy developers!
Back to the OT, my insignificant *vote* is hell no... let them suffer :-P I like the idea of the board, but not the companies tactics. Boycott them FWIW until they see sense.
-
BDR is an understatement. You were jumping up and down a bit there now 'Charles', but still, they shouldn't be publicly talking about this sort of stuff if they're not willing to put up the numbers and performance data. And as you said, calling it open source is just a bad joke on the community... open source is not just creating a new repo on GitHub! Sheesh! I'm glad I never bought into the whole Banana board thing now... I stuck with the Raspberry Pi for all it's faults, and then deliberately went to the Orange Pi Zero know its faults thanks to the sunxi and Armbian documentation because of it's size and price. I certainly won't be recommending this or any other Banana board after seeing their level of support and foresight in involving the community so they don't screw up yet another (potentially) good idea/design.
-
-
yours is absolutely neat comparted to mine at the moment... pine64, orange pi zeros, rock64... arduinos, meters, parts boxes, heatsinks, nrf24L01 project boards, led matrixes... all strewn across two desks... plus a laptop or two and a tablet in there somewhere! :-O
-
-
As per this post and the downloads section of the Armbian site, some boards have been moved to WIP (Work In Progress) or EOS (End of Support). The only specific H5s I'm aware of, the Orange Pi Zero 2+ H5 and the Orange Pi PC2 are both WIP boards (although from a second glance at the downloads page, it looks like all but the pinebook are H5 boards), so post this commit from 28 days ago, you'll need to set the EXPERT flag to YES in order to show WIP boards. This was done to reduce the number of support requests when people have self-built WIP board images or downloaded the nightlies and subsequently complained that it didn't work properly, which is exactly the reason why it is a WIP!!!
-
@TonyMac32 We're not that far away from mainline support already... at least the first digit is a 4 instead a 3!!
The rockchip folks have stated that they are committed to open source, and are working towards mainline support, so fingers crossed it happens. Making this board the (if not the, then one of) the best best linux supported SBCs for 2017 and with a reasonable hardware set? 
-
I don't have any issue with any of the points raised in this thread so far. So, my 2 cents (or is it 5 cents?):
- Forum restructure - yes, "I" think is needed, as current three levels are restrictive. So break it out to development and tutorials at the least. Before we head down the tutorials on the forum approach though, we really do need to nail down if we do tutorial stuff on the forum, or on a wiki. If we stick with a forum approach, we could probably replicate the 'technical support' categories, to sort them, and then just standardise a layout... first post is always the updated tutorial, second might be links to other resources, something like that...
-
Moderator presence - we're here only to keep the peace, keep stuff organised, play wack-a-mole with spammers and that's basically it. I'm a bit confused as to the context of tkaisers 'invisible', but my take is basically what he said - clean up any silly formatting - i.e. not using code blocks, moving stuff to where it belongs, and a friendly PM to the poster to let them know how to do it in future. Other than that, we're just regular users, and as long as we don't do what happened in the other forum which we all know about, things will get on just great!
- As far as deleting a 'support request' that hasn't had a reply for say 2 weeks, I dunno... what happens if the OP comes back to it after three weeks? Unless we get a whole bunch of them, and things start getting out of hand... they can stay.
- Some sort of pined post outlining how to start a support request would be good. It will never solve the increasingly worse problem of "I'm an expert - Google told me so!", but it will at least get it through to some posters that details do matter. We are not clairvoyant. So if you don't give us the information, like I jokingly said in a recent post, I will assume that you need to tell the hamster in the hamster well to run faster, as I honestly believe your board is powered by a hamster wheel turbine due to the amount of information you have provided. (Who around doesn't remember the old adage of crap in, crap out??)
-
As far as cooling down, if you're thinking of the current Orange PC thread... we're far from needing that. The OP is being a little dim, which is understandable, since he is frustrated. However, it hasn't devolved to a slinging match yet, so we're not even near needing a timeout yet! But the desire to slap a warning on some people is so hard to resist at times (you know what I mean... the "how thick can you be" ones) ... it would be so hilarious if the forum has a commenting system that only the moderators/admins could see attached to forum posts...
-
You know, it would be really helpful if you said more than "IT DOESN'T WORK"!!
For instance - which image are you using? How did you write it? What power supply did you use? Have you tried other images with the pine64? What do you have plugged into it? You know, the little details that let other people get an idea of your setup and what could be going on. Otherwise I couldn't be blamed for saying that you need to tell the hamster in the wheel driving the turbine powering your pine64 needs to run a bit faster since I honestly believe at the moment you are running your pine64 via hamster power (isn't the imagination a good thing!).
-
I meant to mention - have you thought of trying the reverse? You keep trying to ping your Orange Pi zero, which appears to be 192.168.1.40. What is the device at 192.168.1.1 you're trying to ping? Your router? your laptop? If it isn't, try pinging your laptops IP... if the Orange Pi Zero can't see it... then how do you expect to be able to ssh into your orange pi zero? One of the major problems here is that you only give us part of the information, and we have to guess the rest. We aren't clairvoyant... we don't know what testing and knowledge you do have. We're just ordinary guys and gals who want to help other people.
Look at this image (which I googled) and see what voltage you think should be on pins 1 and 2 of the 13 pin header:
-
I personally think that 4.80v at the rpi header is too low, especially if the Orange Pi Zero was unloaded when you measured the voltage.
As a comparison for you, I just ran up a freshly downloaded build of Armbian 5.30 Debian Jessie onto a not great, but reliable microSD (I know tkaiser will be spitting chips when I say this... Sandisk Class 10 8GB - the red and grey type - it's what I had handy - but I usually use tested Samsung EVO cards - as quality cards is important). I used a power supply set to 5.30v, and a known good quality 1m microUSB lead. I loaded it up, checked the voltage at pins 1 & 2 of the 13 pin header - 5.20v when the power supply had dropped to 5.29... still well above the danger levels. I then enabled the wifi, pinged google. It worked fine. I then disabled the WiFi, plugged in the ethernet (connected to a GbE router/modem, but since Orange Pi Zero is limited to 100Mb isn't really relavant), tried pinging google again, and it worked fine again. I rebooted, left the wifi off, and tested the ethernet. Again no problem. I then ran a stress -c 4 to see what the voltage at the headers was on the orange pi zero. measured 5.08v - so it was a good thing I started off with 5.30v wasn't it! Cable and voltage is important. Finally, the really test - would SSH work. In the mean time, I had run "sudo apt update && sudo apt upgrade" to upgrade the system to 5.31, so you'll see the warning message. But, I logged into to the ssh using 'ssh -l pfeerick 192.168.0.54' without any issue.
So you see, there is something peculiar going on here... as we have conflicting reports of 5.30 Jessie not working... Igor tested it, and it worked. So does my set up. I'll test it on a second OPi Zero just for kicks, but I doubt it will play up. So we are left with it being hardware, either the board, the power, or the microSD. And power/microSD are the top two issues that people don't realise is the problem. So please forgive the more experience people here on the forum when they get testy... it's just they've seen it again, and again, and again... along with the "it can't be this" and the "it can't be that"... when it fact it can be and most often is.
So where does this leave us? I'm not sure yet. But you can see.. it's not as cut and dry as "the image is broken"... because if the image was broken, I wouldn't be able to show you this (serial terminal in the background, ssh session in the foreground):
Orange Pi Zero Armbian 5.30 Jessie (first boot, wifi enabled and checked then disabled, then ethernet enabled/checked):
SpoilerLinux orangepizero 3.4.113-sun8i #16 SMP PREEMPT Tue Jun 13 14:15:57 CEST 2017 armv7l ___ ____ _ _____ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) |__ /___ _ __ ___ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | / // _ \ '__/ _ \ | |_| | | | (_| | | | | (_| | __/ | __/| | / /| __/ | | (_) | \___/|_| \__,_|_| |_|\__, |\___| |_| |_| /____\___|_| \___/ |___/ Welcome to ARMBIAN 5.30 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i System load: 1.13 0.31 0.10 Up time: 0 min Memory usage: 11 % of 494MB IP: 192.168.0.53 CPU temp: 49°C Usage of /: 15% of 7.2G [ General system configuration: armbian-config ] pfeerick@orangepizero:~$ sudo ifconfig We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for pfeerick: eth0 Link encap:Ethernet HWaddr 0e:7a:b9:f7:b8:e3 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:678 (678.0 B) Interrupt:114 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:136 errors:0 dropped:0 overruns:0 frame:0 TX packets:136 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11472 (11.2 KiB) TX bytes:11472 (11.2 KiB) wlan0 Link encap:Ethernet HWaddr dc:44:6d:6d:50:23 inet addr:192.168.0.53 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::de44:6dff:fe6d:5023/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:114 errors:0 dropped:0 overruns:0 frame:0 TX packets:63 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:21240 (20.7 KiB) TX bytes:6864 (6.7 KiB) pfeerick@orangepizero:~$ ping www.google.com.au PING www.google.com.au (216.58.196.131) 56(84) bytes of data. 64 bytes from www.google.com.au (216.58.196.131): icmp_seq=1 ttl=54 time=41.1 ms 64 bytes from www.google.com.au (216.58.196.131): icmp_seq=2 ttl=54 time=94.6 ms 64 bytes from www.google.com.au (216.58.196.131): icmp_seq=3 ttl=54 time=202 ms 64 bytes from www.google.com.au (216.58.196.131): icmp_seq=4 ttl=54 time=93.8 ms 64 bytes from www.google.com.au (216.58.196.131): icmp_seq=5 ttl=54 time=151 ms ^C --- www.google.com.au ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 41.113/116.737/202.706/55.350 ms #unplug the wifi, ethernet not plugged in yet pfeerick@orangepizero:~$ sudo ifconfig eth0 Link encap:Ethernet HWaddr 0e:7a:b9:f7:b8:e3 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:678 (678.0 B) Interrupt:114 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:136 errors:0 dropped:0 overruns:0 frame:0 TX packets:136 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11472 (11.2 KiB) TX bytes:11472 (11.2 KiB) # plug in the ethernet pfeerick@orangepizero:~$ sudo ifconfig eth0 Link encap:Ethernet HWaddr 0e:7a:b9:f7:b8:e3 inet addr:192.168.0.54 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::c7a:b9ff:fef7:b8e3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:17 errors:0 dropped:0 overruns:0 frame:0 TX packets:19 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1668 (1.6 KiB) TX bytes:2550 (2.4 KiB) Interrupt:114 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:136 errors:0 dropped:0 overruns:0 frame:0 TX packets:136 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:11472 (11.2 KiB) TX bytes:11472 (11.2 KiB) pfeerick@orangepizero:~$ sudo ping www.google.com.au PING www.google.com.au (216.58.196.131) 56(84) bytes of data. 64 bytes from www.google.com.au (216.58.196.131): icmp_seq=1 ttl=54 time=39.6 ms 64 bytes from www.google.com.au (216.58.196.131): icmp_seq=2 ttl=54 time=38.3 ms 64 bytes from www.google.com.au (216.58.196.131): icmp_seq=3 ttl=54 time=42.5 ms 64 bytes from www.google.com.au (216.58.196.131): icmp_seq=4 ttl=54 time=38.5 ms 64 bytes from www.google.com.au (216.58.196.131): icmp_seq=5 ttl=54 time=38.9 ms ^C --- www.google.com.au ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4007ms rtt min/avg/max/mdev = 38.396/39.619/42.578/1.543 msOrange Pi Zero Armbian Debian Jessie 5.30 second boot, wifi disabled, ethernet only:
SpoilerLast login: Thu Jun 22 11:02:30 CEST 2017 on ttyS0 Linux orangepizero 3.4.113-sun8i #16 SMP PREEMPT Tue Jun 13 14:15:57 CEST 2017 armv7l ___ ____ _ _____ / _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) |__ /___ _ __ ___ | | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | / // _ \ '__/ _ \ | |_| | | | (_| | | | | (_| | __/ | __/| | / /| __/ | | (_) | \___/|_| \__,_|_| |_|\__, |\___| |_| |_| /____\___|_| \___/ |___/ Welcome to ARMBIAN 5.30 stable Debian GNU/Linux 8 (jessie) 3.4.113-sun8i System load: 0.64 0.15 0.05 Up time: 0 min Memory usage: 9 % of 494MB IP: CPU temp: 48�°C Usage of /: 15% of 7.2G [ 0 security updates available, 42 updates total: apt upgrade ] Last check: 2017-06-22 11:23 [ General system configuration: armbian-config ] pfeerick@orangepizero:~$ sudo ifconfig [sudo] password for pfeerick: eth0 Link encap:Ethernet HWaddr 0e:7a:b9:f7:b8:e3 inet addr:192.168.0.54 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::c7a:b9ff:fef7:b8e3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:35 errors:0 dropped:0 overruns:0 frame:0 TX packets:23 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3389 (3.3 KiB) TX bytes:2858 (2.7 KiB) Interrupt:114 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:200 errors:0 dropped:0 overruns:0 frame:0 TX packets:200 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16656 (16.2 KiB) TX bytes:16656 (16.2 KiB) pfeerick@orangepizero:~$ sudo ping www.google.com.au PING www.google.com.au (216.58.203.99) 56(84) bytes of data. 64 bytes from ssl.gstatic.com (216.58.203.99): icmp_seq=1 ttl=54 time=39.2 ms 64 bytes from ssl.gstatic.com (216.58.203.99): icmp_seq=2 ttl=54 time=38.9 ms 64 bytes from ssl.gstatic.com (216.58.203.99): icmp_seq=3 ttl=54 time=42.5 ms 64 bytes from ssl.gstatic.com (216.58.203.99): icmp_seq=4 ttl=54 time=39.6 ms ^C --- www.google.com.au ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 38.951/40.094/42.513/1.441 ms pfeerick@orangepizero:~$
Improve 'Support over Forum' situation
in Off-topic
Posted
Oh FFS... now the forum ate half of my post because I went back to turn off the code syntax highlighting!
I had basically said that if we want to be stuck in a vicious cycle of saying 'have you checked this' and 'have you checked that' then, sure doing things the way they are now. Or if you want to be proactive and head them off, add some simple checks that you can point to and then say here are the docs that explain what the problem is.
And no, no-one gets paid for this. But time is time, and I'd rather spend it doing other stuff, rather than answering the same question day in and day out. And scaring people off is not what I want to do either, because that doesn't achieve anything other than annoy and frustrate. I'd rather be promoting a community of people that share ideas, problems and solutions. I'm just thankful that some manufactures are listening, including the infamous supercomputer SBC manufacturer, which should now be using a barrel jack instead of a micro USB connector for power (which doesn't help people with the earlier revisions, naturally) and was incorporated into their designs for future products. Yes, mistakes are still being made, but so is progress. Sometimes. Doesn't mean we should let up the pressure on manufactures to do the right thing, but something is needed to protect the sanity of Armbian folks from their stupidity.
Anyway, was this the sort of boot test you were thinking of?
Obviously /usr/bin/cpuburn would have to be added into the right place. This if course doesn't go any further than the power-on test... there's no linkage to MOTD or anything. I was thinking of a script that checks how many attempted starts there have been, and then after a set number, say on the third fail, it bypasses, cleans up its attempts tracker, and touches a file that can can trigger a permanent MOTD warning. Then if in the future the user changes their power supply, they re-enable the service, and run it through again, where it will clear the MOTD warning if the test passes. And it's linked to the firstboot process, so it is disabled once first boot completes either way. Bad idea? Waste of time?
And then as you said, add a more rigorous 3-5 minute test to armbianmonitor -c . Then that becomes the standard diagnostic if anything possibly power or microSD related is reported.