Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
2013/1/28 Mike Gilbert flop...@gentoo.org On Sun, Jan 27, 2013 at 10:07 PM, João Matos jaon...@gmail.com wrote: title Gentoo Linux 3.7.1 systemd root (hd0,0) kernel /boot/thekernel2 root=/dev/sda1 rootfstype=ext4 init=/bin/systemd vga=0x31B resume=/dev/sda3 journalctl -b Why do you have journalctl -b in there? That makes no sense. Also, the -b is what is causing systemd to start emergency.target. Well, removing it did solve my problem! The interesting fact is that the problem started, but I had no log info during the boot process. So I put journalctl -b to see the boot info. Since them I have the boot info (not just a black screen). Probably the problem was solved long time ago and the -b didn't let me notice it. Thank you. :) -- João de Matos Linux User #461527 Graduando em Engenharia de Computação 2005.1 UEFS - Universidade Estadual de Feira de Santana
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
Am 27.01.2013 22:08, schrieb Canek Peláez Valdés: udev-197 in the tree installs everything to /; systemd-197 installs to /usr. I'm pretty sure that is not going to end well; I haven't upgraded to 197 in neither package. forking this thread: decided to give systemd another chance here and edited my $USE in make.conf: ... -consolekit systemd ... (correct?) emerge -avuDN world ... now brought me systemd-197-r1 which booted OK here. I have issues with starting the rebuilt gdm now, maybe related to the consolekit-issue? My /etc/systemd has to be cleaned up as it contains stuff from back then and I have to get network etc. configured right. But overall it booted OK ... Stefan
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
On Mon, Jan 28, 2013 at 1:01 PM, Stefan G. Weichinger li...@xunil.at wrote: Am 27.01.2013 22:08, schrieb Canek Peláez Valdés: udev-197 in the tree installs everything to /; systemd-197 installs to /usr. I'm pretty sure that is not going to end well; I haven't upgraded to 197 in neither package. forking this thread: decided to give systemd another chance here and edited my $USE in make.conf: ... -consolekit systemd ... (correct?) emerge -avuDN world ... now brought me systemd-197-r1 which booted OK here. I have issues with starting the rebuilt gdm now, maybe related to the consolekit-issue? My /etc/systemd has to be cleaned up as it contains stuff from back then and I have to get network etc. configured right. But overall it booted OK ... I saw that mgorny unmasked systemd, and I'm installing it as of right now. I hope to have no problems, but I still don't know how they managed to install udev in / and systemd in /usr without problems. Perhaps it will just work as long as /usr is not in its own partition, or you use an initramfs. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
Am 28.01.2013 20:08, schrieb Canek Peláez Valdés: I saw that mgorny unmasked systemd, and I'm installing it as of right now. I hope to have no problems, but I still don't know how they managed to install udev in / and systemd in /usr without problems. Perhaps it will just work as long as /usr is not in its own partition, or you use an initramfs. I don't have /usr separated so it doesn't matter for me right now. Do you use gnome/gdm? If yes, would you share use-flags and service-file? Thanks! Stefan
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
On Mon, Jan 28, 2013 at 1:25 PM, Stefan G. Weichinger li...@xunil.at wrote:
Am 28.01.2013 20:08, schrieb Canek Peláez Valdés:
I saw that mgorny unmasked systemd, and I'm installing it as of right
now. I hope to have no problems, but I still don't know how they
managed to install udev in / and systemd in /usr without problems.
Perhaps it will just work as long as /usr is not in its own
partition, or you use an initramfs.
I don't have /usr separated so it doesn't matter for me right now.
Do you use gnome/gdm? If yes, would you share use-flags and
service-file? Thanks!
I just booted with udev/systemd-197. The only error was:
Failed at step EXEC spawning /usr/bin/udevadm: No such file or directory
Which was kinda what I was expecting, since udevadm moved to /bin.
However, everything (except plymouth-start.service) works. The error
happens inside the initramfs, just before the switch-root, so perhaps
I can fix it by putting a link to udevadm in /usr/bin in my initramfs.
My gdm USE-flags are:
[ebuild R ~] gnome-base/gdm-3.6.2 USE=audit fallback gnome-shell
introspection ipv6 ldap plymouth systemd tcpd -accessibility
-consolekit -debug -fprint (-selinux) -smartcard {-test} -xinerama 0
kB
The service file is the one the package provides. I have gdm.service
as display-manager.service:
# ls -l /etc/systemd/system/display-manager.service
lrwxrwxrwx 1 root root 37 Oct 13 16:48
/etc/systemd/system/display-manager.service -
/usr/lib64/systemd/system/gdm.service
Nothing else, AFAICS.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
On Mon, Jan 28, 2013 at 1:34 PM, Canek Peláez Valdés can...@gmail.com wrote: On Mon, Jan 28, 2013 at 1:25 PM, Stefan G. Weichinger li...@xunil.at wrote: Am 28.01.2013 20:08, schrieb Canek Peláez Valdés: I saw that mgorny unmasked systemd, and I'm installing it as of right now. I hope to have no problems, but I still don't know how they managed to install udev in / and systemd in /usr without problems. Perhaps it will just work as long as /usr is not in its own partition, or you use an initramfs. I don't have /usr separated so it doesn't matter for me right now. Do you use gnome/gdm? If yes, would you share use-flags and service-file? Thanks! I just booted with udev/systemd-197. The only error was: Failed at step EXEC spawning /usr/bin/udevadm: No such file or directory Which was kinda what I was expecting, since udevadm moved to /bin. However, everything (except plymouth-start.service) works. The error happens inside the initramfs, just before the switch-root, so perhaps I can fix it by putting a link to udevadm in /usr/bin in my initramfs. I had to put the link in both the initramfs (made a trivial dracut module to do it), and in the filesystem. The error went away, and everything works, including plymouth-start.service (I don't know why I still have it, my laptop boots so fast I almost don't see the splash). I have zero failed units in systemctl --full --all. I also took the plunge and removed both 70-persistent-net.rules 80-net-name-slot.rules; my laptop uses NetworkManager, so everything just keep working, but now my network interfaces have silly new names: # ifconfig | grep UP enp0s25: flags=4099UP,BROADCAST,MULTICAST mtu 1500 lo: flags=73UP,LOOPBACK,RUNNING mtu 65536 wlp2s0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 So the only problem was udevadm in /bin instead of /usr/bin, but apparently (in my laptop at least) only plymouth-start.service needs it. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
Am 28.01.2013 20:34, schrieb Canek Peláez Valdés:
My gdm USE-flags are:
[ebuild R ~] gnome-base/gdm-3.6.2 USE=audit fallback gnome-shell
introspection ipv6 ldap plymouth systemd tcpd -accessibility
-consolekit -debug -fprint (-selinux) -smartcard {-test} -xinerama 0
kB
The service file is the one the package provides. I have gdm.service
as display-manager.service:
# ls -l /etc/systemd/system/display-manager.service
lrwxrwxrwx 1 root root 37 Oct 13 16:48
/etc/systemd/system/display-manager.service -
/usr/lib64/systemd/system/gdm.service
Nothing else, AFAICS.
Thanks. Same here, afaik.
I now get gdm up but I get thrown back after entering my (correct) password.
with xdm.service I am able to start gnome.
Do I have to take special care of polkit/consolekit/pam/whatever?
Thanks, Stefan
ps: my bigger hurdle will be the bridging-setup for running
KVM-virtualization. This was one of the reasons to go back to openrc
back then.
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
2013/1/28 Stefan G. Weichinger li...@xunil.at Am 27.01.2013 22:08, schrieb Canek Peláez Valdés: udev-197 in the tree installs everything to /; systemd-197 installs to /usr. I'm pretty sure that is not going to end well; I haven't upgraded to 197 in neither package. forking this thread: decided to give systemd another chance here and edited my $USE in make.conf: ... -consolekit systemd ... (correct?) Try emerge --info | grep consolekit and see if is everything ok. In my case it isn't, so I filled a bug: https://bugs.gentoo.org/show_bug.cgi?id=45 emerge -avuDN world ... now brought me systemd-197-r1 which booted OK here. I have issues with starting the rebuilt gdm now, maybe related to the consolekit-issue? My /etc/systemd has to be cleaned up as it contains stuff from back then and I have to get network etc. configured right. But overall it booted OK ... Stefan -- João de Matos Linux User #461527 Graduando em Engenharia de Computação 2005.1 UEFS - Universidade Estadual de Feira de Santana
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
On Mon, Jan 28, 2013 at 3:08 PM, Stefan G. Weichinger li...@xunil.at wrote:
Am 28.01.2013 20:34, schrieb Canek Peláez Valdés:
My gdm USE-flags are:
[ebuild R ~] gnome-base/gdm-3.6.2 USE=audit fallback gnome-shell
introspection ipv6 ldap plymouth systemd tcpd -accessibility
-consolekit -debug -fprint (-selinux) -smartcard {-test} -xinerama 0
kB
The service file is the one the package provides. I have gdm.service
as display-manager.service:
# ls -l /etc/systemd/system/display-manager.service
lrwxrwxrwx 1 root root 37 Oct 13 16:48
/etc/systemd/system/display-manager.service -
/usr/lib64/systemd/system/gdm.service
Nothing else, AFAICS.
Thanks. Same here, afaik.
I now get gdm up but I get thrown back after entering my (correct) password.
with xdm.service I am able to start gnome.
Do I have to take special care of polkit/consolekit/pam/whatever?
Yes, we had a long thread about that some months ago, around November.
Basically, there is lots of stuff that break if you mix up consolekit
and systemd (logind, actually). Maybe the situation has improved, but
in my case the simplest solution was to purge consolekit from my
systems (except in my media center, XBMC still uses its d-bus
interfaces). ConsoleKit is unmantained anyway.
I have USE=-consolekit where necessary (basically gdm, pambase and
bluez), and USE=systemd everywhere else. Please note that some
packages need to unmask the systemd flag:
# cat /etc/portage/profile/package.use.mask
media-sound/pulseaudio -systemd
net-misc/networkmanager -systemd
sys-auth/polkit -systemd
sys-fs/udisks -systemd
sys-power/upower-systemd
I believe polkit is the most important, since it's the one controlling
what program can do what, but since I switched completely to systemd
years ago, I just use it everywhere. Things just work most of the
time.
Thanks, Stefan
ps: my bigger hurdle will be the bridging-setup for running
KVM-virtualization. This was one of the reasons to go back to openrc
back then.
I have no experience with that, but if it works in OpenRC it should
work in systemd. Probably better, even.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
Am 28.01.2013 22:27, schrieb Canek Peláez Valdés: On Mon, Jan 28, 2013 at 3:08 PM, Stefan G. Weichinger li...@xunil.at wrote: Do I have to take special care of polkit/consolekit/pam/whatever? Yes, we had a long thread about that some months ago, around November. Basically, there is lots of stuff that break if you mix up consolekit and systemd (logind, actually). Maybe the situation has improved, but in my case the simplest solution was to purge consolekit from my systems (except in my media center, XBMC still uses its d-bus interfaces). ConsoleKit is unmantained anyway. I removed consolekit already and I right now recompile all the packages depending on it. I have USE=-consolekit where necessary (basically gdm, pambase and bluez), and USE=systemd everywhere else. Please note that some packages need to unmask the systemd flag: # cat /etc/portage/profile/package.use.mask media-sound/pulseaudio-systemd net-misc/networkmanager -systemd sys-auth/polkit -systemd sys-fs/udisks -systemd sys-power/upower -systemd Followed that as well, thanks. I believe polkit is the most important, since it's the one controlling what program can do what, but since I switched completely to systemd years ago, I just use it everywhere. Things just work most of the time. The logs make me assume that pulseaudio/dbus/bluez drops me out of my session ... although if I use xdm to login, things work fine. No big deal, but gdm is nicer and it just should be possible to use it correctly with systemd. I will dig further ... Thanks, Stefan ps: my bigger hurdle will be the bridging-setup for running KVM-virtualization. This was one of the reasons to go back to openrc back then. I have no experience with that, but if it works in OpenRC it should work in systemd. Probably better, even. I don't think it won't work, I just wonder how to do it in the right and most efficient way. I will think about that later/tomorrow maybe, already late here ... Best regards, Stefan
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
On Sun, Jan 27, 2013 at 12:31 PM, João Matos jaon...@gmail.com wrote: 2013/1/26 Canek Peláez Valdés can...@gmail.com On Sat, Jan 26, 2013 at 7:08 PM, João Matos jaon...@gmail.com wrote: Hi list, I'm having this problem for a while, but I've decided to solve it know. Every time I boot my system (couple times a day), I have to hid Ctrl + D when the boot process is interrupted by the emergency mode. I think it started when I was compiling the kernel myself, and removing lot of stuff. Although, I checked and the mandatory options for systemd are ok. When I run journalctl -b -p err the only information I get is: Jan 26 20:29:20 KONOHA NetworkManager[1497]: claim_connection: assertion `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed Jan 26 20:29:24 localhost dhcpcd[1557]: wlan0: sendmsg: Cannot assign requested address Jan 26 20:30:42 localhost pulseaudio[2073]: [pulseaudio] pid.c: Daemon already running. Jan 26 20:30:42 localhost pulseaudio[2080]: [pulseaudio] pid.c: Daemon already running. It give me no clue. Attached the .conf from my gentoo-3.7.1 After I hit Ctrl + D, the system works normally. Any help will be appreciated :) Are you using udev-197 with systemd-197? mgorny masked it, and said this in package.mask: I'm using them. Last time I updated my system there weren't any warning. Anyway, this problem is happening since the previous version. # Does not boot. Something with udev is probably broken. Feel free # to unmask, debug and provide me with a patch. You need to be using the same version for udev and systemd (they are the same package). If you are using the same version for udev and systemd, are you using an initramfs? When was the last time you built it, if you do? I don't have initramfs. Just the kernel. But it used to work normaly. Could you boot with systemd.log_target=kmsg and systemd.log_level=debug, and post the whole output of journalctl -b? It prints only the logs from the last boot. journalctl -b attached. From your logs: Jan 27 15:16:27 KONOHA systemd[1]: Activating default unit: emergency.target You have emergency.target as default unit. The default.target can be set in different ways: - Check /usr/lib64/systemd/system/default.target - Check /etc/systemd/system/default.target - Check if you use --unit=emergency.target in your grub config - Check if you pass the emergency kernel parametr in your grub config udev-197 in the tree installs everything to /; systemd-197 installs to /usr. I'm pretty sure that is not going to end well; I haven't upgraded to 197 in neither package. Check your default.target; for some reason is set to emergency. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
2013/1/27 Canek Peláez Valdés can...@gmail.com On Sun, Jan 27, 2013 at 12:31 PM, João Matos jaon...@gmail.com wrote: 2013/1/26 Canek Peláez Valdés can...@gmail.com On Sat, Jan 26, 2013 at 7:08 PM, João Matos jaon...@gmail.com wrote: Hi list, I'm having this problem for a while, but I've decided to solve it know. Every time I boot my system (couple times a day), I have to hid Ctrl + D when the boot process is interrupted by the emergency mode. I think it started when I was compiling the kernel myself, and removing lot of stuff. Although, I checked and the mandatory options for systemd are ok. When I run journalctl -b -p err the only information I get is: Jan 26 20:29:20 KONOHA NetworkManager[1497]: claim_connection: assertion `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed Jan 26 20:29:24 localhost dhcpcd[1557]: wlan0: sendmsg: Cannot assign requested address Jan 26 20:30:42 localhost pulseaudio[2073]: [pulseaudio] pid.c: Daemon already running. Jan 26 20:30:42 localhost pulseaudio[2080]: [pulseaudio] pid.c: Daemon already running. It give me no clue. Attached the .conf from my gentoo-3.7.1 After I hit Ctrl + D, the system works normally. Any help will be appreciated :) Are you using udev-197 with systemd-197? mgorny masked it, and said this in package.mask: I'm using them. Last time I updated my system there weren't any warning. Anyway, this problem is happening since the previous version. # Does not boot. Something with udev is probably broken. Feel free # to unmask, debug and provide me with a patch. You need to be using the same version for udev and systemd (they are the same package). If you are using the same version for udev and systemd, are you using an initramfs? When was the last time you built it, if you do? I don't have initramfs. Just the kernel. But it used to work normaly. Could you boot with systemd.log_target=kmsg and systemd.log_level=debug, and post the whole output of journalctl -b? It prints only the logs from the last boot. journalctl -b attached. From your logs: Jan 27 15:16:27 KONOHA systemd[1]: Activating default unit: emergency.target You have emergency.target as default unit. The default.target can be set in different ways: - Check /usr/lib64/systemd/system/default.target Nothing found here. The file is: [Unit] Description=Graphical Interface Documentation=man:systemd.special(7) Requires=multi-user.target After=multi-user.target Conflicts=rescue.target Wants=display-manager.service AllowIsolate=yes [Install] Alias=default.target - Check /etc/systemd/system/default.target doesn't exist. - Check if you use --unit=emergency.target in your grub config - Check if you pass the emergency kernel parametr in your grub config Nothing wrong with grub. udev-197 in the tree installs everything to /; systemd-197 installs to /usr. I'm pretty sure that is not going to end well; I haven't upgraded to 197 in neither package. Check your default.target; for some reason is set to emergency. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México I've also tryed systemctl disable emergency.service and systemctl disable emergency.target before but got nothing. Anyway, thank you for your help :). I'll try to downgrade. But I still think it is about kernel config. -- João de Matos Linux User #461527 Graduando em Engenharia de Computação 2005.1 UEFS - Universidade Estadual de Feira de Santana
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
Is there any way it is not in the default mode? when it stoped, instead of hitting Ctrl D, I taped my password and systemctl default, so it could try to start again the default boot process. And it worked. I'll not try the downgrade right now bcz, after a emerge --sync, my portage started do complain about compiling net-misc/networkmanager with support for both systemd and consolekit, but I'm not able to disable consolekit support. So I'll wait them to fix it. 2013/1/27 João Matos jaon...@gmail.com 2013/1/27 Canek Peláez Valdés can...@gmail.com On Sun, Jan 27, 2013 at 12:31 PM, João Matos jaon...@gmail.com wrote: 2013/1/26 Canek Peláez Valdés can...@gmail.com On Sat, Jan 26, 2013 at 7:08 PM, João Matos jaon...@gmail.com wrote: Hi list, I'm having this problem for a while, but I've decided to solve it know. Every time I boot my system (couple times a day), I have to hid Ctrl + D when the boot process is interrupted by the emergency mode. I think it started when I was compiling the kernel myself, and removing lot of stuff. Although, I checked and the mandatory options for systemd are ok. When I run journalctl -b -p err the only information I get is: Jan 26 20:29:20 KONOHA NetworkManager[1497]: claim_connection: assertion `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed Jan 26 20:29:24 localhost dhcpcd[1557]: wlan0: sendmsg: Cannot assign requested address Jan 26 20:30:42 localhost pulseaudio[2073]: [pulseaudio] pid.c: Daemon already running. Jan 26 20:30:42 localhost pulseaudio[2080]: [pulseaudio] pid.c: Daemon already running. It give me no clue. Attached the .conf from my gentoo-3.7.1 After I hit Ctrl + D, the system works normally. Any help will be appreciated :) Are you using udev-197 with systemd-197? mgorny masked it, and said this in package.mask: I'm using them. Last time I updated my system there weren't any warning. Anyway, this problem is happening since the previous version. # Does not boot. Something with udev is probably broken. Feel free # to unmask, debug and provide me with a patch. You need to be using the same version for udev and systemd (they are the same package). If you are using the same version for udev and systemd, are you using an initramfs? When was the last time you built it, if you do? I don't have initramfs. Just the kernel. But it used to work normaly. Could you boot with systemd.log_target=kmsg and systemd.log_level=debug, and post the whole output of journalctl -b? It prints only the logs from the last boot. journalctl -b attached. From your logs: Jan 27 15:16:27 KONOHA systemd[1]: Activating default unit: emergency.target You have emergency.target as default unit. The default.target can be set in different ways: - Check /usr/lib64/systemd/system/default.target Nothing found here. The file is: [Unit] Description=Graphical Interface Documentation=man:systemd.special(7) Requires=multi-user.target After=multi-user.target Conflicts=rescue.target Wants=display-manager.service AllowIsolate=yes [Install] Alias=default.target - Check /etc/systemd/system/default.target doesn't exist. - Check if you use --unit=emergency.target in your grub config - Check if you pass the emergency kernel parametr in your grub config Nothing wrong with grub. udev-197 in the tree installs everything to /; systemd-197 installs to /usr. I'm pretty sure that is not going to end well; I haven't upgraded to 197 in neither package. Check your default.target; for some reason is set to emergency. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México I've also tryed systemctl disable emergency.service and systemctl disable emergency.target before but got nothing. Anyway, thank you for your help :). I'll try to downgrade. But I still think it is about kernel config. -- João de Matos Linux User #461527 Graduando em Engenharia de Computação 2005.1 UEFS - Universidade Estadual de Feira de Santana -- João de Matos Linux User #461527 Graduando em Engenharia de Computação 2005.1 UEFS - Universidade Estadual de Feira de Santana
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
On Sun, Jan 27, 2013 at 5:14 PM, João Matos jaon...@gmail.com wrote: Is there any way it is not in the default mode? Can you post your complete kernel command line?
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
title Gentoo Linux 3.7.1 systemd root (hd0,0) kernel /boot/thekernel2 root=/dev/sda1 rootfstype=ext4 init=/bin/systemd vga=0x31B resume=/dev/sda3 journalctl -b 2013/1/27 Mike Gilbert flop...@gentoo.org On Sun, Jan 27, 2013 at 5:14 PM, João Matos jaon...@gmail.com wrote: Is there any way it is not in the default mode? Can you post your complete kernel command line? -- João de Matos Linux User #461527 Graduando em Engenharia de Computação 2005.1 UEFS - Universidade Estadual de Feira de Santana
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
On Sun, Jan 27, 2013 at 10:07 PM, João Matos jaon...@gmail.com wrote: title Gentoo Linux 3.7.1 systemd root (hd0,0) kernel /boot/thekernel2 root=/dev/sda1 rootfstype=ext4 init=/bin/systemd vga=0x31B resume=/dev/sda3 journalctl -b Why do you have journalctl -b in there? That makes no sense. Also, the -b is what is causing systemd to start emergency.target.
Re: [gentoo-user] Systemd reaches target Emergency Mode every boot
On Sat, Jan 26, 2013 at 7:08 PM, João Matos jaon...@gmail.com wrote: Hi list, I'm having this problem for a while, but I've decided to solve it know. Every time I boot my system (couple times a day), I have to hid Ctrl + D when the boot process is interrupted by the emergency mode. I think it started when I was compiling the kernel myself, and removing lot of stuff. Although, I checked and the mandatory options for systemd are ok. When I run journalctl -b -p err the only information I get is: Jan 26 20:29:20 KONOHA NetworkManager[1497]: claim_connection: assertion `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed Jan 26 20:29:24 localhost dhcpcd[1557]: wlan0: sendmsg: Cannot assign requested address Jan 26 20:30:42 localhost pulseaudio[2073]: [pulseaudio] pid.c: Daemon already running. Jan 26 20:30:42 localhost pulseaudio[2080]: [pulseaudio] pid.c: Daemon already running. It give me no clue. Attached the .conf from my gentoo-3.7.1 After I hit Ctrl + D, the system works normally. Any help will be appreciated :) Are you using udev-197 with systemd-197? mgorny masked it, and said this in package.mask: # Does not boot. Something with udev is probably broken. Feel free # to unmask, debug and provide me with a patch. You need to be using the same version for udev and systemd (they are the same package). If you are using the same version for udev and systemd, are you using an initramfs? When was the last time you built it, if you do? Could you boot with systemd.log_target=kmsg and systemd.log_level=debug, and post the whole output of journalctl -b? It prints only the logs from the last boot. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
