Guys, I like your project and wish you the best but I've hit a couple of issues that mean that I just can't really consider keeping going with this. You can check my history for the previous issues but here is the latest.

When I built the box that I currently have Obarun installed on, one of my aims was to run meshroom. I used it for a couple of other things in the meantime but tried to get to it tonight. Well, once I had git-cloned meshroom, it wanted me to run pip on the requirements. OK, pip is not installed. pacman installing pip seemed to be OK but when I attempted to run pip, I got a screen full of errors. I managed to remove some of them by manually updating various dependencies but soon hit one that was not obvious to resolve. Can I just update all dependencies? Not as far as I can tell. I read that Arch (which I believe Obarun is based on) only really does full system updates.

Well, I have an inkling where that is going to lead me. But let's give it a go anyway. One pacman -Syu later and package installs are scrolling up the screen quickly. I see something about manual intervention with 66-update which is quickly gone from my scroll-buffer but I think I managed to google that well enough and when all is done, I get to run 66-update -d and 66-update. OK.

So now I am back at my root prompt and maybe things are looking good. So I run pip and no errors, just the help screen. Then I run pip on the requirements file and get a bunch of connection errors. That's not good. My ssh session is still open so I still have network. But trying to ping a couple of domain names gives me system errors. Seems like whatever is supposed to be resolving is not working somehow. No problem, I just did a full system upgrade. Perhaps a reboot will fix things...

So nope. Now I get presented with a failure of tree boot and ctrl-d to continue (which doesn't work) or enter password (which also doesn't work).

I just wanted to install some software.

Here's the thing. I use my box and I'm a developer so I'm always going to be installing different shit. I can resolve software dependency issues no problem but I can't be having a whole box down just because I wanted to install some trivial piece of software. Fixing stuff that shouldn't be broken is not an efficient use of my time, especially when it breaks stuff not directly related. As a sysadmin, package managers were the bane of my life. When they work, they're convenient. When they don't work you're in dependency hell or stuck playing with boot media because you needed some trivial lib.

So in summary, the risks are just too high. I don't think this is you guys' fault but it's just an unacceptable way to be for me. And don't get me wrong, I've borked some boxes in my time but usually when you do it yourself, you have some rough idea of what needs fixing. When it's automated like this and especially with a system you're not familiar with, it's just dispiriting.

For comparison, hopefully without looking like I'm promoting it, my usual distribution is one which begins with S maintained by a guy with the initials PV. My main box has been up since 2012 with occasional upgrades. When I want to install software, I do and if it works, it works and if it doesn't, I fix it and I've never had to worry if it will boot after.

Apologies if this comes off as ranty. Like I say, I don't blame you, it seems to be an Arch issue. You're doing good work and we need to keep systemd at bay. I hope you can take this as constructive criticism and it will be more useful than if I just went away quietly.
Hi welcome and hopefully you can stay and struggle with "it" and not leave, but I am not trying to sell you obarun, I am trying to explain things, as far as I know (I am not a dev I am a user), not just for you but for others who may also end up here trying to fix a problem.

1st if it is python-pip you were talking about it is a "make dependency", which means it is needed while building the package, then can be removed even before installation, it is not functional from that point on.

Obarun can really be responsible for its own software on its own repositories, what comes from Arch (core extra community) is pure arch, and what comes from AUR is not really officially arch, just a space with slacker regulation where users of arch can upload their own packages.

Obarun is responsible for the init and service management/supervision s6 and 66. The rest is all arch, with the exception of some popular utilities and desktop stuff that have an unnecessary systemd dependency that can be directed elsewhere, either to s6, other linux utilities, or consolekit2.

What you are presenting with a meshroom problem is more of an AUR issue than arch, or even obarun.
You are describing some network problem without really any details?
Box being down? One of the things that s6 has that is unparallel to any other system tried is that once it is up and running it is next to impossible to kill unless its own shutdown routine has completed. The damn thing keeps coming back alive just like it just booted.
With systemd one should be surprised if it stays up long after an upgrade. Skarnet's own server only comes down after years to replace the kernel.

