TMA-1

Thanks for the compass heading grn. While building an Armbian image looks like a good learning project for me and I may do it just for the experience some day, the truth is all this time I've been trying to avoid deploying a fresh image to my existing SBC. I was hoping to somehow modify the existing configuration to "not break" when updates were applied. I guess that's a pipe dream and I should get off my butt and re-deploy Armbian, one way or another. My thanks and regards to all who chimed in on this saga.

Just got back from a short period off-line. Excited to see there may be a "patch". Unfortunately my neophyte Linux skills and non-existent Github ones don't point me at anything I know how to use at the link above. Has anyone tried it? Does it work?

Yeah, I'm afraid I don't have the skills or the time to even begin to digest that code scroll. Neither do I hold out much hope that a 3A supply will help. I am running 3A into a powered hub (among other combinations I've tried), and it still falls flat on its face 100% of the time. I seem to be hearing that "it's just broken". Armbian_21.05.1_Orangepioneplus_buster_current_5.10.34.img.xz , plus updates, equals "kaboom". This is a pity, since I feel that my renewal and redeployment of the affected boxes I'm using was "relatively recent" in terms of what should still be supported. This leaves me with 2 choices,... re-do the machines yet again (starting with a more current distribution), or forget about doing updates. If there's another choice a neophyte can implement, I'm all ears. In the mean time, no more updates for me. My thanks to all those who chimed in to help and commiserate. Best Regards, all.

Thank-you grn for all your hard work. I'm going to show my linux noob colors again (as stated at the top of this thread), and admit that I only "half follow" what is obviously a well-researched and well-presented analysis. If I'm hearing this all correctly, it sounds like whether or not you get torpedoed by "killer updates" depends on what version of u-boot you have. Total noob question: If it's not part of the distribution image, where does the u-boot (I'm not even sure what that is) come from? Not to get ahead of myself, but my bottom line question would be: How would one go about fixing it? Best wishes.

For the record my instances are 2.1 as well. I don't completely follow what you've done grn, but it sounds like you've established that the same starting images have been used. By the process of elimination,... But I just checked my cards and 1 of the 3 I've been using is a U3 as well. They're all 16GB though. That shouldn't make a difference,... Whatever this is, it's over my head.

Long cool-downs do seem to work sometimes, through one mechanism or another. I have one cardboard box I call The Burnouts Box. Things that appear beyond immediate hope go in there when the heart is reluctant to scrap them out entirely. And things have come back from The Burnouts Box a few times, when my knowledge and skills have increased, or sometimes as you said, by just giving it another try at a later time. Unfortunately in this case, I cannot believe there are so many spontaneous parallel hardware failures which only show up after updates. There are 4 complete independent layouts in play, counting grn's. That much coincidence is a poor bet imho, though they did give away the top $100,000 prize on Wheel of Fortune three days in a row recently. Anyway, thank-you all for your time and attention. For the time being I am running my Pi-Hole and TorrentSlave as they are, and just avoiding The Killer Update. Something will change,... eventually.

That is disappointing. Like grn, my setup has been running for 1 or 2 years. I am using 3 instances of board, (1 of which was traditionally "spare"), 3 uSD cards, and a well-proven and beefy PSU. I have cross-checked the PSU and the connecting USB cord. All work fine in other scenarios, as do their substitutes. The problem only occurs after I apply the updates. It seemed that depending on what distribution image was started from, something got applied in the apt update and apt upgrade process that threw a marble into the gearing. So I too downloaded Armbian_22.02.1_Orangepioneplus_focal_current_5.15.25.img.xz experimentally from the Net today, and it surprised me by triggering the problem straight away! Would not boot, claiming the UUID is incorrect. Armbian_22.02.1_Orangepioneplus_bullseye_current_5.15.25.img.xz did the same thing. The cancer, whatever it is, is spreading. Or I'm going insane, or both. Now I don't know what to think. When logic fails, challenge the assumptions. Is there any chance that differences exist in older OPi1+'s vs. newer ones? Is there any chance that "fresh" downloads of the OS are somehow getting different images? Could it somehow be related to the process of taking the ~.img.xz file onto the SD card? (I think "No", because that wouldn't explain the update sinking things.) Clutching at straws now,...

