Re: OpenRC & eudev on Arch

OK it's working now, due to updates or something.

Another question: recent versions of modemmanager are not started by dbus automatically but need to be systemctl enabled. Openrc has no service file for it, and I have no idea how to create one. Can anyone help with this?

Re: OpenRC & eudev on Arch

It is work in progress.I have been a bit busy with other stuff, but I am working on it right now.

I will test before I put anything in the repo, because theoretically the /usr prefix is not necessary any more.I just created a plugins tarball with unprefixed runscripts, just fixed for arch.

I'll see how it plays out in virtualbox first, since without prefix, some paths in the openrc pkgbuild need to eventually point to /usr. Not sure right now.

However, the current version packages and builds should also run fine in theory, except the openrc-git build would need a minor fix to remove the rc symlink it creates.

Update: Everything runs fine without prefix, in vbox.I'll put sysvinit in the repo too.So updated packages would be up soon, I just need to test upgrade behaviour.Github repo should also have updated versions soon.

It would make the plugin packages fully compatible with apg AUR openrc-git.I already adapted the download script for the runscripts

Re: OpenRC & eudev on Arch

great to hear that, artoo.

I messed up the update because i had forgotten to install latest sysvinit and openrc-sysvinit, fixed it but now have a different problem.

my /home is on LVM, and since the /usr move update 4 out of 5 boots it fails to mount my home.With systemd i do 'vgchange -ay' in maintenance mode to activate /home, then issue 'systemctl default' and boot continues.

Openrc gives me a normal console, but i'm not sure how to redo the boot process with the vg present.atm i do this :

# vgchange -ay
# rc boot
# rc default

This does appear to work, but doesn't feel like a clean way to me.

putting vgchange -ay in the local service doesn't help, as the volume needs to be active before localmount service runs.local service is run after the boot services.

Re: OpenRC & eudev on Arch

Lone_Wolf wrote:

great to hear that, artoo.

I messed up the update because i had forgotten to install latest sysvinit and openrc-sysvinit, fixed it but now have a different problem.

my /home is on LVM, and since the /usr move update 4 out of 5 boots it fails to mount my home.With systemd i do 'vgchange -ay' in maintenance mode to activate /home, then issue 'systemctl default' and boot continues.

Openrc gives me a normal console, but i'm not sure how to redo the boot process with the vg present.atm i do this :

# vgchange -ay
# rc boot
# rc default

This does appear to work, but doesn't feel like a clean way to me.

putting vgchange -ay in the local service doesn't help, as the volume needs to be active before localmount service runs.local service is run after the boot services.

Suggestions how to solve/workaround the lvm2 problem in a clean way ?

I must say, I am almost glad to read that.Because I have a similar problem with arch linux and lvm. But for me, its the lvm root partition which does it.And I tested it with systemd and openrc, it appears to happen with both init systems randomly, but especially if I reboot from genoo into arch. And it has done this before the /usr merge.I have a slight suspicion that it is either mkinitcpio or kernel, kmod or something related on arch.

As for activating lvm partitions manually, do you refer to the recovery shell? Or do you login as root and then issue the commands to get /home mounted to login as user? Does this happen to other lvm partition on your system?

edit:

I am in a hurry, reread you post:I would just try to restart the localmount service once lvm partition is activated.

I noticed I expressed myself badly, I was referring to these plugin tarballs, which are the source for the pkgbuilds installing them. But the pkgbuilds are not compatible with apg, since I maintain changing /etc/conf.d is not a good idea.

Re: OpenRC & eudev on Arch

I've read them and it seems cleanest solution is to use a service-file to take care of lvm activation that then becomes a needed dependency of localmount (or even fsck).

I've looked at your plugin files, and the lvm2 stuff in there looks useful.

We've discussed about the configdirs differences between your setup and apg' setup before.it would be great if plugins could be shared, but you have every right to decline making them compatible with both your and apg setup.Fortunately it shoudl be doable to convert your plugin files to work with apg' packages manually.

Re: OpenRC & eudev on Arch

I've read them and it seems cleanest solution is to use a service-file to take care of lvm activation that then becomes a needed dependency of localmount (or even fsck).

I've looked at your plugin files, and the lvm2 stuff in there looks useful.

We've discussed about the configdirs differences between your setup and apg' setup before.it would be great if plugins could be shared, but you have every right to decline making them compatible with both your and apg setup.Fortunately it shoudl be doable to convert your plugin files to work with apg' packages manually.

To clear up any possible confusion.

The new to be released version of the runscripts(downloaded from gentoo) in the tarball package will be compatible with apg openrc, but you would have to install them manually. My pkgbuilds for individual services, eg samba, won't be compatible due to the different conf.d locations. Besides that, the new runscripts won't need to be fixed in any way. They should run just fine if manually placed.

In case you missed it, I made a small download script, which downloads the service files from gentoo, and automatically fixes eventual /bin or /sbin differences. Not perfect, but does the job, and the files you want to download are collected in a list file, so download reads the list.

I completely changed the way to handle and maintain the runscripts. In fact, I don't maintain them myself any longer, I directly get them from gentoo, let a fairly easily extensible script fix inconsitencies, and just package them, while downloaded in a git repo. Its too time consuming trying to maintain them.

Re: OpenRC & eudev on Arch

