Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 401541 - sys-kernel/dracut-014-r1 - endless reboots when /forcefsck exists
Summary: sys-kernel/dracut-014-r1 - endless reboots when /forcefsck exists
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Amadeusz Żołnowski (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-30 16:15 UTC by Marcin Mirosław
Modified: 2012-08-01 14:11 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Mirosław 2012-01-30 16:15:26 UTC
When i touch /forcefsck and reboot system, i'm geting: Filesystem was repaired but reboot is needed. OS reboots and situation happens again, reboot and reboot...
/ is ext4 on md raid1, 1.2 metadata version.
I don't know what other information would be usefull, this is why description is so short.


Reproducible: Always




# emerge --info
FEATURES variable contains unknown value(s): Xsplitdebug, Yfail-clean, Yuserpriv
Portage 2.1.10.44 (hardened/linux/amd64, gcc-4.5.3, glibc-2.13-r4, 3.2.1-gentoo-r2 x86_64)
=================================================================
System uname: Linux-3.2.1-gentoo-r2-x86_64-Intel-R-_Core-TM-2_CPU_4300_@_1.80GHz-with-gentoo-2.0.3
Timestamp of tree: Mon, 30 Jan 2012 14:15:01 +0000
ccache version 3.1.7 [enabled]
app-shells/bash:          4.1_p9
dev-lang/python:          2.7.2-r3, 3.1.4-r3
dev-util/ccache:          3.1.7
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.0.3
sys-apps/openrc:          0.9.8.2
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.68
sys-devel/automake:       1.11.1
sys-devel/binutils:       2.21.1-r1
sys-devel/gcc:            4.5.3-r2
sys-devel/gcc-config:     1.4.1-r1
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r1
sys-kernel/linux-headers: 3.1 (virtual/os-headers)
sys-libs/glibc:           2.13-r4
Repositories: gentoo horhe zfs
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=native -s"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa /var/bind"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -march=native -s"
DISTDIR="/usr/portage/distfiles"
FEATURES="Xsplitdebug Yfail-clean Yuserpriv assume-digests binpkg-logs ccache collision-protect distlocks ebuild-locks fixlafiles news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch usersandbox usersync"
FFLAGS=""
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="pl_PL.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en pl"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_EXTRA_OPTS="-O"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/var/lib/layman/zfs"
SYNC="rsync://ftp.vectranet.pl/gentoo-portage/"
USE="acpi amd64 bash-completion caps hardened ipv6 mmx mmxext multilib openmp sse sse2 sse3 ssse3 threads unicode urandom vim-syntax" DRACUT_MODULES="caps mdraid" ELIBC="glibc" GRUB_PLATFORMS="pc" KERNEL="linux" LINGUAS="en pl" USERLAND="GNU" XTABLES_ADDONS="tarpit"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS
Comment 1 Amadeusz Żołnowski (RETIRED) gentoo-dev 2012-02-19 13:59:40 UTC
Dracut should ask you before reboot to perform it. Didn't it? Can you reproduce this problem with 016?
Comment 2 Marcin Mirosław 2012-02-19 22:36:11 UTC
With 016 nothing changed. Now i can see i should be more precise in description. All cycle looks like that:
a) kernel starts
b) in the meantime appears line from dracut:
dracut: issuing e2fsck -f on ....(i don't remember all line)
Dracut doesn't display any other information about this e2fsck (no progress etc)
c) openrc starts
d) openrc do forced fsck on root partition
e) openrc displays message "Filesystem was repaired
but reboot is needed" and reboots host

On other host (which doesn't use dracut) i don't have such issue with /forcefsck this is why i submit bug for dracut.
Comment 3 Ulenrich 2012-02-28 17:11:22 UTC
I consider /forcefsck written on a corrupt disk is itself a bug.
openSUSE and Debian since long support a cmdline parameter forcefsck, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529498
Comment 4 Marcin Mirosław 2012-02-28 18:30:03 UTC
In my case rootfs isn't corrupted, i tested if /forcefsck works. Agree kernel boot parameter "forcefsck" is usefull.
Comment 5 Amadeusz Żołnowski (RETIRED) gentoo-dev 2012-07-31 14:48:09 UTC
(In reply to comment #2)
> With 016 nothing changed. Now i can see i should be more precise in
> description. All cycle looks like that:
> a) kernel starts
> b) in the meantime appears line from dracut:
> dracut: issuing e2fsck -f on ....(i don't remember all line)
> Dracut doesn't display any other information about this e2fsck (no progress
> etc)
> c) openrc starts
> d) openrc do forced fsck on root partition
> e) openrc displays message "Filesystem was repaired
> but reboot is needed" and reboots host

Do I understand correctly that dracut doesn't remove /forcefsck after successful fsck and therefore openrc is forced to refsck?

Does the bug still occurs with 022?  If so could you provide me /run/initramfs/dracut.log which is created when rd.debug is appended to cmdline options.
Comment 6 Marcin Mirosław 2012-08-01 12:37:39 UTC
Yes, you are right, file /forcefsck was still present. I've tried dracut-0.22-r1 and i couldn't reproduce problem. It looks it's fixed for me.
Thanks.
Comment 7 Amadeusz Żołnowski (RETIRED) gentoo-dev 2012-08-01 14:11:32 UTC
Good. :-) Closing.