Okay, as long as I have it all set up, I tried it. stock Orange Pi One Plus deploy Armbian_21.05.1_Orangepioneplus_buster_current_5.10.34.img.xz (reboot--works) apt update apt upgrade attempt reboot Splat.

Thanks Myron. I do use 2 cards in rotation for speed, refreshing a card from the pre-updates image squirreled away on my PC when I want to try something. Yes, it is just a simple apt update && apt upgrade that does it in. Weird huh? Werner,... tried it. No appreciable difference I'm afraid. The latest bootlog is here. For information, the distribution image I started with was Armbian_21.05.1_Orangepioneplus_buster_current_5.10.34.img.xz Then I probably did some installs and tailoring, but nothing that should spread any engine grease. Now this current batch of upgrades, and "kaboom". I could probably recreate the entire scenario from the initial install if desired.

Okay I'm back. And I got the logging to work. For the record it was 115200 baud. Thanks for thought to check the TTL-USB dongle Myron; I indeed did do that because it was one that I haven't proven in use before. It was not the culprit, however. We won't talk about what I was actually doing wrong. (Oh, so THAT's what THOSE 3 lonely pins are!) Here's hoping that the primary issue is as easy to solve. The log from before I do updates (system booting fine), is here. The log from after I do updates (and the system becomes a glorified brick), is here. They look pretty similar to me up until a message on the "updated" system that something has tripped over a bad kernel command. It's a little beyond my pay grade though. I hope one of you gurus can hero it out.

(Still away). I did try 115200 and 9600, but don't recall in what combination with other similar gotchas. I'm sure it was something like that though,... just have to find the magic elixir that works, then I'll get back to the real problem. Thanks for the support.

Thank-you very much for the reply Werner. If you mean "a fresh install" from distro, no, I haven't done that. I'm trying to rescue the existing machines. I have two separate machine identities (which do have a common ancestor, if we were to go back far enough), having their own backups each. I have restored the two backups multiple times, tried something, applied updates, and then hit the brick wall in both cases, every time. Getting a full boot log to a serial console is a great idea, and I've been working on doing that, but haven't quite figured it out yet. I have verbosity=7 and console=both in /boot/armbianEnv.txt, and have a serial dongle, but have not yet gotten any traffic into a Putty session. Obviously doing something wrong, and need to play with that more. When I get back from travel this weekend I'll get back to doing that. Thanks again for the compass heading.

Hello, I'm sort of an "educated noob" on Linux, meaning I understand about 1/2 of the postings in forums like this one. And I seem to have a problem. I am using Armbian Buster on an Orange Pi One Plus. After the most recent (to me) batch of updates, the machine will no longer boot. The error is: "Gave up waiting for root file system device." This occurs after numerous instances of "Running /scripts/local-block", (which does not seem to exist), and is followed by "ALERT! UUID=[valid UUID] does not exist. Dropping to a shell!" The "shell" it pro-ports to drop into is mythical, I assume because no keyboard driver has even been established. The computer is completely unresponsive. He's dead, Jim. The only thing I can do is recover from backup, which dates back almost a year (I know, I know,...), so any re-application of updates now involves a basket of 150 packages. (I do not remember how recent the "killer" update may have been.) I have recovered multiple times, trying this-and-that from old postings on the Net. The lack of any more recent similar postings makes me think this problem is unique to me, but I don't know why. There are no RAIDs involved. I do not use encryption. The UUIDs match across /boot/armbianEnv.txt, /etc/fstab, and the error message. I have multiple instances of the Orange Pi hardware; they all exhibit the same problem. Multiple uSD cards; same problem still. And at least two different machine identities share this grief. I simply cannot apply any updates since my backups were taken, without killing things. What I CAN do is apply the updates, avoid restarting, and then make some kind of repair, if only I knew what that repair was! The system runs fine until it's asked to shut down and restart. Any guidance regarding where and how to look for a solution would be appreciated.