You are not logged in.

#701 2011-06-03 19:03:34

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

hda-codec: no NID mapping control independent hp:0:0

Not systemd-related. Seems harmless and you confirm that everything works. Not sure why you're pointing this out.

You seem to misunderstand of how module loading works. In short, you don't need to do anything. Modules will still be detected and loaded by udev on boot. If you have a need for specific other modules that udev does not load on boot (such as those you might put in the MODULES array in /etc/rc.conf), then you want to add those in config files in /etc/module-load.d.

In the future, please use code tags, not quote tags when posting output.

Offline

#702 2011-06-05 01:35:40

cuihao
Member
Registered: 2011-03-19
Posts: 27

Re: systemd: Yet Another Init Replacement

My systemd does not work now. getty cannot start:
2011-06-05T09:01:49+08:00 localhost systemd[1]: Job dev-tty6.device/start timed out.

Before this, I try making systemd work while using aufs usr and it works.
Yesterday, I gave up and moved usr back. Then systemd doesn't work any more.

/sbin/init works well.


Forgive my poor English. I am a senior student from China.

Offline

#703 2011-06-05 01:44:20

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

You cannot have /usr on a separate filesystem. This is very clear on the wiki and has been mentioned several times in this thread.

Last edited by falconindy (2011-06-05 02:11:03)

Offline

#704 2011-06-05 03:31:13

cuihao
Member
Registered: 2011-03-19
Posts: 27

Re: systemd: Yet Another Init Replacement

falconindy wrote:

You cannot have /usr on a separate filesystem. This is very clear on the wiki and has been mentioned several times in this thread.

I mean:
When I use /usr on a separate filesystem, systemd worked (I copy the dbus libraries to /lib).
But when I use original /usr on root filesystem , it failed.


Forgive my poor English. I am a senior student from China.

Offline

#705 2011-06-05 06:40:23

sonay
Member
Registered: 2010-03-09
Posts: 75

Re: systemd: Yet Another Init Replacement

falconindy wrote:
hda-codec: no NID mapping control independent hp:0:0

Not systemd-related. Seems harmless and you confirm that everything works. Not sure why you're pointing this out.

You seem to misunderstand of how module loading works. In short, you don't need to do anything. Modules will still be detected and loaded by udev on boot. If you have a need for specific other modules that udev does not load on boot (such as those you might put in the MODULES array in /etc/rc.conf), then you want to add those in config files in /etc/module-load.d.

In the future, please use code tags, not quote tags when posting output.

I pointed that out because with sysV, I didn't had that message. And I am wondering why this is coming out during boot.

For the modules, if I don't add those files, udev does not detect my keyboard and my touchpad. I didn't know where else to ask, because all these problems started to occur, just after moving to systemd. I hope this makes sense for you.

By the way, since hardware clock is deprecated (I don't remember where I read), how do you keep your time correct? Mine is 3 hours back, since last night.

(Sorry for my English, I am not native.)

Offline

#706 2011-06-05 09:54:52

bharani
Member
From: Karaikudi, India
Registered: 2009-07-12
Posts: 202

Re: systemd: Yet Another Init Replacement

I have a problem with systemd now
Using systemctl i can start/stop/status sensors.service but if run enable/ disbale then it says that the service is not found

┤03:16 PM|$├1─> sudo systemctl  start  sensors.service

┤03:20 PM|$├─> sudo systemctl  status  sensors.service
sensors.service - SYSV: sensors is used for monitoring motherboard sensor values.
      Loaded: loaded (/etc/rc.d/sensors)
      Active: active (running) since Sun, 05 Jun 2011 15:16:42 +0530; 4min 12s ago
     Process: 2216 ExecStop=/etc/rc.d/sensors stop (code=exited, status=0/SUCCESS)
     Process: 2270 ExecStart=/etc/rc.d/sensors start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/sensors.service
┤03:20 PM|$├─> sudo systemctl  enable  sensors.service
Couldn't find sensors.service.

Please help me.
Thanks.


Tamil is my mother tongue.

Offline

#707 2011-06-05 12:21:05

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

bharani wrote:

I have a problem with systemd now
Using systemctl i can start/stop/status sensors.service but if run enable/ disbale then it says that the service is not found

┤03:16 PM|$├1─> sudo systemctl  start  sensors.service

┤03:20 PM|$├─> sudo systemctl  status  sensors.service
sensors.service - SYSV: sensors is used for monitoring motherboard sensor values.
      Loaded: loaded (/etc/rc.d/sensors)
      Active: active (running) since Sun, 05 Jun 2011 15:16:42 +0530; 4min 12s ago
     Process: 2216 ExecStop=/etc/rc.d/sensors stop (code=exited, status=0/SUCCESS)
     Process: 2270 ExecStart=/etc/rc.d/sensors start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/sensors.service
┤03:20 PM|$├─> sudo systemctl  enable  sensors.service
Couldn't find sensors.service.

Please help me.
Thanks.

1) You can't enable the service if it doesn't exist in the form of a .service file. systemd will scrape /etc/rc.d for scripts and allow you to start/stop daemons via systemctl.
2) The sensors "daemon" does nothing but load/unload modules. I suggest figuring out what modules you need and instead just loading those modules at boot.

