OpenRC & eudev on Arch

x33a · 2013-04-15 10:04:45

What are the contents of your .xinitrc?

Also, did you put the hostname in /etc/hosts as well?

gothmog123 · 2013-04-15 15:08:52

Actually there's a name set for 127.0.0.1 (is this the one I need?) in /etc/hosts. It's not host-001.

My .xinitrc:

#!/bin/bash

(sleep 2 && /usr/bin/nm-applet --sm-disable) &

tint2 &

(sleep 4 && /home/andras/.fehbg) &

xbacklight -set 100

exec ck-launch-session dbus-launch openbox-session

x33a · 2013-04-15 17:45:18

I am not sure, but maybe it's network manager? Do you have dhcp running and set to change hostnames?

In any case disable networkmanager and then startx to figure out the cause.

gothmog123 · 2013-05-03 18:29:43

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?

x33a · 2013-05-04 05:13:50

Do you need modemmanager running all the time? If yes, then you can simply start it through xinitrc.

gothmog123 · 2013-05-04 07:29:41

Seems like it only works when it's systemctl enabled and I reboot. Modems are not picked up if I just systemctl start it. Must have something to do with systemd stuff or dbus?

The Solutor · 2013-05-09 09:21:31

artoo wrote:

No major issues encountered here.
You may want to add the hostapd plugin, here is it the one I'm using (it required minor fixes)
/etc/openrc/init.d/hostapd

I have add hostapd to plugins source, and a git build is also on github.
Would be helpful if you could test it.

I'm sorry for the very late reply, but I was very busy due to some family issues, and to get the matter worse the forum missed to sent me the notifications via email.

BTW the hostapd script works fine.

Networkmanager 0.9.8 is available as build and binary pkg, works well, and has lower case service name now.

NM instead doesn't work 100% for me.

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.

Last edited by The Solutor (2013-05-09 09:22:34)

Lone_Wolf · 2013-06-01 09:21:47

The move from /bin , /sbin , /usr/sbin to /usr/bin (already talked about a lot in this thread) is now really close,

https://mailman.archlinux.org/pipermail … 25003.html .

I've checked apg' openrc and openrc-git packages, and both will give problems when that update is rolled out.
I left a comment on the pages of the aur packages.

Artoo, what is the status of your packages wrt the /usr move ?

Mektub · 2013-06-01 21:44:37

Lone_Wolf,

there is an update to the arch-dev-public mail:

https://mailman.archlinux.org/pipermail … 25042.html

Mektub

x33a · 2013-06-02 08:40:34

@ Mektub, but the openrc packages still need to be fixed. Lone_Wolf got the maintainer of sysvinit in the AUR to fix the package already, it's just openrc now.

Last edited by x33a (2013-06-02 08:41:03)

apg · 2013-06-02 15:49:43

openrc and openrc-git have been updated. If you're using openrc-arch-services-git make sure you upgrade it as well.

x33a · 2013-06-03 20:01:21

Is anyone else having problems with shutting the system down after upgrading openrc and sysvinit?

I am getting the following errors with different commands.

# poweroff
shutdown: No such file or directory

# halt
shutdown: No such file or directory

# shutdown -h now
shutdown: cannot execute /sbin/init

Seems like the init binary path is hardcoded in the shutdown binary.

apg · 2013-06-03 20:32:42

x33a wrote:

Is anyone else having problems with shutting the system down after upgrading openrc and sysvinit?
I am getting the following errors with different commands.
# poweroff
shutdown: No such file or directory

# halt
shutdown: No such file or directory

# shutdown -h now
shutdown: cannot execute /sbin/init
Seems like the init binary path is hardcoded in the shutdown binary.

Yes, the sysvinit binaries have several hardcoded paths. Sysvinit should not be upgraded without also completing the /usr/bin merge.

x33a · 2013-06-04 06:27:30

apg wrote:

Yes, the sysvinit binaries have several hardcoded paths. Sysvinit should not be upgraded without also completing the /usr/bin merge.