Now!

Do you need help in solving specific problems, even if they are AUR or Arch originating issues, open a specific thread (building meshroom, or solving wifi issue, or failing ssh server) and we can all try to help with the specific problem?
If not and this is a goodbye note ... then there is little need to speak of python-pip or anything else.

Note: When you use an AUR pkg Arch warns you, it is a risk you are willing to take. Even bad hackers willing to do harm have managed to upload pkgs on AUR, and are only taken down when reported and the bad code is located.
Building an AUR package with an AUR pkg as a MAKE dependency it is risk in the second or third power, meaning secret windows may come from a library that will not even exist in the active binary you use. It is running on ice that may be thin but still looks white to be running on ice that you can see fish swimming underneath very clearly. At least if you will do something like this use a container solution of some form so you can contain the damage away from the rest of your system and monitor the bubble for what is going in and out.


Frustration with a problem that can't be solved and sleepless nights is something we all suffer, (I am lethal when this happens, I actually have a wooden club and go out in the yard and break things :) otherwise we would use MSwin7 or Apple-iJuice or mUbundu.

PS Firefox-esr was kicked out of arch, so a total slob picked it up in AUR, retained the original pkgbuild file having language specific pkgs i-18-"$language" depending on firefox-esr that no longer existed but was replaced with -firefox-esr-bin, then all language pkgs were copies of the same, meaning that unless you edited the specific languages you wanted you installed all 195 of them. So time passed (months???) and someone else made a separate package for the same exact browser and called it firefox-esr to satisfy dependencies of the lang.packs. It is a zoo!
This is not some obscure fork of a browser but -esr, the most widely accepted safer alternative to anything.
Hi, yes, to be clear, python-pip was required by the build process of meshroom. Unfortunately, when I installed python-pip, some of its dependencies were outdated, giving errors. The only way to update these dependencies properly was (apparently) to perform a full-system update which left the system in an unbootable state.

I'm not sure if meshroom is available as an AUR package but I was just going to compile it from scratch and had cloned it from github.

Unfortunately, I couldn't supply much more information on the network issue because literally the only error it gave me when I tried to ping anything was "system error". However, network functionality itself seemed to be fine so this looked to be a DNS issue. The tools I am used to using for diagnosing these things are unfortunately not in the default Obarun install. I am fairly sure that I have seen this before and it was fixed by a reboot (and I'm not afraid of diagnosing that kind of issue) but now here I am, without even a command prompt...

Unfortunately, the system I have this on seems to be having an issue with coming up after a full power-down which makes this tricky to play with (and is no doubt playing into my frustrations). I'm hoping for an upgrade once the new AMD CPUs start being in stock so I may consider giving it a try again with a fresh install then since that was a fairly old install and maybe things are better.
If you try to update your 66 ecosystem jumping e.g from 0.2.0.0 to 0.4.0.1 without passing through the other version, you will get huge troubles. The 66 development is really quick and bring a lot of changes at each release. Compatibility with version is really hard to keep cause of some bad code design choice made at the start of the project. However, we are almost done with this kind of changes.
I'm conscious of how it can be difficult for user to follow the development but i search to provide a stable and rock solid software. I don't want to deal with bad decision for 10 years.

Anyway, if you trouble come form the boot and the 66-update program didn't did the tricks correctly for you, you can rebuild your tree manually from the scratch.
Hey Richy,

sorry to hear that. It has happened to all of us indeed. You say that "The tools I am used to using for diagnosing these things are unfortunately not in the default Obarun install." Well it seems they're actually not on the Arch repos to begin with if you have to pull them from AUR or compile them ;)

So that's a big one to begin with. I must say, if you check that a given AUR package X has some sort of repo, with active or semi-active management, people commenting on it and committing it's usually rather safe to install.
There's always this thing with the AUR that even if you find a package Y which is a very famous product of company Z, you need to be aware that in most cases it is actually not at all managed by that company in question. On the contrary, it is only there because some person felt the need to bring it to Arch. Like Meshroom!