Offline

#708 2011-06-05 12:24:38

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

sonay wrote:
falconindy wrote:
hda-codec: no NID mapping control independent hp:0:0

Not systemd-related. Seems harmless and you confirm that everything works. Not sure why you're pointing this out.

You seem to misunderstand of how module loading works. In short, you don't need to do anything. Modules will still be detected and loaded by udev on boot. If you have a need for specific other modules that udev does not load on boot (such as those you might put in the MODULES array in /etc/rc.conf), then you want to add those in config files in /etc/module-load.d.

In the future, please use code tags, not quote tags when posting output.

I pointed that out because with sysV, I didn't had that message. And I am wondering why this is coming out during boot.

I have no idea what it means. I'm still doubtful that it's systemd related. Scour dmesg for this while booting off /sbin/init. Either way, google is your friend.

sonay wrote:

For the modules, if I don't add those files, udev does not detect my keyboard and my touchpad. I didn't know where else to ask, because all these problems started to occur, just after moving to systemd. I hope this makes sense for you.

Then like I said, create conf files in /etc/modules-load.d so those modules are loaded on boot.

sonay wrote:

By the way, since hardware clock is deprecated (I don't remember where I read), how do you keep your time correct? Mine is 3 hours back, since last night.

(Sorry for my English, I am not native.)

Hardware Clock is not deprecated. Running it in localtime is discouraged, but still supported. UTC Is preferred. Sounds like your time zone isn't being honored. hwclock --systz --utc.

Offline

#709 2011-06-05 12:25:53

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

cuihao wrote:
falconindy wrote:

You cannot have /usr on a separate filesystem. This is very clear on the wiki and has been mentioned several times in this thread.

I mean:
When I use /usr on a separate filesystem, systemd worked (I copy the dbus libraries to /lib).
But when I use original /usr on root filesystem , it failed.

I don't know what you broke, but if it worked before and now it doesn't, you broke something. There's way too many people drinking the squashed /usr koolaid. It's complete crap.

Offline

#710 2011-06-05 13:00:07

kritter
Member
Registered: 2011-06-05
Posts: 19
Website

Re: systemd: Yet Another Init Replacement

Hey guys. Am I the only one who does not like to enter every passphrase for ever LUKS device on my system? Seems like the scripts mentioned by the article can not parse /etc/crypttab. Anyone who's written some fix for this or who has a clue how to write a new service file?

This is the only issue I found testing systemd some minutes ago, seems good to me.


My try at blogging // IRC: kritztopf@freenode

Offline

#711 2011-06-05 13:15:48

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

systemd follows the debian /etc/crypttab format. The third field is the path to a keyfile, not a password itself. It's not broken, just different from how Arch does it. IMO, the Arch format allowing plaintext passwords to be stored in /etc/crypttab is what's broken.

Offline

#712 2011-06-05 14:26:01

bharani
Member
From: Karaikudi, India
Registered: 2009-07-12
Posts: 202

Re: systemd: Yet Another Init Replacement

falconindy wrote:

1) You can't enable the service if it doesn't exist in the form of a .service file. systemd will scrape /etc/rc.d for scripts and allow you to start/stop daemons via systemctl.
2) The sensors "daemon" does nothing but load/unload modules. I suggest figuring out what modules you need and instead just loading those modules at boot.

