The next
openrc-0.35.5-12 or
runit-2.1.2-6 update will require manual intervention.
This procedure will be necessary in [gremlins] first, later in [system].
Updated instructions:
Runit:Remove runlevel symlinks you eventually set manually.
sudo rm /etc/runit/runsvdir/default/{dbus,elogind}Remove sysv symlinks.
sudo rm /usr/bin/{init,poweroff,shutdown,halt,reboot}sudo pacman -Syu artix-sysvcompat
Openrc:Remove runlevel symlinks you eventually set manually.
check elogind:
sudo rc-update del elogind boot
check dbus:
sudo rc-update del dbus default
Then proceed with system update:
sudo pacman -Syu artix-sysvcompat
Please do not attempt the update in pamac or octopi.
Additional note for runit users:
Since we finally provided a unified sysvinit-compatible binary, please delete all of these symlinks before upgrading to runit-artix-20180414-9.
# rm /usr/bin/init /usr/bin/poweroff /usr/bin/shutdown /usr/bin/halt /usr/bin/reboot
Upgraded to gremlins using packages-gremlins.cfg then upgraded as above on a reboot got root mounted but sbin/init does not exist. Checked with vi editor and it does exist so not sure what is wrong?
Start your system by adding to kernel at grub:
init=/usr/bin/openrc-init
boot up
sudo pacman -Syu openrc
pacman output:
:: Running post-transaction hooks...
(...)
( 4/12) Activating init switching system...
==> Activated openrc-init.
Reboot.
I don't get it...
# pacman -Syu artix-sysvcompat
:: Synchronizing package databases...
/var/lib/pacman/sync/gremlins 100%[=================================================>] 25.78K --.-KB/s in 0.1s
/var/lib/pacman/sync/system.d 100%[=================================================>] 191.33K 1.12MB/s in 0.2s
/var/lib/pacman/sync/world.db 100%[=================================================>] 659.96K 2.31MB/s in 0.3s
/var/lib/pacman/sync/galaxy-g 100%[=================================================>] 9.25K --.-KB/s in 0s
/var/lib/pacman/sync/galaxy.d 100%[=================================================>] 143.12K 858KB/s in 0.2s
/var/lib/pacman/sync/lib32-gr 100%[=================================================>] 76 --.-KB/s in 0s
/var/lib/pacman/sync/lib32.db 100%[=================================================>] 11.37K --.-KB/s in 0s
/var/lib/pacman/sync/extra.db 100%[=================================================>] 1.56M 1.96MB/s in 0.8s
/var/lib/pacman/sync/communit 100%[=================================================>] 4.32M 3.82MB/s in 1.1s
/var/lib/pacman/sync/repo-ck. 100%[=================================================>] 34.84K --.-KB/s in 0.06s
error: target not found: artix-sysvcompat
Mirrorlist:
##
## Artix Linux repository mirrorlist
## Generated on 2017-10-21
##
# Artix mirrors
Server = http://artix.wheaton.edu/repos/$repo/os/$arch/
Server = https://www.uex.dk/repos/artix/repos/$repo/os/$arch
Server = https://mirrors.dotsrc.org/artix-linux/repos/$repo/os/$arch
Server = http://mirror1.artixlinux.org/repos/$repo/os/$arch
Server = http://mirror.strits.dk/artix-linux/repos/$repo/os/$arch
artix-sysvcompat is not in stable yet only in gremlins.
He is on Gremlins.
Some mirrors haven't caught up to the primary and depending on the order of the mirrors and/or proximity to them you may have a different picture than what we had. Wait a little and it will show up on one of your -Sy attempts.
This instruction was for OpenRC, why?
Somehow I have elogind and libelogind that are newer than system, must have come from gremlins and then vanished and never made it to system. Should I downgrade to those in stable?
system/elogind 235.4-2 (base) [installed: 236.1-1]
The systemd project's logind, extracted to a standalone package
system/elogind-runit 20180226-1 (runit-system) [installed]
runit service scripts for elogind
system/libelogind 235.4-2 (base-devel) [installed: 236.1-1]
Gremlins version has been bumped up to "artix-sysvcompat-0.3.7-6", perhaps that has a fix for the init issue with runit?
I cannot verify as I use openrc.
Best regards.
The fix is in
goblins gremlins currently. Brave runit users can get it there.
Carlossalvatore - cowabunga, that mirror list is totally outdated, the mirrors on it have packages way out of date, some of them don't exist any more. You need to add the new mirrors at the top manually.
[note I use openrc, not runit]
At least for me, it seems like elogind and dbus had been manually added to rc-update, so the upgrade barfed on the file conflict when it tried to add them. Manual removal seemed to be the easiest way around it. I have no idea if that is the case for runit. I'd say try the upgrade, and see if it complains about the conflict.
I also ended up with elogind and libelogind ahead of system, and I did downgrade, although I didn't notice any problem related to that (before or after the upgrade.)
One thing that might help avoid problems for some openrc users, is a more explicit note they do need to add artix-sysvcompat. I didn't do that at first, and then noticed I didn't have halt or reboot. It IS in the first post - but I skipped it as I didn't already have it, and didn't see why I would need it. Yes - I did figure it out later...
Hi, dude!
Which one is the good one?
Never mind. I've changed to these ones and it worked:
Server = https://mirror.clarkson.edu/artix-linux/repos/$repo/os/$arch
Server = https://ftp.sh.cvut.cz/artix-linux/$repo/os/$arch
Server = http://artix.wheaton.edu/repos/$repo/os/$arch
Server = http://mirror.strits.dk/artix-linux/repos/$repo/os/$arch
Server = https://mirrors.dotsrc.org/artix-linux/repos/$repo/os/$arch
Server = https://www.uex.dk/public/artix/$repo/os/$arch
Server = http://mirror1.artixlinux.org/repos/$repo/os/$arch
I've also updated the wiki with this information.
Alright, updated instructions (https://forum.artixlinux.org/index.php/topic,520.msg4084.html#msg4084) for updates arriving in stable [system].
That's all. :)
I had the dotsrc mirror at the top at first as it was fast in my location, but I noticed I didn't have the latest mirror list that people were talking about on here. So I switched it to the bottom and added this to the top:
https://ftp.cc.uoc.gr/mirrors/linux/artixlinux/$repo/os/$arch
because it was added very recently to the list so I thought it must be up to date. It was slower for my location but brought in many updates. I tried putting the dotsrc one back at the top later but I just got lots of "newer than..." warnings when I did pacman -Syu. Looking manually by browser at the two repos:
https://mirrors.dotsrc.org/artix-linux/repos/system/os/x86_64/
artix-mirrorlist-20171021-1-any.pkg.tar.xz 2152 21-Oct-2017 09:58
https://ftp.cc.uoc.gr/mirrors/linux/artixlinux/system/os/x86_64/
artix-mirrorlist-20180424-1-any.pkg.tar.xz 25-Apr-2018 00:24 2192
So at least one mirror is not at all up to date, perhaps others need updating too?
I tried following the steps for openrc, but something went wrong and now I can't boot my system. I tried adding the "init=/usr/bin/openrc-init" at the GRUB command line, but that did no good. I just got a message saying:
Root device mounted successfully, but /sbin/init does not exist. Bailing out, you are on your own. Good luck.
sh: can't access tty; job control turned off
Is there any way of repairing this?
This means that your update was probably partial and you're missing /sbin/init (which belongs to openrc). A live linux CD or USB stick would be your best option.
When you are able to mount the system look at your / root directory if /bin /sbin /lib /lib64 links exist.
# mount /dev/sd** /mnt
# ls -al /mnt
# artools-chroot /mnt
Are you running on gremlins and your mirrorlist is not current or you synched from that one mirror that has not updated?
Did you install a version of artix-sysvcompat on your last upgrade? What is the file version?
# pacman -Qs artix-sysvcompat
the mirrors from the "tutorial" on the website didn't have artix-sysvcompat available to me. i had to use:
Server = http://artix.wheaton.edu/repos/$repo/os/$arch
also... there was no announcement when the change would hit system, which indeed it already did (yesterday?). i ALMOST rebooted my system without checking for special instructions. only when i realized i couldn't use reboot any more (thank god) i started to poke around and found the outdated info on the website and forum.
you guys, i really appreciate all you are doing... but if this continues the way it does... i'll probably switch to another distro. just wanted to let you know in case others feel the same way so that you get a feeling about the general "health" of your user base.
you keep introducing possible system breaking changes without much warning. the constant dependency issues from migrating away from arch packages are just another issue that falls into that category. if you want to keep this distro that way without ever getting it to a stable place you've got all my support and best wishes to do so. just let us know if you are planning to stay on the experimental route because that's just not what i was looking for when i wanted to stay away from systemd.
We have introdued an init agnostic base group.
This make it possible to keep artix open for eventual s6 adoption, or runit and openrc in combination.
We certainly have no mean to email each and every user, and time is spread thin.
Post #13 of this thread contains the announcement, the stable servers took a few hours to sink, so late yesterday.
I've not had time to try using a live DVD to fix the system. I do, however, agree 100% with eNTi's comments about getting to a "stable place." I want to see a systemd-free version of Arch linux, but I need stability as well. If Artix is going to be a place for developers to tinker with alternative init software instead of getting to one or more stable versions of systemd-free Arch, then I certainly need to find an alternative distro.
We recently lost our primary mirror unexpectedly and relatively suddenly, lets not mix several issues here.
As a matter of fact, the updates arrived in stable and they do work, granted you followed the announcement, and you have had updated your mirrorlist(pacnew).
Troubles with a flawed update has likely its root cause in the mirror being outdated.
yeah... the 3 mirrors that were in the announcement were outdated and the one i posted worked. SGOrava pointed me in the right direction. these things happen i suppose. especially with the limited man power behind the project.
what i don't understand and what isn't really necessary is the fact that users (like me) update their system and it breaks without warning. i might expect that from an experimental distribution and therefor don't ever update before i check the forums and the website.
however i was under the impression that artix [system] is generally regarded as safe (stable). if i got the wrong impression of what artix is supposed to be (a STABLE and systemd-free archlinux fork) please tell us so that we either pay closer attention to updates or look for an alternative.
it's totally ok if you want the distro to be a playground i just don't want to keep false hopes. so far artix is all i ever wanted from a distro sans the system breakages.
I simply don't get the complaining here.
System is stable, the update works as intended, but there is no way to pull in a new member of base group automatically.
That is all there is to it, not different to what arch does in their announcements if user intervention is required on update.
Stable and everything working for me on the following machines:
Lenovo Yoga 2 Pro - (i7, 8GB RAM, 500GB mSATA, Intel Graphics, Touch Screen, Convertable)
Dell Precision 7510 - (Xeon Proc, 64GB RAM, Nvidia + Intel (using Nvidia DKMS, 1x1TB SATA SSD, 1x1TB m2))
MSI GS40 Phantom - (i7, 32BG RAM, Nvidia + Intel (using Nvidia DKSM, 1x1TB m2))
Microsoft Surface 2 Pro - (i7, 8GB RAM, Intel Graphics, Touch Screen, 1x1TB (whatever drive is in it))
We all work though everything together. Very few problems go unanswered even when they have nothing to do with Artix (such as AUR packages) and Artoo is pretty good at updating us within a few hours of any bugs. It's not perfect, but the system works for us and I'm happy to help out when I can.
yesterday my system would have been broken in two if it weren't for the coincidence that /bin/reboot was removed (temporarily). i AM on [system] and you can't state that system is STABLE if it breaks on a random update and you also can't say that the update works(ed) as intended if it had broken my system that way yesterday. yesterday when the update went life i went to the homepage (again due to the coincidence that /bin/reboot was gone) and followed the steps in the announcement and still weren't able to get the update running because the mirrors weren't updated yet.
that are just facts. there's no judgment in there. i'm telling you what my problems are. you can't tell me that those are not problems or that i'm not having them or that those are not of your doing.
this is actual judgment: if you are getting all defensive and keep saying everything works as intended ... well then i'm sorry i ever said anything. if it's your goal to run your distro this way... so be it. i'll just not bother with artix any more because i'm not interested your politics or experiments. all i want is a stable system without systemd. if you can't have any critique whatsoever ... well then good look i suppose.
It could be a good idea have a web feed with the announcements, in this way people can aggregate to the feed and see if it is going to be a tough update.
What are your facts, please provide log files etc.
Hysteria in a rant will not fix any issue without providing more detail.
I don't think anyone is saying works as intended. I'm just saying we're a small community and have already developed habits such as waiting a few days on updates and checking the forums before we update to see if Artoo or Fungalnet have posted any bugs before we actually update. For example, I have a separate VM that is a mirror of my host that I do all updates on before I do my host (excluding the Nvidia DKMS drivers obviously) just in case something unforseen sneaks past the devs. We'll get there.
Stable is just as stable as Arch is. The last actual issue was when icu was accidentally pushed too soon and broke pacman, but that was many many months ago. The init stuff is naturally more tricky business (hence why it requires some manual intervention), but I like the idea of providing a common base for all the possible init systems to work off of.
After using the Artix live DVD to chroot my system, I was (after a great deal of time and effort) able to get my system working again. I copied the /sbin/init directory from the live disk to my hard drive. After that, I tried to reinstall openrc via pacman, but got errors about conflicting files with runit, which was never installed on my system. I finally had to force the openrc reinstall and ran a full system update. After doing that, I was able to boot from the hard drive, but I wasn't able to get to the graphical login. The startx command gave error messages that no screen was found. That may have come from one of the updates when I did the full update. I tried to boot off of the basic kernel instead of the lts one, and it worked.
While I'm happy to have my system working again, I do think that you guys need to decide what your goal is with Artix. Do you want it to be a user-friendly Arch-based system without systemd, or an experimental distro for trying different systemd alternatives? I understand that your resources are limited; that's why I think you ought to prioritize your efforts. If you want to be the user-friendly Arch alternative without systemd, you need to pick one init application and focus your effort into making that the stable flagship of your offerings. Once that's done, you can introduce other init approaches. If you want to be an experimental disto, then state that up front so that less savvy users won't waste their time with it.
I'd say Artix is about as user friendly as Arch which is probably equal to "not very." People should know their way around a linux system and not be afraid of a command line. I've said it before, but I'm honestly surprised there's even a graphical installer in the first place (personally, I would rather just do it in cli). Not that the distro is super hard or anything, stuff like Gentoo is way more time consuming, but they're definitely not aiming for a seamless, ubuntu-like experience.
We, as the artix team, never ever stated that we are aiming to be yet another manjaro, we don't, and we said this from the beginning.
If you expect a user friendly distro, that is actually your misconception.
"user freindly" depends on the definition. If you expect a click and point approach, no terminal usage, , then you expect wrong and windows is the OS you really want.
my 2c is that Artix has been very very stable, despite of the warnings it is not for newbies. I'll have to give the "team" this.
Things seem to have coincided, such as runit development, the primary mirror being exchanged for a new one, new mirrors being added, mirrors taking to long to resynchronize and some of them losing the ability to, and a suspected rush to get new isos out "with" runit as well as with OpenRC. I suspect with all the mirror turmoil the past 2 weeks installing with January's isos you are lost as how to get any upgrades, where to find the new mirrors that work, etc.
The problem is not whether facing temporary unforseen issues is adequately confronted but the "trend" of the team working silently in the backroom, maybe for 36straight with out breaks, but not adequately alarming users before things fall apart. Being locked out of your system without a word for days is not nice, no matter who you are. Not knowing what may have caused it and get no clues is a problem. Upgrading something that came through a repository and being locked and be blamed after the fact as your fault for upgrading, is a problem.
I suspect due to my own ordeal that your conflicts of openrc with runit came from artix-sysvcompat and some rogue version of it lying around in some repository that didn't sync on time with the rest to prevent you from installing it.
That is what makes
@artoo's repeated unfriendly advise totally uncalled for. Which is a contradiction to what I am saying. Some members of the team may be the gods of coding but not very good in communicating what they have done to users. I don't know where the balance is.
@artoo's remarks are definitely NOT what I call being alarmed of changes ahead of them appearing in repositories.
Is there a plan/schedule to update the installation media accordingly?
I mean no offense, but the "base" medium (so called "rolling") has not been updated for more than half a year. Considering all the discussed changes, and also issues that this particular medium brings (missing the "nobody" user, missing the SSH server etc.), I trust I am not the only one who would appreciate a bit of an update here. Sure, the LXQT was updated lately, and would most probably be appreciated by newbies and the likes. But considering the many times spoken fact that this distribution is not for total newbies (again, no offense), I am more than happy with a minimalist wizard-less installation media (KISS?), as long as it is working and somewhat up to date.
Thanks and cheers!
Yes, new isos are going to be generated once we have the new runit and openrc stuff ready.
What also was a release blocker, new toolchain, now in stable, but new gcc8 already in goblins.
thank you for whoever added that on the main page!
I did my usual update and rebooted without thinking and OHNOES!
lesson learned ;D
>always read the news and new posts in announcements kids
[edit]
and I forgot to ask my question, which is what was the cause/reasoning for this upgrade going a bit crazy? I use openrc, so my guess it had something to do with runit support?
Yes it does, the change will allow easier switch between openrc and runit, as well as future init systems.
This means the network config files and the mariadb files need to be removed?
[ruben@flatbush ~]$ ls -al /etc/init.d/|grep '^.*->'
lrwxrwxrwx 1 root root 18 Apr 27 21:29 agetty.tty1 -> /etc/init.d/agetty
lrwxrwxrwx 1 root root 18 Apr 27 21:29 agetty.tty2 -> /etc/init.d/agetty
lrwxrwxrwx 1 root root 18 Apr 27 21:29 agetty.tty3 -> /etc/init.d/agetty
lrwxrwxrwx 1 root root 18 Apr 27 21:29 agetty.tty4 -> /etc/init.d/agetty
lrwxrwxrwx 1 root root 18 Apr 27 21:29 agetty.tty5 -> /etc/init.d/agetty
lrwxrwxrwx 1 root root 18 Apr 27 21:29 agetty.tty6 -> /etc/init.d/agetty
lrwxrwxrwx 1 root root 31 Apr 27 21:29 functions.sh -> /usr/lib/openrc/sh/functions.sh
lrwxrwxrwx 1 root root 18 Dec 1 12:41 net.eno1 -> /etc/init.d/net.lo
[ruben@flatbush ~]$
No, he was referring to the 2 services that are in the original post. Only those 2 services need to be deleted from the runlevel.
I'm sorry to hear about it now, I'm a developer and I do not have time to deal with OS issues. the procedure indicated did not work for me, I go back to openSuse again. Good luck and thank you
edit:
I'm going to continue for a while here, I appreciate your effort
Depending on the dev language you use, you are much better settled with suse, because they have debug symbols and devel packages, and it is not a rolling release afaik.
Since you are a developer, you will understand that development decision have to be made and implemented.
Artix is less than a year old, started out in two more or less technically ugly community efforts on arch and manjaro to replace systemd.
It had reached the limits of what is doable technically, hence we started a distro, building all artix repository packages ourselves.
We started off with the rock solid, still developed openrc, the default on gentoo.
However, in recent time, other very promising and nice service managers and init systems have been developed, artix has been evaluating runit, by now well working.
Without going into further detail, we may decide that runit becomes the default on artix, while openrc would still be supported and running stable as usual. We will decide for what we evaluated to be the best software for service management and initializing the system, and this major update laid the foundation to use whatever we evaluated to become default, without such potential trouble experienced by users. It simply had to be done to implement a neutral init with interface package for service managers.
would you expand on this a bit? what do you (as artix developers) see as some benefits of runit over openrc? I'm just curious, artix (and previous arch) has been the perfect balance for me between utility (rarely breaks for me) vs hobbyist linux usage (I pretty much went from linux-from-scratch to arch because pacman), so i appreciate the distro as it is. I always want to know the why's of developers choosing one solution vs another though.
for openrc there is no listed services and the runit ones are in a runit specific location
So, follwoing my nose... I see
flatbush ~]# sudo ls -al /etc/runlevels/
total 20
drwxr-xr-x 7 root root 81 Jun 8 2016 .
drwxr-xr-x 125 root root 8192 May 6 00:02 ..
drwxr-xr-x 2 root root 4096 May 4 08:29 boot
drwxr-xr-x 2 root root 4096 May 6 01:30 default
drwxr-xr-x 2 root root 19 May 4 08:29 nonetwork
drwxr-xr-x 2 root root 56 May 4 08:29 shutdown
drwxr-xr-x 2 root root 141 May 4 08:29 sysinit
[flatbush ~]# sudo ls -al /etc/runlevels/shutdown/
total 0
drwxr-xr-x 2 root root 56 May 4 08:29 .
drwxr-xr-x 7 root root 81 Jun 8 2016 ..
lrwxrwxrwx 1 root root 21 Apr 27 21:29 killprocs -> /etc/init.d/killprocs
lrwxrwxrwx 1 root root 20 Apr 27 21:29 mount-ro -> /etc/init.d/mount-ro
lrwxrwxrwx 1 root root 21 Apr 27 21:29 savecache -> /etc/init.d/savecache
[flatbush ~]#
Is that relevant? can this be related to trouble with my network booting correctly?
If you were around debian and maybe arch, when systemd was adopted the #1 attack by systemd defenders was that sysvinit is an antique that needs to be replaced with something more modern. AFAICT OpenRC is no init system, it is a wrapper for sysvinit. It is like putting new bodywork on a 60s vw bug. It may still work and be reliable and have less wind noise.
s6 and runit are so simple and so reliable once set up correctly they may as well be used in a school for teaching students what an init system is and what supervision does. Whether google can use them for their servers or not, it is not a priority for me to find out.
Apart from the bumpy road and instance I chose to go with runit, it runs like a swiss clock. The only installation I have with openrc is a refracta which I keep around with no use just out of respect for the guy who makes it. I don't have the heart to delete refracta.
But OpenRC being on and supported means you don't have to change anything, so what are you worried about?
Gentoo is catering to a very specific crowd of sysadmins, they like what they develop and what is being developed for them. Make sure you have the same needs as they do then get attached to it. My opinion is that most of us don't need something so complex. It is the only reason that systemd gained support that something new was needed, "for the same crowd".
Your network problem is unrelated to OpenRC. You are using 2 network managers at the same time and they conflict. Read my post in your other thread.
Hello, may I just add this to fungalnet's comment?
OpenRC used to be a wrapper just for the old init (SysV), that binary /sbin/init.
The more recent Linux distros with OpenRC sport their own (OpenRC-)init binary, but still called the same and doing the same thing. That's the elegance of it. It even works with "old" init scripts in /etc/init.d/ provided the distro adheres to LSB standards.
Enjoy the choice of several init systems at your hands! OpenRC, runit, S6, InitSysV all are well and kicking! Even InitSysV gets some revival.
Guys, "rolling distro" to me means a full image backup with Clonezilla of /boot/efi and / before I even dream about applying updates. I got bitten by the "no init" after updating as well, but simply restored the backup until I had time to look into this and come here.
Finger-pointing will not help and the community is way too small, in my opinion, to be able to afford any bad blood.
What might help - and this is a suggestion: could pacman be leveraged to display an UPDATING message (I am thinking about FreeBSD ports here) before committing an update, whenever first doing an update after an architecture change has been made that is likely to break things?
That being said, I found Artix so far to be a much better experience than Ubuntu / Mint and the stability is great (not talking about updating, but everyday usage).
I love to have a systemd-free distro, I hate every single break changing. But I understand some reasons, it's ok doing mistakes. It's not ok, however, not even thinking about how painful it's for the users.
Artix, with updates off, it's a solid system with me. But sincerely after each upgrade I don't know more if my system will open X correctly (several packages broken in my system since the beginning of this year) and now even OpenRC.
I'm not making here any exigence. The dev guys behind this are doing a truely hero job, I'm just sad for the overall experience. But I'll not give up. For now, I don't have any great alternative for a stable system Arch-like with a systemd-free mindset.
I'm really not trying to talk bad about Artix. I still have hope that all this changes will normalize and we'll can use artix for a nice time.
Anyway, good luck for you guys, hope the best for the distro.
Can someone please tell me what my next steps are from the rootfs prompt?
It says /sbin/init does not exist.
I've managed to find my personal files under the new_root structure so can backup at least.
Don't worry, all your OS and data should be perfectly safe, there is no real problem. I guess you updated and didn't read that you needed to install the artix-sysvcompat package before shutting down. That contains the init file symlink to the real init:
$ pacman -Ql artix-sysvcompat
artix-sysvcompat /usr/
artix-sysvcompat /usr/bin/
artix-sysvcompat /usr/bin/halt
artix-sysvcompat /usr/bin/init
artix-sysvcompat /usr/bin/poweroff
artix-sysvcompat /usr/bin/reboot
artix-sysvcompat /usr/bin/shutdown
artix-sysvcompat /usr/share/
artix-sysvcompat /usr/share/libalpm/
artix-sysvcompat /usr/share/libalpm/hooks/
artix-sysvcompat /usr/share/libalpm/hooks/50-sysvcompat.hook
artix-sysvcompat /usr/share/libalpm/hooks/55-initswitch.hook
artix-sysvcompat /usr/share/libalpm/scripts/
artix-sysvcompat /usr/share/libalpm/scripts/initswitch-hook
artix-sysvcompat /usr/share/licenses/
artix-sysvcompat /usr/share/licenses/halt/
artix-sysvcompat /usr/share/licenses/halt/COPYING
artix-sysvcompat /usr/share/man/
artix-sysvcompat /usr/share/man/man8/
artix-sysvcompat /usr/share/man/man8/halt.8.gz
artix-sysvcompat /usr/share/man/man8/poweroff.8.gz
artix-sysvcompat /usr/share/man/man8/reboot.8.gz
artix-sysvcompat /usr/share/man/man8/shutdown.8.gz
$ ls -l /usr/bin/init
lrwxrwxrwx 1 root root 11 May 1 21:41 /usr/bin/init -> openrc-init
(it would point to runit-init if you were using runit)
So you see, all you are missing is to boot up and install that package. You can follow Artoo's instructions (usually the best plan) on the first page of this thread to temporarily alter the command line, or probably even chroot in and install the package after manually downloading it, or make a temporary symlink manually somehow if you felt like it.
Thanks. I have chrooted and resolved.
Download latest artix
Write to usb drive and boot
Setup network
Update mirrors (as per main page)
Unlock luks partitions (udiskctl)
mount partition
chroot
install artix-syscompact
reboot
Might be a good idea to elaborate on the "command line" instructions as to where exactly it needs to be added to get back in to install the compat package? I tried adding it to my linux line and still couldn't get in. Thankfully it was on a dev updater box but I didn't have much time so I wound up doing a new install actually following Artoo's instructions instead of fighting with it.
Look guys I have been just to busy to bother with Artix for over one month in that time Nvidia has decided to mess users up by not recognising certain current cards .
I decided to ditch Nvidia and do this update while I was at it 1st Nvidia got that out of the way.
Well I followed Artoo to the letter downloaded 650MB rebooted guess what all was fine like I knew it would but then i'm just a old Arch user used to doing things the Arch way,
now I'm a happy Artix user doing things the Artix way.
Its all very simple really.
Arch occasionally will bite in the same way if you forget to check for manual intervention. It's so rare, that it becomes very easy to forget to check. IIRC, there was a wrapper for pacman in Arch that did something like that. I see a pacmatic package that is similar, but I don't think that's the one I used. The problem with the one I used is that it tried to do a lot of other stuff as well and became annoying.
for openrc
<<Remove runlevel symlinks you eventually set manually.>>
What does this mean exactly? I have delayed updating my server, but I will do it this weekend. But I'm not sure what this exactly means.
you uninstall the two services from the run levels and then install one package, this is directly under the openrc section on the first post.
then I am not rm'ing anything. I am sorry for being confused.
Well you are stopping the two services from auto starting because the new file does this automatically and you don't want or need the services to start twice.