I think it's actually cool that you managed to be conscious in this whole mess and managed to upgrade 66 basically on the fly, while being bothered by this whole process. I've had my fair share with 66 not wanting to boot properly, but that's usually after me playing around with configs and services, and often times it's rather easily fixed.

In earlier 66 versions we had failing services block the whole service chain and very little useful verbose output on that. Eric and the team are doing their best to make this gold and I second his view point of not wanting to maintain code that just didn't work like expected when now after several months of being live they can track how and where to improve. I think that's just great. Also there are few times that the boot tree itself gets sort of corrupted and you don't even get into the tty12 terminal which is started early on.

This may sound like a personalized advertisement (and maybe it is hahaha) but from my personal experience no one Linux distro will ever be able to not break. I've broken them all. Like seriously,...all of them...
If you upgrade your rig in the future and wanna try again, go fresh. Make sure everything works. Install some stuff from Arch repos (pacman, not AUR!) and go little by little. Reboot a few times. Check that everything's working as expected and then install more unique things.

By the way,...as a graphic designer and frontend developer "Meshroom is a free, open-source 3D Reconstruction Software based on the
AliceVision framework." doesn't sound like a trivial piece of software to me ;)))

Wish you the best of luck and greetings from Mexico!



P.S.: I had to add this one from the Arch forums hahahaha, sorry but this is so Linux,...
Sorry if I missed something, but what was the fix to this? I uninstalled xorg-fonts-alias and installed xorg-fonts-alias-100dpi, and now xorg won't start.

  • [deleted]

  • Post #6
Hi Richy

That’s why when I'm packaging, building, installing and executing the software, everything is done inside a Virtual Machine and only after a complete inspection of the result, build log included, I use it on my main machine.
Yeah, meshroom does seem like a big bit of software. I do a fair bit of 3D printing and I'd like to be able to do some photogrametry. Unfortunately, it also requires access to Nvidia hardware so VM stuff may not be applicable. Not that the hardware I'm using is powerful enough to be hosting VMs anyway. I really need new hardware but I'm waiting on the 3100 or 3300X ryzen CPUs to become available and stock is low at the moment.

It sounds like the main issue is the change in init system is the main hurdle so I may go for a reinstall with a later version. Though it seems like that "only full upgrades" thing is not very compatible with major changes that can break things. I've not had much faith in package managers since a small change in Debian left me with an unbootable corporate mailserver with 6000+ users one fine day.

How would I go about rebuilding my tree from scratch? Currently, the error I have on screen is about "unable to initiate earlier service of tree:boot"
How would I go about rebuilding my tree from scratch? Currently, the error I have on screen is about "unable to initiate earlier service of tree:boot"
The wiki has an introduction to 66 entry, and also has an entry about dbus and user tree services (https://wiki.obarun.org/doku.php?id=dbus_and_dm). Those two without reading anything else should have plenty of practical information on how to delete all current trees, make new ones, and enable services in them.

Basically to boot and have a fully functional console you need:
root shell or use sudo in front:
1 # 66-intree -zg root (record what services you have enabled on root tree)
2 # 66-tree -R boot (remove boot tree)
3 # 66-tree -R root (remove root tree)
4 # 66-intree -zg (will show you if you have any other root level trees)
if you do, record their services and repeate the removal command for each of these trees.
5 # 66-intree -zg (you should have no trees now)
6 # 66-tree -n boot (create a (n)ew boot tree /etc/66/init.conf defines to the init which tree to run, you can change the name there and call it kukuruku if you don't like the word boot)
7 # 66-enable -t boot boot (enable on (t)ree boot the service bundle named boot - the contents of boot-66serv)
8 # 66-tree -ncE root (create root tree, (n)ew, (c)urrent, (E)nabled
9 # 66-enable -t root tty@ tty1 (this will give you tty1 console to log in, nothing else running ... feel free to add other things, dhcpcd, tty@ tty{2,3,4,5} connmand, cupsd, sshd, ntpd, sddm, ......

After 7 you can reboot and you will have to switch to tty12 (Ctrl-Sift-F12) the next steps are optional :)