Thanks. Completing the /usr merge fixed the problem.

Mektub · 2013-06-04 07:22:33

I have a laptop running OpenRC and the /usr merge completed without problems.

Thanks for all the work.

Mektub

artoo · 2013-06-04 17:58:36

Lone_Wolf wrote:

Artoo, what is the status of your packages wrt the /usr move ?

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

Last edited by artoo (2013-06-04 19:02:03)

Lone_Wolf · 2013-06-05 00:26:19

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 ?

Last edited by Lone_Wolf (2013-06-05 00:27:42)

artoo · 2013-06-05 09:42:30

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.

but my problem solution always involves recovery shell. because the root device won't be found/activated.

edit2:
Probably a good idea to post documentaion links:
http://wiki.gentoo.org/wiki/OpenRC#Named_runlevels
http://www.gentoo.org/doc/en/handbook/h … t=2&chap=4

In your case, the are some more solutions.

edit3:

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.

Last edited by artoo (2013-06-05 10:16:59)

Lone_Wolf · 2013-06-05 11:40:48

Those are very useful links, artoo.

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.

artoo · 2013-06-05 13:58:21

Lone_Wolf wrote:

Those are very useful links, artoo.
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.

https://github.com/udeved/pkgbuilds/tree/master/scripts

sh run

and you'll have the runscripts on your harddrive.

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.

Last edited by artoo (2013-06-05 15:06:50)

artoo · 2013-06-05 14:54:45

The Solutor wrote:

NM instead doesn't work 100% for me.
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.

WonderWoofy · 2013-06-05 17:24:38

@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.

artoo · 2013-06-05 17:45:42

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.

Last edited by artoo (2013-06-05 17:47:38)

Lone_Wolf · 2013-06-07 10:11:55

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 ?

Last edited by Lone_Wolf (2013-06-07 10:14:28)

artoo · 2013-06-07 11:08:24

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.

Arch Linux

#176 2013-04-15 10:04:45

Re: OpenRC & eudev on Arch

#177 2013-04-15 15:08:52

Re: OpenRC & eudev on Arch

#178 2013-04-15 17:45:18

Re: OpenRC & eudev on Arch

#179 2013-05-03 18:29:43

Re: OpenRC & eudev on Arch

#180 2013-05-04 05:13:50

Re: OpenRC & eudev on Arch

#181 2013-05-04 07:29:41

Re: OpenRC & eudev on Arch

#182 2013-05-09 09:21:31

Re: OpenRC & eudev on Arch

#183 2013-06-01 09:21:47

Re: OpenRC & eudev on Arch

#184 2013-06-01 21:44:37

Re: OpenRC & eudev on Arch

#185 2013-06-02 08:40:34

Re: OpenRC & eudev on Arch

#186 2013-06-02 15:49:43

Re: OpenRC & eudev on Arch

#187 2013-06-03 20:01:21

Re: OpenRC & eudev on Arch

#188 2013-06-03 20:32:42

Re: OpenRC & eudev on Arch

#189 2013-06-04 06:27:30

Re: OpenRC & eudev on Arch

#190 2013-06-04 07:22:33

Re: OpenRC & eudev on Arch

#191 2013-06-04 17:58:36

Re: OpenRC & eudev on Arch

#192 2013-06-05 00:26:19

Re: OpenRC & eudev on Arch

#193 2013-06-05 09:42:30

Re: OpenRC & eudev on Arch

#194 2013-06-05 11:40:48

Re: OpenRC & eudev on Arch

#195 2013-06-05 13:58:21

Re: OpenRC & eudev on Arch

#196 2013-06-05 14:54:45

Re: OpenRC & eudev on Arch

#197 2013-06-05 17:24:38

Re: OpenRC & eudev on Arch

#198 2013-06-05 17:45:42

Re: OpenRC & eudev on Arch

#199 2013-06-07 10:11:55

Re: OpenRC & eudev on Arch

#200 2013-06-07 11:08:24

Re: OpenRC & eudev on Arch

Board footer