tkaiser

This thread came to my attention only today So how can we prevent this? This is not the first time an Armbian update bricked server installations due to insufficient testing. How can we prevent this ever happening again?

2 things changed: you stopped those dangerous Y USB cable mess you power your board totally differently now (or did your self-built cable always looked like this with ability to connect the Multimeter) BTW: if you want to explore undervoltage you need to measure someone else of course: at the board and even at the disk enclosure!!! I haven't checked schematics but 5V should be available on pins 4 and 6 of the GPIO header. If the cable between PSU and board is insufficient it's pretty normal that 5.1 at the PSU turned into something below 4.7V at the board. And voltage available to a connected disk might be even lower.

https://superuser.com/a/1022965

Please add -v and provide the URL: h3disp -v -m 10 -d And of course h3disp needs a reboot for changes to take effect since all this tool does is adjusting script.bin which is only read at boot time.

But you used h3disp before since prior to the upgrade you didn't have a pink screen and now you have? If that's the case you need to re-apply settings again ('h3disp -d' to get non-pink screen with HDMI-DVI adapters) and this time they might stick since I tried to fix h3disp recently but don't know whether this update made it into latest release or not.

Hmm... you're focused on amperage/consumption but why? The specs talk about 'Standard Operating Voltage 5V ± 5%' and that's the most important sentence there: 4.75V is the minimum allowed according to these specs and 5.25V is the maximum. So in case your PSU is currently adjusted to 4.7V you're well below specs. You use a PSU with adjustable 5V output voltage so which voltage do you feed your board with? Unless you're able to answer this question it's really absolutely pointless to do any further step in any direction... Besides that: I've always 3 Samsung SSDs flying around for tests only and they all run fine with just 4.5V (but none of them is a 'Pro', it's all cheap EVO stuff). One of those, the EVO750, is somewhat nasty since with this SSD I can power down every Micro USB powered board connected with an insufficient cable to the PSU. This thing seems to have an insanely high peak consumption at startup which then leads to either a huge voltage drop or consumption peak on the DC-IN input line immediately killing each board I tried with already. Works of course fine when powered from a separate PSU. PS: I really start to hate this SBC crap... https://linux-sunxi.org/Xunlong_Orange_Pi_Prime (no one took the time to add a device page with PCB pictures so we could look for voltage testpoints)

But please provide the requested information: Which HDD are you using (it's important since different brands behave differently wrt undervoltage) How do you really power your board? On the led strip PSU there's only a screw terminal. What is connected to this and how do the cable diameters look like? The real problem is that the average user is not aware of voltage drops and that amperage ratings printed on the PSU are less relevant (ok, often it's both -- cheap PSUs show faked amperage ratings or there is at least the following relationship: a cheap 5V/3A PSU either provides 5V or 3A since if a device really would want to draw 3A the voltage already dropped to such low levels that the device to be powered crashed due to undervoltage). In case your PSU is adjusted to provide less than 5V and you use tiny wires between PSU and board every single symptom you report is just the well known and pretty common undervoltage problem no normal user is willing to accept (and that's what this subforum should serve for: giving a nice overview of 'real life underpowering stories' for other users to read through and learn from -- but if threads aren't readable any more due to confusion spread and walls of text for no reason this subforum becomes as useless as every piece of instructions we provide since no one ever will read them)

If this thing overheats there's only one solution: do not use it. In case you want to address your problem one more time in trial&error mode check the voltage available on the screw terminals. If you measure below 5V (which I would assume) use the blue thing next to it to adjust it to 5.25V, then try again.

Feel free to waste your time further on this, I only answer in the hope that some of the 8 moderators in this forum later do what they originally wanted to do (some housekeeping to help users): 'usb 3-1: reset high-speed USB device number 2 using ehci-platform' this message tells you that USB controller 3-1 lost control to device 3-2 (that's your external JMS578). Usually this is the result of undervoltage, the external disk doesn't get enough voltage (which HDD do you use? Some of them start to get in trouble when voltage drops below 4.7V, some others are even fine with 4.4V), disconnects from JMS578's SATA PHY which in turn let the JMS578 disappear from the USB bus. Reduced consumption let's the voltage rise again, the disk reappears and so the JMS578 does In the meantime your filesystem is already corrupted (which is perfectly understandable if there are continous USB resets) so I would better check with 'btrfs scrub /home' now If you want to switch from trial&error mode into investigation mode you need a Multimeter to check voltage available on testpoints under load and in idle And if you want to solve the problem with an external disk that is not able to be powered on its own you need to provide a reliable power source able to provide a STABLE voltage and enough current (using those Y-cable and connecting them to two different power sources with different voltages available is nothing I would call 'stable power source') Edit: Realized that this sounds all too harsh but I really just want you to stop wasting your time since it's really pointless. Even if OPi Prime is not supported it's IMO misleading to not tell you that you need a 3A PSU with stable voltage to do the next step. All of your symptoms are well known and with 99% probability underpowering related. So again it's pointless to spend any time on this before this common problem source is not eliminated.

Sure, why not. But honestly I don't care any more...

When you see 'Error 500' accessing any page on sprunge.us this means always the same: Internal server error at sprunge.us (this is an online pasteboard service Armbian is only using since majority of users fails with providing log output -- so we integrated an automatic upload mechanism in Armbian that works almost all the time but sometimes not, simply try it again) And you can stop flooding this thread with more and more underpowering reports since it's pointless. I also have no idea why this thread is not already in the correct subforum.

Then most probably something went wrong. I flashed for and back differnet firmware versions maybe 30 times within the last weeks and sometimes it didn't work as expected (needs a full power cycle). So I started to immediately check again after powering on the JMS578 and this confirmed to my surprise that sometimes the update was not applied: JMS578FwUpdate -d /dev/sda -v

Just for your information... this is with the images I provided that were made with an u-boot with eMMC support and a fex file with eMMC support. No, there's no NAND in this box and none of all the outdated NAND related stuff applies to ANY H3 device. It should be as easy as booting from SD card, updating everything with 'apt upgrade' and then executing nand-sata-install. Just as a small reference for those poor souls who happen to stumble accross this screwed thread later...

Same HC1 used, same SSD (EVO840), JMS578 on the board vs. JMS578 connected to USB 2.0 port (ROCK64 SATA cable), same firmware version on both JMS578 (JMS578_Hardkernel_v173.01.00.01.bin), same benchmark test: 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2': JMS578 via USB 3.0 random random kB reclen write rewrite read reread read write 102400 4 13592 14530 18712 18744 14664 14514 102400 16 46857 49586 59322 59665 50182 49651 102400 512 204547 217732 200402 205359 201479 217830 102400 1024 233728 239458 237045 247595 241844 245813 102400 16384 224437 276093 308294 317705 317230 274902 JMS578 via USB 2.0 random random kB reclen write rewrite read reread read write 102400 4 7960 7967 7995 7999 7993 7977 102400 16 15040 15643 15984 15998 15984 15930 102400 512 21761 21874 22360 22411 22416 21884 102400 1024 22332 22866 22509 22585 22582 22421 102400 16384 22476 22912 22801 22864 22765 22879 Above tests were made with performance governor... and obviously performance sucks (I've seen much better numbers already). I flashed the external JMS578 with v0.4.0.5 firmware again and tested: JMS578 with v0.4.0.5 firmware via USB 2.0 random random kB reclen write rewrite read reread read write 102400 4 7318 7967 7994 7999 7988 7976 102400 16 15584 15904 15982 15998 15984 15938 102400 512 22059 22787 22400 22442 22436 22170 102400 1024 22508 22875 22524 22586 22583 22558 102400 16384 22554 23002 22810 22853 22760 22956 So most probably this is a kernel issue and something slowing down USB has been commited to Hardkernel's 4.9LTS kernel in the meantime. Please direct all your questions at Hardkernel over in ODROID forum, I'm simply too tired to deal any more with this constant mess...

By setting the speed with ethtool: https://github.com/armbian/build/blob/master/packages/bsp/h3consumption#L56 (h3consumption is essentially doing just that: adding a line with an ethtool call to /etc/rc.local). Besides that you really don't want to use any nightly build for something productive (recently Ethernet stopped to work on H5 boards with latest nightly kernel) and there's a nice OMV image available for the board you're interested in which is the best idea if you want to start with OMV anyway...

HC2 arrived. PCB almost identical but powering has changed since this variant will be powered with 12V from the barrel plug. Hardkernel sent a 12V/2A PSU which I found a bit on the low side since the Seagate Barracuda I tested with shows a pretty high peak consumption at spin up and then an idle HC2 with the disk spinning up already reads 24W measured at wall so imagine when something heavy runs on the Exynos at the same time. I would choose a 2.5A PSU just for some safety headroom. Edit: Hardkernel responded that they tested their '2A rated' PSU with very high loads close to 30W over many days and also their PSU supplier said, consumption up to 2.5A wouldn't be a problem. So the PSU is sufficient even for very power hungry 3.5" disks but problems might occur if an additional host powered 2.5" disk is attached to HC2's USB2 port. Dealing with 3.5" disks has the usual downside: higher consumption. Even in idle with the 12V PSU: 5.3W on average with disk sleeping (compare with HC1 values yourself on 1st page of this review). Edit: tested also with a sleeping SSD and got 4.3W in idle and without just 3.9. So differences between HC1 and HC2 in idle are more or less only related to standby consumption of the disk in question and not related to the 12V PSU being less efficient than HK's 5V PSU. Performance will only depend on the disk used (of course you can combine HC2 with SSDs too!) so with a somewhat decent 3.5" HDD and either mainline Armbian or Armbian based OMV you get +100 MB/s sequential performance through the network for sure as well as lousy random IO performance since all HDD simply suck here. Since this is a dev sample that had been sent out prior to JMicron releasing the upgrade I had to apply latest JMS578 firmware upgrade myself and now everything simply behaves as it would be true SATA (SAT -- SCSI/ATA translation -- fully working, no spindown issues, correct drive serial numbers reported). Once HC2 will be shipped to Customers next month this won't be necessary since latest firmware upgrade already applied by Hardkernel then. Final note: the plastic 'case' that can be seen above works exactly as the smaller HC1 variant and even if it's black all LEDs shine through perfectly since it's fortunately somewhat translucent. 100% software compatible means I was up and running in no time. Tested with XU4/HC1/HC2 OMV image: http://sprunge.us/BWMF Edit: Reported SoC temperature is a few degree above HC1 level. I asked Hardkernel and they explained: 'Because of the DCDC converter circuit to make 5V from 12V input, the PCB temperature is higher around 3~4C than HC1'. Quick test with firing up short benchmarks on HC1 and HC2 seem to confirm this, the temperature rise/fall is the same just overall temperature is slightly higher. So there's nothing to worry here, it's just the PCB spreading some more heat into the SoC.

Why spreading so much confusion? Both boards have own wiki pages provided by technical writers so there's no need to focus on temporary mistakes their marketing folks might make. Main difference between both boards is that Core2 features an RTL8211 GbE PHY while Core uses the SoC's internal Fast Ethernet PHY. And I hope they stay with H3 (or H2+ since essentially the same) on Core and H5 on Core2 and do not start with stupid SoC exchanges since this only leads to confusion and users picking up the wrong OS images. Peripherals (heatsink included) are all compatible and they designed the boards fortunately backwards compatible. Pin headers soldered or not can be decided in the store at checkout time (I assume the Core when ordered together with the Mini Shield comes with them presoldered, I can't imagine FE repeating the same mistake as with the first NAS expansion bay). Size of DRAM is choosable and eMMC optional. Which combinations might be available might change over time (based on feedback/demand) There's USB OTG on the Micro USB port (other boards do it differently eg Tritium and NEO Plus 2 so it's worth to mention since both boards even without pin headers soldered can provide limited network connectivity through g_ether module) and the boards can be powered through pin headers too. Ethernet implementation is interesting since they offer the same Mini Shield for both variants so it should be possible to combine the Core2 with an external GbE MagJack as long as traces are short and most probably of same length ( didn't look into schematic yet). Software support efforts seem to be minimal (more or less only DT stuff and maybe checking for GbE TX/RX delay adjustments) and at least with the Core I wouldn't consider Micro USB for DC-IN a show stopper...

Should be fixed now in latest release: https://forums.resin.io/t/etcher-v1-2-1-release/2265

Exactly and that's why it became useless to cobtribute here. Since we can talk all day long, try to reach a consensus and in the end you do whatever you want anyway. What's the purpose of these 'web services' Armbian provides? What happens here and there? dl.armbian.com and armbian.com/downloads: This is where people want to download software or maybe even do device differentiation to prepare a buy. They need good navigation there, something that can clearly be addressed by letting experts redesign these pages as it's currently planned forum.armbian.com: could be a place to complain and asking for help about installation related stuff. But instead it's something different: the heart of Armbian's community, a place where people can learn a lot and even collectively develop new ideas/projects. We have here device reviews, we have technical tutorials, we have overview articles/threads to help users decide which device to choose (not hours but days of my life went into this kind of forum contents over the last 2 years -- for the sole reason to make this forum and community attractive for more users) www.armbian.com: Nothing, it's an ugly and overloaded page hosting a brief project description with tons of links (majority not even easily accessible). If you visited this page once there's no reason to ever come back since there's nothing to see (it's this kind of web pages that are only viewed by their owners regularly and by no one else) Trying now to throw people out of the forum explaining this would be a 'fix' since 'Navigation is wrong' is telling. Since there exists no reason. Not a single one except maybe someone trying to follow some 'design guides' in a formalistic way that do not apply here (we're not a news site like Arstechnica -- there it makes some sense to redirect people from the forum back to the main page but not when the forum is the most attractive part of the whole site). If you (would start to) look at your project from the outside having your users in mind you want to direct the visitors of your site in a reasonable and not a stupid way. There's nothing to see at www.armbian.com so it can be considered even a mistake to link to this page. You would need to hire a 'content marketing' guy to change this filling www.armbian.com with artificial content. But why? Why would this be needed? Again wasted time trying to explain stuff. For no reason since what needed a serious amount of time will be destroyed later in seconds. As it happenend countless times in the past (we babbled already so much about eg. testing and release policies) and that's why it's useless to continue here (same with 'Board Bring-Up' BS in the meantime -- even if there is a consensus that we try to support way too much boards in the meantime obviously it doesn't affect you at all).

https://forum.armbian.com/topic/5759-535536-bug-questions-collection/?do=findComment&comment=45111 (you better open a Github issue to ensure it will be fixed)

Well, nothing more to add. @Igor: This sort of 'decisions' are the ones that makes contributing here useless. We babble about stuff and then you change something thinking it's not a big deal (see also count of boards Armbian tries to support and why). Anyway, it has become just a waste of time...

Who decided when for which reason to render this forum's most used UI element (the logo in left top corner to get back to 'Forums Index') to be broken? Why is it necessary to break functionality now and why isn't it possible if it's about breaking usability to do this as part of a re-design/relaunch process after usability concerns have been addressed?

More than 6 times here and this is the final proof why all this babbling is 100% useless. Igor's decision yesterday to switch NanoPi M3 from .csc to .wip was enlightening.

The firmware upgrade will only succeed after a full power cycle of the USB-to-SATA bridge (so a simple reboot will NOT do). For ODROID-XU4 and HC1 please direct questions at https://forum.odroid.com/viewtopic.php?f=97&t=28535 (since Hardkernel provides this update).

Then please use Etcher on Windows (again: Etcher on Linux is currently as crappy as dd or Win32DiskImager since NOT IMPLEMENTING VERIFY)