Bug#470956: initscripts: checkroot.sh shouldn't fsck twice with /forcefsck

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#470956: initscripts: checkroot.sh shouldn't fsck twice with /forcefsck

Adrian Bunk
Package: initscripts
Version: 2.86.ds1-54
Severity: normal

I am aware that fsck of ext2 isn't fast, but that's not a reason for
doing it needlessly *twice* when the first fsck gave an error <= 3.

What happened was:
$ shutdown -F -r now
# computer reboots
# fsck of root fs
# fsck.ext2 returned error 3 (most likely since it optimized directories)
# computer automatically reboots  (everything works as expected until now)
# fsck of root fs  *grrr*



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#470956: initscripts: checkroot.sh shouldn't fsck twice with /forcefsck

Pierre Ynard-2
severity 470956 minor
tags 470956 moreinfo
thanks

> I am aware that fsck of ext2 isn't fast, but that's not a reason for
> doing it needlessly *twice* when the first fsck gave an error <= 3.
>
> What happened was:
> $ shutdown -F -r now
> # computer reboots
> # fsck of root fs
< # fsck.ext2 returned error 3 (most likely since it optimized directories)
> # computer automatically reboots  (everything works as expected until now)
> # fsck of root fs  *grrr*

I don't see how the system itself could guarantee between the two boots
that the filesystem is still clean the second time. Another OS could
have been booted instead, used the filesystem and left it dirty. The
device could have been swapped in and out of the machine, and mounted by
another system, etc...

Even we wanted initscripts to set up some flag for the next reboot,
that's not really possible because the filesystem is still read-only
at this point, and really shouldn't be touched anymore until after the
reboot.

I suppose that if anything could be done about this, it would be by fsck
utilities in the filesystem internal attributes. But I don't know which
filesystem types would be concerned by this issue and if they would
allow to address it. Ted, what do you think about this?

--
Pierre Ynard

Reply | Threaded
Open this post in threaded view
|

Bug#470956: initscripts: checkroot.sh shouldn't fsck twice with /forcefsck

Pierre Ynard-2
Oh sorry, I hadn't fully realized that as indicated by the title, this
was with /forcefsck set. In that case, as I said, since the filesystem
is still read-only, the /forcefsck flag can't be cleared - nor should
it be cleared at this point, because it covers all mounts and not just
root.

So an alternative interface to creating a /forcefsck file would have to
be used, one that doesn't reside on the filesystem itself and can be set
and cleared for individual filesystems separately - for example, the
filesystem internal data.

--
Pierre Ynard

Reply | Threaded
Open this post in threaded view
|

Bug#470956: initscripts: checkroot.sh shouldn't fsck twice with /forcefsck

Adrian Bunk-3
In reply to this post by Pierre Ynard-2
Control: tags -1 -moreinfo

On Fri, Mar 08, 2019 at 04:53:41PM +0000, Pierre Ynard wrote:

> severity 470956 minor
> tags 470956 moreinfo
> thanks
>
> > I am aware that fsck of ext2 isn't fast, but that's not a reason for
> > doing it needlessly *twice* when the first fsck gave an error <= 3.
> >
> > What happened was:
> > $ shutdown -F -r now
> > # computer reboots
> > # fsck of root fs
> < # fsck.ext2 returned error 3 (most likely since it optimized directories)
> > # computer automatically reboots  (everything works as expected until now)
> > # fsck of root fs  *grrr*
>
> I don't see how the system itself could guarantee between the two boots
> that the filesystem is still clean the second time. Another OS could
> have been booted instead, used the filesystem and left it dirty. The
> device could have been swapped in and out of the machine, and mounted by
> another system, etc...
>
> Even we wanted initscripts to set up some flag for the next reboot,
> that's not really possible because the filesystem is still read-only
> at this point, and really shouldn't be touched anymore until after the
> reboot.
>
> I suppose that if anything could be done about this, it would be by fsck
> utilities in the filesystem internal attributes. But I don't know which
> filesystem types would be concerned by this issue and if they would
> allow to address it. Ted, what do you think about this?

The logical fix would be to mark the filesystem as clean since all
errors have been corrected.

If anything, the kernel should not mark it clean again if it gets
mounted rw and then unmounted again before a reboot.

> Pierre Ynard

cu
Adrian

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed