After updating to the latest 66 version obarun does not boot in my system :(
When prompted to go into the emergency shell, a problem with tty12 is reported. If I choose to continue booting, I have the same error for tty2. When running 66-update from a single user environment in obarun or from chroot, Ι get:
66-update boot
66-update: info: save state of tree: boot
66-update: info: save service(s) list of tree: boot
66-update: fatal: unable to resolve source path of: tty12

66-update root
66-update: info: save state of tree: root
66-update: info: save service(s) list of tree: root
66-update: fatal: unable to resolve source path of: tty@ tty2
I can probably remove the trees and rebuild them, but I would like a solution that does not involve such a step. I have made no modifications to the frontend files or trees.
Classic diagnosis instructions are:
1 edit /etc/66/init.conf switch verbocity from 0 to 4 (or is it 3)
2 reboot as possible and try to extract /run/66/log/0/current
pastebin or enclose here in 
code /code  brackets


Somehow I think that boot-66serv wasn't updated correctly and/or an older definition of tty12 is harboring in there.
please post the output of 
# 66-update -d -v4 boot
Always use high level of verbosity for every tools when you want to debug and -d option at the first try, this will test if the process go well before changing anything on your system and give you the ability the downgrade the 66 package if something go wrong.(see 66-update documentation)
Also, be aware of this: https://web.obarun.org/index.php?id=126
by the ways of too many fingers on one key, is this a typo?:
To resolve this trouble, just create the /etc/66s/service directory (with root privilegies)
66s ??? If it was 66s/ervice it would have been more obvious :)
66-update -d -v4
66-update(src/66/66-update.c: main: 271): info: dry run do: save state of tree: boot-user
66-update(src/66/66-update.c: main: 280): tracing: dry run do: tree: boot-user is marked enabled
66-update(src/66/66-update.c: tree_allowed: 119): tracing: dry run do: allowed user(s) for tree: boot-user are: root
66-update(src/66/66-update.c: main: 287): info: dry run do: save service(s) list of tree: boot-user
66-update(src/66/66-update.c: tree_contents: 144): tracing: dry run do: tree: boot-user contain service: setenv-mobinmob
66-update(src/lib66/resolve.c: ss_resolve_src: 182): warning: unable to open : /etc/66/service/: No such file or directory
66-update(src/lib66/resolve.c: ss_resolve_src_path: 133): warning: unable to parse source directory: /etc/66/service/: No such file or directory
66-update(src/66/66-update.c: tree_contents: 146): fatal: unable to resolve source path of: setenv-mobinmob
After creating /etc/66/service and running 66-update everything seems ok. Let' s reboot :P
Unfortunately I get the same errors on reboot (the above was done in a chroot from my void installation).
I get the prompt for an emergency shell after the following:
66-init: unable to resolve dependencies of: tty12: Success
If I choose to press CTRL+D to continue the system stops with:
sulogin: cannot read /dev/tty1: Operation not permitted
mobinmob wrote
66-update -d -v4
66-update(src/66/66-update.c: main: 271): info: dry run do: save state of tree: boot-user
66-update(src/66/66-update.c: main: 280): tracing: dry run do: tree: boot-user is marked enabled
66-update(src/66/66-update.c: tree_allowed: 119): tracing: dry run do: allowed user(s) for tree: boot-user are: root
66-update(src/66/66-update.c: main: 287): info: dry run do: save service(s) list of tree: boot-user
66-update(src/66/66-update.c: tree_contents: 144): tracing: dry run do: tree: boot-user contain service: setenv-mobinmob
66-update(src/lib66/resolve.c: ss_resolve_src: 182): warning: unable to open : /etc/66/service/: No such file or directory
66-update(src/lib66/resolve.c: ss_resolve_src_path: 133): warning: unable to parse source directory: /etc/66/service/: No such file or directory
66-update(src/66/66-update.c: tree_contents: 146): fatal: unable to resolve source path of: setenv-mobinmob
After creating /etc/66/service and running 66-update everything seems ok. Let' s reboot :P
did you made a real update before rebooting? 
# 66-update -v4
-d -> make a dry-run meaning check if all is ok before processing
without -d -> really update your trees
All this is due to this one time transition from the old to the new. If you were to remove the trees and remake them manually I don't think there will be an issue. In one of my tests lately I reverted upgrades to the previous edition of 66 that had 66-update and run it, it worked. It works back and forth.
eric wrote
did you made a real update before rebooting? 
# 66-update -v4
-d -> make a dry-run meaning check if all is ok before processing
without -d -> really update your trees
Ooops :)
I forgot to actually do the update, you are right. After 
# 66-update -v4
my obarun installation boots again.
Thank you eric!
There seems to be a problem with starting xfce from sddm, but that is unrelated - jwm starts fine.
Does it make sense to run 66-update automatically as a post-install script of either 66 or boot-66serv in your opinion?
fungalnet wroteAll this is due to this one time transition from the old to the new. If you were to remove the trees and remake them manually I don't think there will be an issue. In one of my tests lately I reverted upgrades to the previous edition of 66 that had 66-update and run it, it worked. It works back and forth.
It seems that 66-update works as intended, but I will keep that in mind, thanx ;)
Does it make sense to run 66-update automatically as a post-install script of either 66 or boot-66serv in your opinion?
Not really because not every 66 upgrade needs the use of 66-update. 66-update is here to help you to reconfigure your tree and the configuration inner file used by all 66 tools when this inner format is changing or when s6-rc format changes. These changes should be rare and i will warn user if the use of 66-update is needed.
Please make a difference between 66 tools and boot-66serv. 66-update take care about 66 tools inner format change not service changes. Service changes as nothing to do with the heart of 66 tools. To apply a service change just use classic tool like 66-{enable,start,stop,..}
The 1 question I have for needlessly adding a 66-update hook to updating would be who is going to run 66-update for the user. In a way it sounds like a "user friendly" policy violation to me.
fungalnet wroteThe 1 question I have for needlessly adding a 66-update hook to updating would be who is going to run 66-update for the user. In a way it sounds like a "user friendly" policy violation to me.
There is obviously a problem there. The boot tree is maintained by the distro, it is essentially distro policy. It should always result on a working system with a tty operational. If an 66 package update changes the internal format in a way it follows that it should update the boot tree - and the root tree perhaps, or at least notify the user to update somehow. Of course this my understanding, and it is not necessarily the best fit for obarun or any other distribution. 66 is very flexible, as it dictates very few, if any, policy decisions. That is a good thing (tm). It also means that different implementations/packaging will differ in some aspects. The above is not a jab at obarun - I should have read the announcement ;)

@ eric: Thank you, once again!


Edit: pelhaps -> perhaps
Are you saying it would have been bundled up as one pkg in other distros and just be replaced by an update? As far as I understand it for amd64 architecture and for linux as a kernel it is fixed, but still allows someone not on amd64 or not using linux to create their own.
Pluralism has its drawbacks, it requires involvement into the decision making, :)

Do you have any ideas on how else it can be done? I think your concerns are revolving around boot-66serv packaging, are they?
fungalnet wroteAre you saying it would have been bundled up as one pkg in other distros and just be replaced by an update?
A distro can choose to have different directories for frontend files, different trees or a single tree, to tune the packaging, to configure certain things on install/update/reboot etc... If a distro/maintainer is responsible for these policy decisions, they should be responsible for keeping them working, by running code or involving the user in a fix. User trees outside the distro/maintainer-provided are a responsibility of the user ;)
fungalnet wrote Do you have any ideas on how else it can be done? I think your concerns are revolving around boot-66serv packaging, are they?
Indeed they do ;) Ι am going to test them and determine what works.
I think one way to make this a runit similar system would be to add all desired services to a single tree, boot, and make boot-66serv part of 66-rc and create a user scandir for every user in the system by default. I think this is what debian would have done ;)
Oh, I am not trying to recreate runit with 66, that will be really weird and a slightly bizarre experiment. 66 provides excellent flexible mechanisms that are capable of supporting different policies effectively. That is no small feat :)
But did you try what I suggested? tty1 comes up blistering fast, but dhcpcd and other services failed. Maybe the delay between boot and root trees allows the time to work properly.
Proper service start ordering and/or readiness notification is a separate issue from having one or more trees.

Powered by Obarun