Upgraded Endeavour OS

[raymac46]

It's really like playing whack-a-mole. About the only thing we can be sure of is that some sort of corruption occurs during updates. It seems to be worse if a kernel upgrade is indicated. I doubt that there is a foolproof remedy.

If I absolutely had to run a Linux VM in Windows I think I would choose a different virtualization solution - VMWare maybe. And my choice of distro would be probably Debian-based.

All this "learning" has convinced me that "one PC - one O/S" is the better way to go. You can test a distro in a VM but the only way to be sure is to actually install it.

If you need to run Windows as a guest in Linux, you have better options.

[Hedon James]

23 hours ago, raymac46 said:

It's really like playing whack-a-mole. About the only thing we can be sure of is that some sort of corruption occurs during updates. It seems to be worse if a kernel upgrade is indicated. I doubt that there is a foolproof remedy.

If I absolutely had to run a Linux VM in Windows I think I would choose a different virtualization solution - VMWare maybe. And my choice of distro would be probably Debian-based.

All this "learning" has convinced me that "one PC - one O/S" is the better way to go. You can test a distro in a VM but the only way to be sure is to actually install it.

If you need to run Windows as a guest in Linux, you have better options.

I've been saying for years "why run a supremely stable VM on a somewhat unstable, buggy & quirky host; when you can run the unstable, buggy & quirky system as a VM on a supremely stable and rock solid host?!"

[raymac46]

Another update today that had some glib2 and linux-firmware in it. Tried something a bit different.

I used the eos-rankmirror script before updating and then ran the eos-update script. These are available as graphical buttons on the Welcome screen.

Dracut rebuilt the kernel modules as part of the update. After a reboot things were OK.

I don't know if this proves anything.

[raymac46]

One further experiment. Since VMWare Pro is now free for personal use, I downloaded it and installed EOS there. No updates yet but it was pretty easy to install and get a full screen. I'll compare it to VBox as we go along.

[Hedon James]

1 hour ago, raymac46 said:

One further experiment. Since VMWare Pro is now free for personal use, I downloaded it and installed EOS there. No updates yet but it was pretty easy to install and get a full screen. I'll compare it to VBox as we go along.

Oohhh....that sounds interesting!  I was looking for ways for you to install VMM on Windows, or another KVM-qemu solution, but it got overly complicated (IMO) and I'm not nearly as familiar with Windows as I was 15 years ago.  I like where you're going with this....isolate whether it's a VBox issue, or cross it off the list. 

[raymac46]

I have now done another VBox update being careful to rank the mirrors before I did. This one had another kernel upgrade. Used the EOS update script as well. Dracut rebuilt the modules. After a reboot everything is OK. Posting from it now.

[raymac46]

I have to say that I do like the look, feel, and ease of use of VMWare Pro.

However as a long time Linux user I believe that the choice between throwing my lot in with Oracle or Broadcom is a bit of a Scylla vs Charybdis decision. 

Edited December 12, 2024 by raymac46

[raymac46]

I have now completed a couple of days of EOS updates in both VBox and VMWare without incident. In both cases, I have made sure to rank the mirrors before the update.

It's too soon to take a victory lap, but it looks promising. We had a suspicion all along that mirror inconsistency caused the problems in EOS. Syncing or ranking the mirrors might be the solution.

I spot the light at the end of the tunnel. I just hope it isn't a train coming the other way.

 

[raymac46]

You never know in the Linux biz, but I think we may have solved our EOS VBox issue. I have done probably 10 upgrades now and rebooted each time without a hitch. The trick is to update the Arch and EOS mirrorlists before doing any upgrades.

I'd like to give credit to Hedon James for initially identifying the problem as a poorly synced mirror issue.

[Hedon James]

2 hours ago, raymac46 said:

You never know in the Linux biz, but I think we may have solved our EOS VBox issue. I have done probably 10 upgrades now and rebooted each time without a hitch. The trick is to update the Arch and EOS mirrorlists before doing any upgrades.

