OK, so there are a number of very loosely related problems here. As you can imagine, most of the are quire different, and, as you can guess, unrelated, so dealing with them all in one thread will be difficult.
Also as I do not use forums and generally find them a very clumsy interface for such discussions (I much prefer my mail client with it's proper quoting and threading support) I'll try my best to cover a few things here and hope that it helps you out.
Sound: This is just where the problem is most obviously manifest, it's not actually anything to do with sound per-se, just device permissions and user session registration. It's been covered approximately 30 times (OK, a slight exaggeration!) on different mediums (mailing list, bug reports etc.) It's is almost certainly this problem:
https://bugs.mageia.org/show_bug.cgi?id=2982 see the instructions therein to fix it. The command "systemd-loginctl" is your friend (just as ck-list-sessions was on Mageia 1).
Slow shutdowns: Have you installed dracut before the latest kernel update? Dracut is a new system for generating (the initial ramdisk used to boot your system) that replaces mkinitrd. It will become the default eventually but at the moment you can use both but with varying degrees of success. See below for recreating your initrd with dracut.
Emergency Console: If you have any file systems in your fstab that are on LVM or RAID volumes you pretty much NEED a dracut generated initrd (see above) as the information used by systemd to detect when disks are ready is all coming from udev (it can inform us of the disk availability without us having to probe and check and try, so it's a much cleaner solution). Sadly with an mkinitrd system, such systems (lvm/raid) are initialised before udev starts and the information normally injected into udev is never made available to systemd and thus it cannot start the "local-fs.target" unit. This unit times out after a while of waiting and dumps you into the emergency console. You can see if this is the issue by typing "systemctl status local-fs.target". You can test further by typing: "systemctl start local-fs.target". It should wait a while then time out. (note if you have /usr on a separate, LVM partiion, then you will not be able to run systemctl, but read on!). So, systemd cannot "see" the disks it wants to mount, but that doesn't stop you doing it manually. You can simply look at the filesystems mounted (cat /proc/mounts) and try and spot the missing ones (compare to /etc/fstab) and then type "mount /foo" (where foo is is the non-mounted file system). This should work in most cases. When you have mounted all the file systems you should be able to type "systemctl start local-fs.target" again and it should be happy and complete successfully almost instantly. If this is the case you should be able to do: systemctl start graphical.target" and you will get to your normal boot.
No network: It seems the initscript for network doesn't carry proper information about runlevels (It looks like it's there to me but go figure). So it cannot be started. You can easily enough run it (after getting to a graphical system) by running "/etc/init.d/network start" as root. This should work (not tried). However, I recommend using NetworkManager these days unless you have an exotic networking setup that will only work with old system. If you can get networking working with the above approach, then you should be able to install network manager. I think you then have to mark each interface defined as being under the control of network manager. This is achieved by adding a line with "NM_CONTROLLED=yes" to /etc/sysconfig/network-scripts/ifcfg-eth* and ifcfg-wlan* files. Make sure you do "systemctl enable NetworkManager.service" to ensure it's started at boot.
I think that covers all the problems I read here, tho there will no doubt be more. If you need to regenerate your initrd with dracut (typically needed if you get the emergency console), please see this mail:
http://www.mail-archive.com/mageia-dev@ ... 08826.html
Posted: Oct 29th, '11, 21:01
