https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c Luca Beltrame changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |fcrozat@suse.com |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c Frederic Crozat changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|fcrozat@suse.com |systemd-maintainers@suse.de -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c2 --- Comment #2 from systemd maintainers 2013-11-27 10:54:36 UTC --- Beside this on the kernels command line you may use fsck.mode=<mode> with <mode> one of auto, force, or skip. With skip you're able to skip the check to be able to boot the system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c5 systemd maintainers changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sbrabec@suse.com --- Comment #5 from systemd maintainers 2013-12-18 11:07:26 UTC --- *** Bug 849863 has been marked as a duplicate of this bug. *** http://bugzilla.novell.com/show_bug.cgi?id=849863 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c7 --- Comment #7 from systemd maintainers 2014-01-08 10:19:18 UTC --- Hmm ... currently I try to reproduce with a missing partition with a virtual system (a VirtualBox for openSUSE 13.1) and this works: [ TIME ] Timed out waiting for device dev-disk-by\x2did-ata\x...2dpart1.device. [DEPEND] Dependency failed for /usr/lib/crash. [DEPEND] Dependency failed for Local File Systems. Give root password for maintenance (or type Control-D to continue): linux:~ # on both the virtual console and the serial console ... I'll investigate further to see how I can reproduce this by using a broken file system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c9 --- Comment #9 from systemd maintainers 2014-01-08 11:37:27 UTC --- It seems to very hard to trigger ``UNEXPECTED INCONSISTENCY. RUN fsck MANUALLY'' [ OK ] Found device VBOX_HARDDISK. Starting File System Check on /dev/disk/by-id/ata-VB...973e7c-part1... systemd-fsck[353]: fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb1 systemd-fsck[353]: /dev/sdb1: [ OK ] Started File System Check on /dev/disk/by-id/ata-VBO...4e973e7c-part1. systemd-fsck[353]: The superblock could not be read or does not describe a correct ext2 Mounting /usr/lib/crash... systemd-fsck[353]: filesystem. If the device is valid and it really contains an ext2 systemd-fsck[353]: filesystem (and not swap or ufs or something else), then the superblock systemd-fsck[353]: is corrupt, and you might try running e2fsck with an alternate superblock: systemd-fsck[353]: e2fsck -b 8193 <device> [ 7.372773] EXT4-fs (sdb1): VFS: Can't find ext4 filesystem [FAILED] Failed to mount /usr/lib/crash. See 'systemctl status usr-lib-crash.mount' for details. [DEPEND] Dependency failed for Local File Systems. [ 7.387846] piix4_smbus 0000:00:07.0: SMBus base address uninitialized - upgrade BIOS or use force_addr=0xaddr Give root password for maintenance (or type Control-D to continue): linux:~ # e2fsck /dev/sdb1 [...] /dev/sdb1: ***** FILE SYSTEM WAS MODIFIED ***** /dev/sdb1: 11/131072 files (0.0% non-contiguous), 18847/524256 blocks linux:~ # exit -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c11 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arvidjaar@gmail.com --- Comment #11 from Dr. Werner Fink 2014-01-23 10:43:28 UTC --- *** Bug 852021 has been marked as a duplicate of this bug. *** http://bugzilla.novell.com/show_bug.cgi?id=852021 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c13 systemd maintainers changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |fcrozat@suse.com --- Comment #13 from systemd maintainers 2014-01-23 10:48:19 UTC --- @ Frederic : Is there any way to make emergency.target high priority that is that no service nor a target is able to can cancel a pending emergency request due a socket or similar? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c15 --- Comment #15 from Andrey Borzenkov 2014-01-23 11:24:56 UTC --- (In reply to comment #14)

Maybe we should add the line

# Don't allow logging for emergency Conflicts=emergency.target

to rsyslog.service, syslog-ng.service, and syslogd.service

This won't fix anything. syslog will be triggered by syslog.socket and will cancel running emergency shell. The correct workaround is in my repo (see bnc#852021#c4). It makes sure syslog.socket is stopped when emergency.target is entered. This was also confirmed to fix this problem by other users. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c17 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|fcrozat@suse.com |arvidjaar@gmail.com --- Comment #17 from Dr. Werner Fink 2014-01-23 11:43:48 UTC --- I'm wondering if both patches are required -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c19 --- Comment #19 from Andrey Borzenkov 2014-01-23 17:05:34 UTC --- (In reply to comment #17)

I'm wondering if both patches are required