I'd like to give credit to Hedon James for initially identifying the problem as a poorly synced mirror issue.

Appreciate that, but you're equally deserving.  I just listened to your symptoms and set forth a few theories to be tested.  I (we) was wrong on every one until we finally achieved some success.  We just out-persisted the problem, LOL!

 

With that said, I think you and I must be the most unusual combination of computer buddies in the history of computing.  You and I almost always approach something with 180-degree "opposite" perspectives, and yet somehow end up with nearly identical conclusions.  If I ever have cause to form a "mastermind" group, you'll probably be the first person I ask to join.  I believe that "groupthink" is a BAD thing, so anyone who thinks differently than I do, yet concludes similarly, is someone I can definitely work with! 

Edited December 20, 2024 by Hedon James

[raymac46]

I guess our Venn diagrams intersect enough to give useful results. That has always been the way I have worked. Usually I achieved my best results with people who were the total opposite to me in temperament and/or philosophy.

I think our secret sauce is that we are open to each other's ideas.

[Hedon James]

8 minutes ago, raymac46 said:

I guess our Venn diagrams intersect enough to give useful results. That has always been the way I have worked. Usually I achieved my best results with people who were the total opposite to me in temperament and/or philosophy.

I think our secret sauce is that we are open to each other's ideas.

absolutely!  if you think like me, we're just duplicating each other's efforts.  and if you know something I don't know, I wanna learn what you already know. 

 

How many times have you & I reached a similar/same conclusion on this forum, but for completely different reasons?  More times than I can remember!  It's uncanny, IMO...

 

Edited December 20, 2024 by Hedon James

[Hedon James]

Did my monthly update of VMs in VMM.  Arch, Manjaro & Endeavour all updated without incident.  Endeavour suggested a reboot as "core packages" were updated.  Rebooted and back up and running without incident. 

 

Side note:  Endeavour looks like a keeper in my VM farm, to keep an eye on for awhile.  I was debating between Endeavour and Garuda until this thread kinda tipped the scales for me.  Gonna tweak the appearance a little, as I'm not a fan of that light theme, and the mish-mash of GTK and QT elements.  Probably gonna install Kvantum theme engine to get more QT-flavor, and maybe look for a dark theme, and copy one of my custom Openbox themes over.  Nothing too crazy...it IS a VM...but that light theme just gets hard to look at for more than about 10-15 minutes, LOL!

[raymac46]

I have also done updates in VBox and VMWare and I have been careful to sync the mirrorlists before I did. Everything is working great now. I shall probably customize the wallpaper on both the display manager and desktop but don't need to tweak the defaults much.

[Hedon James]

31 minutes ago, raymac46 said:

I have also done updates in VBox and VMWare and I have been careful to sync the mirrorlists before I did. Everything is working great now. I shall probably customize the wallpaper on both the display manager and desktop but don't need to tweak the defaults much.

I'm glad you found a solution to maintain Endeavour as a VM on your system!  But now that we figured out HOW to make it work, I really wish we could figure out WHY it needs to be done that way?  I just don't know enough about Arch to even begin to guess?!

[raymac46]

I cannot deduce an exact cause because I think it's a VM-Distro interaction. However VBox seems sensitive to corruption based on incomplete syncing of the Mirrors. All I know is that once I did a formal sort of both the Arch and EOS mirrorlists, the glitches went away.

There doesn't appear to be the same problem with EOS on bare metal but I think I'll adopt the best practice of syncing before updating there as well.

Why Arch is more of an issue than stable distros like MX also eludes me. But I think a rolling release is always more of a problem in VMS.

[Hedon James]

20 hours ago, raymac46 said:

I cannot deduce an exact cause because I think it's a VM-Distro interaction. However VBox seems sensitive to corruption based on incomplete syncing of the Mirrors. All I know is that once I did a formal sort of both the Arch and EOS mirrorlists, the glitches went away.