Well... it works but the options to enable wifi/mobile broadband/network are grayed out. (I'm using network-manager-applet-gtk2).

Whatever... the stock networkmanager, managed via the scripts included on the openrc version is working fine for me.

We still need to fix the ModemManager behavior, I haven't a gentoo installation handy now, so I don't know how they launch mm.

I guess the grayed out options are caused by the lack of consolekit support of some gnome library or component. I have been playing around with that, but I don't use gnome myself, and haven't spent much time on it.I know that you need eg gdm compiled with ck flag.

Stock NM won't reliably work with the script, it misses a library, ifnet, an openrc specific NM plugin.You won't get the correct NM status returned reliably and possible dependencies won't work if NM doesn't switch from waiting to running.

Anyway, I recall, last time I tried, I forgot to fix some dependency which didn't allow me to install the nm-applet. I can't remember if I fixed it off the top of my head.

Re: OpenRC & eudev on Arch

@artoo, it is not mkinitcpio or the kernel or kmod that is causing your lvm2 woes. This happened to many (myself included) when the lvm2 package changed from using shell scripts to detect/activate the LVM to using lvmetad. This change occurred toward the end of last year, so if you go to the lvm2 package's page, you can view the changes in the upper right hand corner of the page. In the commits you'll see where work starts on using lvmetad instead.

As a workaround, until I hear of some consistency from others, I have actually been using the old version and have put it in the "IgnorePkg" section of pacman.conf. Actually you have to use the old lvm2 and the old device-mapper, as both those packages are built from teh same PKGBUILD. But with the recent /usr merge, you will need to modify the PKGBUILD so that it puts all the binaries in /usr/bin, as they will otherwise be in /sbin. I actually just moved the binaries manually, then changed the paths in /var/lib/pacman/local/<packages>/files to reflect their new homes in /usr/bin. Everything continues to work great with these packages.

Re: OpenRC & eudev on Arch

WonderWoofy wrote:

@artoo, it is not mkinitcpio or the kernel or kmod that is causing your lvm2 woes. This happened to many (myself included) when the lvm2 package changed from using shell scripts to detect/activate the LVM to using lvmetad. This change occurred toward the end of last year, so if you go to the lvm2 package's page, you can view the changes in the upper right hand corner of the page. In the commits you'll see where work starts on using lvmetad instead.

As a workaround, until I hear of some consistency from others, I have actually been using the old version and have put it in the "IgnorePkg" section of pacman.conf. Actually you have to use the old lvm2 and the old device-mapper, as both those packages are built from teh same PKGBUILD. But with the recent /usr merge, you will need to modify the PKGBUILD so that it puts all the binaries in /usr/bin, as they will otherwise be in /sbin. I actually just moved the binaries manually, then changed the paths in /var/lib/pacman/local/<packages>/files to reflect their new homes in /usr/bin. Everything continues to work great with these packages.

Thx, this sounds logical, because I maintain a mkinitcpio ebuild for gentoo, and didn't get lvmetad running on gentoo. Thus I reverted on gentoo to standard volume activation pre lvmetad hook and don't have any problems with arch's mkinitcpio on gentoo.

Re: OpenRC & eudev on Arch

i now have added 'vgchange -ay' in the fsck start section, but encountered another problem.

both apg openrc and openrc-git have it.

I can add/delete a service to boot or default runlevel with rc-update, but on next boot they are not used.If i add the service as a need dependency to an existing service like localmount, i get the message that service is unknown at boot.

The link is added (or removed) from the correct folder /etc/openrc/runlevels , and rc-service --resolve does find the script correctly.

I've tried to force rebuilding of the cached dependency tree with rc-update -u, but this doesn't change anything.

Atm i'm not sure if my install is messed up, the problem is caused by the /usr/bin move or a bug in openrc itself.Can someone please verify if adding or removing a service from boot or default runlevel works for them ?

Re: OpenRC & eudev on Arch

Lone_Wolf wrote:

i now have added 'vgchange -ay' in the fsck start section, but encountered another problem.

both apg openrc and openrc-git have it.

I can add/delete a service to boot or default runlevel with rc-update, but on next boot they are not used.If i add the service as a need dependency to an existing service like localmount, i get the message that service is unknown at boot.

The link is added (or removed) from the correct folder /etc/openrc/runlevels , and rc-service --resolve does find the script correctly.

I've tried to force rebuilding of the cached dependency tree with rc-update -u, but this doesn't change anything.

Atm i'm not sure if my install is messed up, the problem is caused by the /usr/bin move or a bug in openrc itself.Can someone please verify if adding or removing a service from boot or default runlevel works for them ?

My guess is, you mixed runscripts?

the runscripts in /etc/init.d/ should start with #!/sbin/runscript in first line.

My current binary package versions still make use of #!/usr/sbin/runscript which would produce the behaviour you describe if you use mixed scripts.

My next package version will address that and return to #!/sbin/runscript too.

I already updated my git repo, and packages are about to be updated in the binary repo.Plugins version 0.9.1 to be released.

However, I found no way to update openrc before the user completed the /usr merge, due to already mentioned sysvinit hardcoded paths.So updating openrc would involve to uninstall it before /usr merge.If /usr merge has been done already, then installing new version/updating is without problems.