FS#16167 - [initscripts] Allowing a forced filesystem check directly from grub

Attached to Project: Arch Linux
Opened by Olive (olivel) - Sunday, 13 September 2009, 06:14 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 27 March 2011, 11:44 GMT
Task Type Feature Request
Category Initscripts
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

It should be a good idea to allow a forced filesystem check directly from grub. The tiny patch I attach to apply to /etc/rc.sysinit force a filesystem check when the option forcefsck=1 is appended to the kernel command line.

package version: initscripts 2009.08-1
This task depends upon

Closed by  Tom Gundersen (tomegun)
Sunday, 27 March 2011, 11:44 GMT
Reason for closing:  Fixed
Comment by Olive (olivel) - Sunday, 13 September 2009, 06:21 GMT
Oupss, my patch has not been attached. Here it is...
Comment by Thomas Bächler (brain0) - Monday, 21 September 2009, 22:59 GMT
Looks good. Are variable from the kernel commandline even exported to the environment? I would have thought we need to grep /proc/cmdline for "forcefsck".
Comment by Aaron Griffin (phrakture) - Monday, 21 September 2009, 23:22 GMT
Yeah I think we need to grep /proc/cmdline for this one.

Still, I like it. Please provide a git patch so we can get proper attribution and all that fun stuff

http://wiki.archlinux.org/index.php/Super_Quick_Git_Guide
http://projects.archlinux.org/?p=initscripts.git;a=summary
Comment by Olive (olivel) - Tuesday, 22 September 2009, 04:30 GMT
The kernel export to the environment any variable of the form variable=xxx (with the exception of some "variables" reserved for the kernel: root, etc). see:

http://www.kernel.org/doc/Documentation/kernel-parameters.txt (and make a search on "environment variable")

I have tested my patch and it works.

(note that the tools to log user in such as agetty reset the environment so these variables are not normally seen by users but they are seen by the initscripts)
Comment by Aaron Griffin (phrakture) - Tuesday, 22 September 2009, 16:36 GMT
Just to reiterate: providing a git patch is preferred and will get your patch accepted faster
Comment by Paul Mattal (paul) - Saturday, 06 March 2010, 03:21 GMT
What's the status on this one? Are we waiting for a git patch to implement this? If so, I can generate one.
Comment by christopher rogers (godane) - Saturday, 05 June 2010, 21:35 GMT
I have a git version of your patch. Its best i could do.

PS I had to search for 10 mins since i could read the first patch. I also was check if it was added into git repo already.

I hope this helps.
Comment by christopher rogers (godane) - Saturday, 05 June 2010, 21:44 GMT
Never mind the above patch. Here is the format one that you guys wanted.
Comment by Søren Poulsen (nikor) - Friday, 18 February 2011, 18:17 GMT
There was a small conflict with a newer commit.

This works for me as well.
Comment by CalimeroTeknik (Calimero) - Saturday, 19 February 2011, 18:55 GMT
In my opinion, this should be done in an initscript hook.
You know, the (personal config) files located in /etc/rc.d/functions.d/
Comment by Søren Poulsen (nikor) - Saturday, 19 February 2011, 22:52 GMT
CalimeroTeknik: The hook discussion is, as you mentioned on irc, a trade off between bloating the initscripts vs having features by default. I don't care, I'm just trying to fix the bug/feature request to be one of the cool kids on bug day :)
Comment by Olive (olivel) - Sunday, 20 February 2011, 21:47 GMT
In my opinion, making a hook complicate the things too much (for a KISS distribution like archlinux). There is already a forced filesystem check if there is a /forcefsck in the filesystem without providing a hook, for this. Why one would one to not have this feature? In this case just don't have a menu entry with forcefck=...
Comment by Sébastien Luttringer (seblu) - Friday, 04 March 2011, 00:17 GMT

Loading...