For 66 to run user services you first need a user level scandir created and active, this is what the https://wiki.obarun.org/doku.php?id=dbus_and_dm wiki explains. I never use it myself but I've done for many others' computers and I have yet to deal with a problem with it. Most of my victims don't know the difference between what they are using, ubuntu, or ms-W7 ... they just enter their name and pw and it works.

What you said about Debian with systemd being paralyzed is why most of us are here. Because systemd is fine for dummies when it works, when it fails it is a maze of dynamic events that hardly anyone can diagnose anymore. If you had hired red-hat to provide support and maintenance I assure you that you wouldn't have problems with upgrades :D They are the best in the business (mafia, nSA, etc).
Richy_T wroteI've not had much faith in package managers since a small change in Debian left me with an unbootable corporate mailserver with 6000+ users one fine day.
Ouch :C
That hurts from just reading it, don't want to imagine the pain you went through on that one...
I suppose you are aware that Obarun is a layer on top of Arch and with that a rolling distro with lots of rather bleeding-edge versioning.
That being said, apparently things may break in any moment, depending on your software installed, the development process of their dependencies etc. especially when coming back and doing a pacman -Syu after several months...chance you get fu***d on that are like playing roulette,...

Still so I have never had a Linux before empowering me in this way, giving me the opportunity to actually repair my boot-up process rather easily. Because if anything breaks with s6/66 it's really most often only some minor misconfiguration which can be remedied rather quick from tty12. Even if that's not the case then Eric can always swiftly pinpoint the issue and assist.

I personally wouldn't buy any hardware until after markets got back to normal (and they will...if I like it or not). It's insane what you can get, even for a budget, today. If it wasn't for my anti-consumerism attitude and several old storage disks I'd just build myself a miniITX AMD socket with one of the upcoming APUs, a TB of decent NVMe and put it in one of the AliExpress chinese macMini case clones. Ten times smaller and more powerful than all the PCs and Laptops I've ever owned together...(and I'm currently using a Thermaltake Core V1 hahaha)
I personally prefer to invest in plants though XD
His troubles was solved at # obarun channel.
17 days later
Or so we'd hoped.

I'm now back to booting thanks to a lot of good help from whoever user Obarun is on the Obarun channel. I have that chat saved and I'm planning on reformatting and posting in case it might help someone else. However...

Mypaint was throwing me some errors related to gtk. 
(mypaint:9364): GLib-GIO-ERROR **: 05:11:32.297: Settings schema 'org.gtk.Settings.FileChooser' does not contain a key named 'show-type-column'
Pensively, figuring this was something that hadn't got updated properly, I ran pacman -Syu but the upshot is:
:: Proceed with installation? [Y/n]
:: Retrieving packages...
error: failed retrieving file 'poppler-glib-0.90.1-1-x86_64.pkg.tar.zst' from archlinux.nautile.nc : The requested URL returned error: 403
error: failed retrieving file 'poppler-glib-0.90.1-1-x86_64.pkg.tar.zst' from mirror.lagoon.nc : Failed to connect to mirror.lagoon.nc port 80: Connection timed out
warning: failed to retrieve some files
error: failed retrieving file 'xorg-fonts-alias-100dpi-1.0.3-5-any.pkg.tar.zst' from archlinux.nautile.nc : The requested URL returned error: 403
error: failed retrieving file 'xorg-fonts-alias-100dpi-1.0.3-5-any.pkg.tar.zst' from mirror.lagoon.nc : Failed to connect to mirror.lagoon.nc port 80: Connection timed out
warning: failed to retrieve some files
error: failed to commit transaction (download library error)
Errors occurred, no packages were upgraded.
It appears that this probably isn't an Obarun issue though so I'll wait a while and see if it gets fixed.

Edit2: I added a different mirror to the mirrorlist and the update proceeded well. Perhaps the defaults are not particularly good mirrors. The good news is that I'm not crashing now. Though there are a few broken icons but at least they're not showstoppers.

Powered by Obarun