Well ... without 0001-core-replace-OnFailureIsolate-setting-by-a-more-gene.patch there is small window after emergency.target is requested until syslog.socket is stopped. If syslog is attempted to be started exactly at this moment, it will cancel emergency.target transaction. (In reply to comment #18)

The patch 001-core-replace-OnFailureIsolate-setting-by-a-more-gene.patch does break my workaround for agetty get fooled by plymouth, compare with bnc#774126.

Now plymouth does not remove the lock on the termios structure from /dev/ttyS0 regardless how long agetty waits on.

I honestly do not see how they could be related. This patch never even kicks in in normal case. But note that it is upstream so you will get it in next systemd version anyway. If there are issues with it, they need to be fixed. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c20 --- Comment #20 from Dr. Werner Fink 2014-01-24 08:06:49 UTC --- (In reply to comment #19) IMHO this is a race which cause that plymouth hold the lock on the termios structure on /dev/ttyS0 (as this is one device of the original system consoles) even if the agetty has been started by systemd "After" plymouth-quit-wait.service. I've now tighten the workaround in agetty from util-linux, instead of using tcsendbreak() it is now using a dumb sleep: + for (i = 0; i < 20; i++) { + /* + * Even with TTYReset=no it seems with systemd or plymouth + * the termios flags become changed from under the first + * agetty on a serial system console as the flags are locked. + */ + struct termios lock; + memset(&lock, 0, sizeof(struct termios)); + if (ioctl(STDIN_FILENO, TIOCGLCKTRMIOS, &lock) < 0) + break; + if (!lock.c_iflag && !lock.c_oflag && !lock.c_cflag && !lock.c_lflag) + break; + debug("termios locked\n"); + sleep(1); + } And this does work around this race. Compare with https://bugs.freedesktop.org/show_bug.cgi?id=73585 and bug #774126 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c22 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |arvidjaar@gmail.com --- Comment #22 from Dr. Werner Fink 2014-01-24 09:04:32 UTC --- (In reply to comment #21) Compare with submit request #214778 for Base:System/systemd .. both of your two patches are part of the SR :) I've also enabled 13.1 on Base:System/systemd, have a look -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c24 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |lbeltrame@kde.org --- Comment #24 from Dr. Werner Fink 2014-02-21 17:04:30 UTC --- (In reply to comment #2) This is part of the patch 0001-core-replace-OnFailureIsolate-setting-by-a-more-gene.patch OK then this should work with the latest systemd from factory. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c25 Dave Haefner changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P0 - Crit Sit CC| |dave@itzmark.com Platform|Other |32bit AssignedTo|systemd-maintainers@suse.de |bnc-team-screening@forge.pr | |ovo.novell.com --- Comment #25 from Dave Haefner 2014-06-01 02:47:44 UTC --- (In reply to comment #0) I would like to confirm this bug and add more info: I had an HDD fail such that it could not be seen by the BIOS. On boot systemd reported an error updating the journal for this drive, brought up the "Welcome to the Emergency...." message, but refuses to allow a login. It simply goes to an infinite loop repeating the message. The system will not boot into anything, not even a recovery shell. The only solution is to boot from an external system and remove the drive from fstab if it is there. This is 100% reproducible. Fortunately this happened to a non-system drive mounted at /mnt/backup but this also means that a non-critical error prevents the system from booting. If this had happened to a RAID drive, or one drive on a btrfs or VG the system could well be unrecoverable. systemd should report the error, log it, but continue to boot. The only situation where it should not boot is if the root system will not load (obviously). sysVinit worked this way. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c27 --- Comment #27 from Maciej Pilichowski 2014-06-02 15:00:05 UTC --- I don't know how the OP, but since I fall into dup, I use 64-bit system. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=832220 https://bugzilla.novell.com/show_bug.cgi?id=832220#c29 Felix Miata changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrmazda@earthlink.net --- Comment #29 from Felix Miata 2014-07-13 18:42:05 EDT --- This is easy to reproduce with Jiri's 13.1 32 bit kernel-desktop-3.12.22, mkinitrd-2.8.1-2.1 and systemd-208-23.3. In fstab, set any non-essential, mount-at-boot, native partition to boot by volume label, then misspell the volume label in the fstab entry. That triggers an endless 4 line loop that begins with systemd-journal...received request to flush runtime journal from PID1... Upgrading to systemd-210 from the basesystem repo does allow the mount failure to eventually timeout and the rescue shell to start successfully. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=832220 Tomáš Chvátal changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jarlgjessing@gmail.com --- Comment #31 from Tomáš Chvátal --- *** Bug 855576 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.