Thanks falconindy. I have found and added the module to /etc/modules-load.d.


Tamil is my mother tongue.

Offline

#713 2011-06-05 21:12:21

pogeymanz
Member
Registered: 2008-03-11
Posts: 1,020

Re: systemd: Yet Another Init Replacement

falconindy wrote:

There's way too many people drinking the squashed /usr koolaid. It's complete crap.

I know this is completely off topic, but can you elaborate or point me towards something to back that up? In principle the squashed /usr thing makes sense since our hard drives are big bottle-necks for performance, so reading less data off of them seems like a good idea. Why wouldn't that be true?

Offline

#714 2011-06-05 21:32:33

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

Putting aside the fact that more and more distros will not support /usr on a separate partition, you're compressing mostly binaries -- they don't compress well. It also opens up multiple points of failure:

- what if it doesn't mount and you don't notice? Chances are, your old /usr is still there and full of old junk. Worse, what if the squashed FS becomes corrupted? There's no fsck for squashfs.
- how often do you recompress? You can't feasibly do this from outside runlevel 1, and its also impossible to do cleanly under systemd. If your system changes a lot (hi, rolling release), you lose a lot of the benefit, and recompressing is a pain in the neck.
- the aufs2 maintainer is getting slower and slower to update for each kernel release. He does not yet know when 2.6.39 support will be available. This is a really crappy reason to hold back a kernel update.
- how much I/O are you really saving? with ~500 packages installed, my /usr is 2GB. The commonly used binaries are pretty much immediately cached in memory and then it doesn't matter how compressed they are.

I did this long ago. It was not, imo, worth the hassle.

Offline

#715 2011-06-05 22:19:30

sonay
Member
Registered: 2010-03-09
Posts: 75

Re: systemd: Yet Another Init Replacement

falconindy wrote:
sonay wrote:
falconindy wrote:
hda-codec: no NID mapping control independent hp:0:0

Not systemd-related. Seems harmless and you confirm that everything works. Not sure why you're pointing this out.

You seem to misunderstand of how module loading works. In short, you don't need to do anything. Modules will still be detected and loaded by udev on boot. If you have a need for specific other modules that udev does not load on boot (such as those you might put in the MODULES array in /etc/rc.conf), then you want to add those in config files in /etc/module-load.d.

In the future, please use code tags, not quote tags when posting output.

I pointed that out because with sysV, I didn't had that message. And I am wondering why this is coming out during boot.

I have no idea what it means. I'm still doubtful that it's systemd related. Scour dmesg for this while booting off /sbin/init. Either way, google is your friend.

sonay wrote:

For the modules, if I don't add those files, udev does not detect my keyboard and my touchpad. I didn't know where else to ask, because all these problems started to occur, just after moving to systemd. I hope this makes sense for you.

Then like I said, create conf files in /etc/modules-load.d so those modules are loaded on boot.

sonay wrote:

By the way, since hardware clock is deprecated (I don't remember where I read), how do you keep your time correct? Mine is 3 hours back, since last night.

(Sorry for my English, I am not native.)

Hardware Clock is not deprecated. Running it in localtime is discouraged, but still supported. UTC Is preferred. Sounds like your time zone isn't being honored. hwclock --systz --utc.

Thanks for the help and your great effort to bring systemd to us, everything is OK now.

Offline

#716 2011-06-06 13:50:57

bwat47
Member
Registered: 2009-10-07
Posts: 638

Re: systemd: Yet Another Init Replacement

I have a question. I am using kernel26-ck with the bfs scheduler. The wiki pages for systemd says it uses cgroups, but bfs does not implement these. Does this mean systemd does not work with this kernel?

Offline

#717 2011-06-06 13:53:39

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

One way to find out wink

spoiler alert: it works.

Offline

#718 2011-06-06 13:57:35

bwat47
Member
Registered: 2009-10-07
Posts: 638

Re: systemd: Yet Another Init Replacement

Alright thanks. One more question. I am using inittab to start gnome. The wiki says systemd does not use inittab at all. Do I have to switch to xinitrc to start gnome if I use systemd?

Offline

#719 2011-06-06 17:10:22

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: systemd: Yet Another Init Replacement

Please read the fine wiki page on systemd.

Offline

#720 2011-06-10 08:55:00

eworm
Package Maintainer (PM)
From: Oberhausen, Germany
Registered: 2010-01-30
Posts: 105
Website

Re: systemd: Yet Another Init Replacement

falconindy wrote:

The wiki already mentions this.  If anything, the wiki should merely refer people to the man page to let them figure out what options make sense for their setup. I personally prefer the default behavior, as the man page also mentions:

Note that setting kill-user=1 or even kill-session=1 will break tools like screen(1)

I have a little 'workaround' for this problem... I have scripts that create a new cgroup "name=systemd:/tmux/${USER}" and then launches tmux within this cgroup. Works perfectly so far, even with kill-user=1 or kill-session=1. Get the packages here:

http://arch.lugor.de/eworm/x86_64/libcg … pkg.tar.xz (or from AUR)
http://arch.lugor.de/eworm/x86_64/tmux- … pkg.tar.xz


ArchLinux - make it simple & lightweight

Offline

#721 2011-06-10 11:02:49

Viper_Scull
Member
From: London, UK
Registered: 2011-01-15
Posts: 153

Re: systemd: Yet Another Init Replacement

With the latest updates when i restart or shut down the machine the system freezes for about a minute and then it continues.

I've booted without the quiet parameter to see which service was causing this behavior. The last line i could read before the freeze is "Stopped Permit User Sessions". Then after a minute o minute and a half it goes on but i dont have enough time to read the first line.

What comes after Stopped Permit User Sessions? Or at least is there a way pressing some key to make it go line by line to be able to read it?

Last edited by Viper_Scull (2011-06-10 11:47:54)


Athlon II X4 620 + Gigabyte 785GPM-UD2H + 4GB DDR3 + SSD OCZ Vertex2 60GB

Archlinux x86_64 + Openbox

Offline

#722 2011-06-10 13:03:40

adrianx
Member
From: South Africa
Registered: 2010-03-22
Posts: 70

Re: systemd: Yet Another Init Replacement

@Viper_Scull

The same thing happened to me. In my case, there were broken links in /etc/systemd/system/...

One of them was networkmanager.service. I deleted the broken links and for NetworkManager, did a "systemctl enable NetworkManager.service".

I had to do the same for cups.

Last edited by adrianx (2011-06-10 13:05:48)

Offline

#723 2011-06-10 15:40:51

Arm-the-Homeless
Member
Registered: 2008-12-22
Posts: 273

Re: systemd: Yet Another Init Replacement

Haven't yet switched to this so I have a few questions...
First off, is it pretty much just a drop-in replacement? As in I don't need to configure tons of stuff?

Offline

#724 2011-06-10 16:10:25

James_Eder
Member
From: usa
Registered: 2011-05-19
Posts: 14

Re: systemd: Yet Another Init Replacement

Arm-the-Homeless wrote:

Haven't yet switched to this so I have a few questions...
First off, is it pretty much just a drop-in replacement? As in I don't need to configure tons of stuff?

https://wiki.archlinux.org/index.php/Systemd

How much you configure is up to you, but to get the most out of systemd there is a fair amount of configuring you can do.  The Wiki page is a great place to start and there's a lot of great documentation linked to at the bottom of the article.

As the Wiki article points out, you can install systemd side by side with Arch's default init system and you can switch between them at boot with the appropriate grub configuration.  So, there's not a lot of risk in just trying it out, but do help yourself to the fine documentation.

Offline

#725 2011-06-11 12:49:13

jnguyen
Member
Registered: 2011-02-17
Posts: 139
Website

Re: systemd: Yet Another Init Replacement

Many thanks falconindy for your quality systemd packages.

Using systemd and it's own readahead implementation (which couldn't be simpler to setup), the time from entering my LUKS key to having firefox open has been halved from 20 seconds to 10 seconds, and that's on a regular HDD (not SSD) smile

For anyone who has LUKS system encryption, this bug report may be relevant to you. /etc/rc.conf is parsed by mkinitcpio for KEYMAP, and I proposed a patch to make mkinitcpio parse /etc/vconsole.conf instead if it exists. I was puzzled for quite a while when my LUKS key wasn't accepted roll


TOMOYO Linux: Mandatory Access Control.
My AUR packages

Offline

Board footer

Powered by FluxBB