| Message ID | 20161105125511.29383-4-mbakke@fastmail.com |
|---|---|
| State | New |
| Headers | show |
Marius Bakke <mbakke@fastmail.com> skribis: > * gnu/build/file-systems.scm (check-file-system): Drop "-C" argument > from fsck for compatibility with other fscks. Oh so fsck.ext2 would no longer show any kind of progress report? That’s annoying. Could we address it differently? Not sure how, though. Thanks, Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Marius Bakke <mbakke@fastmail.com> skribis: > >> * gnu/build/file-systems.scm (check-file-system): Drop "-C" argument >> from fsck for compatibility with other fscks. > > Oh so fsck.ext2 would no longer show any kind of progress report? > That’s annoying. > > Could we address it differently? Not sure how, though. We would have to provide a custom check-file-system procedure for each detected file-system. That might be needed in the long run anyway, but I think this is a worthwhile compromise for now. I will push the okayed parts of this series tomorrow evening (with fixes), unless there are further comments.
Hey! Marius Bakke <mbakke@fastmail.com> skribis: > Ludovic Courtès <ludo@gnu.org> writes: > >> Marius Bakke <mbakke@fastmail.com> skribis: >> >>> * gnu/build/file-systems.scm (check-file-system): Drop "-C" argument >>> from fsck for compatibility with other fscks. >> >> Oh so fsck.ext2 would no longer show any kind of progress report? >> That’s annoying. >> >> Could we address it differently? Not sure how, though. > > We would have to provide a custom check-file-system procedure for each > detected file-system. That might be needed in the long run anyway, but I > think this is a worthwhile compromise for now. What about adding a one-argument procedure as the ‘check-procedure’ field of <file-system>, with a sane default, like: (define (default-file-system-check file-system) #~(system* (string-append "fsck." #$(file-system-type file-system)) …)) ? In fact, that would also remove the need for the special case to add dosfstools to the initrd because we could simply write: (define (fat-file-system-check file-system) #~(system* #$(file-append vfatfsck/static "/bin/fsck.vfat") …)) and that would automatically bring vfatfsck/static to the initrd when it’s needed, and only then. WDYT? (Same design pattern as ‘open’ in <device-mapping>.) > I will push the okayed parts of this series tomorrow evening (with > fixes), unless there are further comments. Cool, thanks! Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Hey! > > Marius Bakke <mbakke@fastmail.com> skribis: > >> Ludovic Courtès <ludo@gnu.org> writes: >> >>> Marius Bakke <mbakke@fastmail.com> skribis: >>> >>>> * gnu/build/file-systems.scm (check-file-system): Drop "-C" argument >>>> from fsck for compatibility with other fscks. >>> >>> Oh so fsck.ext2 would no longer show any kind of progress report? >>> That’s annoying. >>> >>> Could we address it differently? Not sure how, though. >> >> We would have to provide a custom check-file-system procedure for each >> detected file-system. That might be needed in the long run anyway, but I >> think this is a worthwhile compromise for now. > > What about adding a one-argument procedure as the ‘check-procedure’ > field of <file-system>, with a sane default, like: > > (define (default-file-system-check file-system) > #~(system* (string-append "fsck." #$(file-system-type file-system)) > …)) > > ? > > In fact, that would also remove the need for the special case to add > dosfstools to the initrd because we could simply write: > > (define (fat-file-system-check file-system) > #~(system* #$(file-append vfatfsck/static "/bin/fsck.vfat") > …)) > > and that would automatically bring vfatfsck/static to the initrd when > it’s needed, and only then. > > WDYT? > > (Same design pattern as ‘open’ in <device-mapping>.) This looks very promising. Will try to make it work -- new patches hopefully later this week! :)
Hi, why not just use "fsck -t xxx" instead? It will filter out "-C" for fscks which don't support it.
Danny Milosavljevic <dannym@scratchpost.org> writes: > Hi, > > why not just use "fsck -t xxx" instead? It will filter out "-C" for > fscks which don't support it. I think pending a proper solution for handling fsck commands, offloading it to util-linux is a decent compromise. Ludo, WDYT?
Marius Bakke <mbakke@fastmail.com> skribis: > Danny Milosavljevic <dannym@scratchpost.org> writes: > >> Hi, >> >> why not just use "fsck -t xxx" instead? It will filter out "-C" for >> fscks which don't support it. > > I think pending a proper solution for handling fsck commands, offloading > it to util-linux is a decent compromise. Ludo, WDYT? I think the problem is that until d9804e5011a58341aafbf4fadd00947f3e5f436e (in core-updates), ‘mount’ from util-linux could not find those programs: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25043 I’d expect it to be the same for ‘fsck’. But anyway, we might just as well do the dispatch ourselves like discussed at <https://lists.gnu.org/archive/html/guix-devel/2016-12/msg00095.html>. Thoughts? Thanks, Ludo’.
diff --git a/gnu/build/file-systems.scm b/gnu/build/file-systems.scm index bfc353a..30abe94 100644 --- a/gnu/build/file-systems.scm +++ b/gnu/build/file-systems.scm @@ -415,7 +415,7 @@ the following: (define fsck (string-append "fsck." type)) - (let ((status (system* fsck "-v" "-p" "-C" "0" device))) + (let ((status (system* fsck "-v" "-p" device))) (match (status:exit-val status) (0 #t)