There doesn't appear to be the same problem with EOS on bare metal but I think I'll adopt the best practice of syncing before updating there as well.

Why Arch is more of an issue than stable distros like MX also eludes me. But I think a rolling release is always more of a problem in VMS.

I absolutely concur it's a VM-Distro interaction.  In all fairness to VBox, we don't know it's a VBox issue.  Who's to say that VMM wouldn't experience the same issue if I wasn't using the -Syyu flags, instead of just -Syu?  And didn't you experience a corruption with VMWare?

 

I wasn't expecting an answer, but just expressing that now that we've stumbled onto a solution (got lucky?), I hope time will fill in the blanks and reveal WHY the solution works with that issue?

 

In my experience, it isn't necessarily an Arch issue.  When I was performing my monthly updates of VMs, I was paying extra attention to the VMs before I attempted the update.  Windows 10, Arch, & Manjaro VMs all experience a significant time lag before the date/time becomes current in the VM.  That lag can be 30-60 seconds, or even up to about 5 minutes...and I can see the disk light flashing that there's activity in the background.  Those OSes are doing something in the background BEFORE they bring the date/time current to the host.

 

Ironically, Endeavour does not have this problem, despite being an Arch derivate.  And I don't have that experience in Debian-based VMs (including 'Buntus, Mint, MX, etc...), nor OpenSUSE VMs (more recent additions).  Those distros reflect correct date/time immediately, or within milliseconds, of opening.  I finally got around to a BSD VM with GhostBSD, and I note that GhostBSD also has the "delayed" date/time behavior.

 

Earlier in this thread, I speculated that bare metal installs don't have this issue because they're on, and connected, constantly.  They update in real time, as updates become available.  Similarly, so do the mirrors.  But a VM is started "cold" from a "last known" configuration (I save snapshots, you indicated you shutdown & restart).  I think that "last known" configuration (including mirrors) becomes "un-synced" for some reason.  Wouldn't have that issue if it updated in real time.  But for some reason, Arch, Manjaro, BSD & Windows 10 all have a delayed reaction with date/time before it gets sorted and syncs with host OS date/time.  It makes sense to me that mirrors/repos would be affected by that also.  It makes NO sense to me why Endeavour (Arch derivate & rolling release) and Debian & OpenSUSE families (stable point releases) do NOT.

 

EDIT:  GhostBSD-VM is a different issue than Arch.  It's only been a VM in my farm for about 2 days, and still feeling it out and learning.  Ghost forums seem to indicate that if the internal ntp has a 1,000 second "variance" with ntp server, ntp shuts down, keeping the date/time "frozen" to the last snapshot saved.  Rebooting probably would have addressed the issue, but it was easy enough to right click in the Mate control center to restart ntp, and the date/time resolved in the blink of an eye.  Just clarifying the difference here in case a future sleuth reads this thread and the BSD behavior leads to a false conclusion.  Or maybe the BSD behavior sparks an idea for something ntp-related?  Issue MAY be related, and solution may be related; but BSD-VM is behaving differently than Arch, IMO.

Edited January 3 by Hedon James

[Hedon James]

Updated my EndeavourVM today.  Again, without incident.  Updated indicate a reboot was recommended, as core packages had changed.  So I did.  Rebooted, logged in, and EndeavourOS LXQT is looking at me, sexy as ever.  No further updates available.

 

May I assume this thread is "resolved" Ray?  I'm just following through on what I said I would, but I don't want to beat a dead horse either.  Instead of confirming my (numerous) successful updates and reboots, how about I just report when/if an issue appears?

[raymac46]

Yes I think we can say it's resolved unless I run into something else. Maybe I would be  wise to start a new thread if that happens.

[Hedon James]

12 hours ago, raymac46 said:

Yes I think we can say it's resolved unless I run into something else. Maybe I would be  wise to start a new thread if that happens.

Your call.  In the meantime, success=silence.  LOL!