On Mon, Jun 30, 2014 at 12:23:39PM +0200, Lennart Poettering wrote:
[snip]
> The nicer option appears to me is to talk to xfs and btrfs upstream and
> ask them to either change their fsck to a symlink to /bin/true or to
> remove it altogether. Because otherwise we cannot detect whether fscking
> is
On Mon, 30.06.14 00:10, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> On Sun, Jun 29, 2014 at 08:46:32PM +0200, Lennart Poettering wrote:
> > This sounds really unnecessary, no? We already have fsck_exists() in
> > place that since a very recent commit of mine even detects a per-fst
Kai Krakow gmail.com> writes:
>
> To check this, I've just pulled the original source from git and built it.
> This is original upstream behavior, no special Gentoo thing. The fsck.btrfs
> utility is just a shell script. It seems to originate from xfs-progs:
>
> https://github.com/josefbacik/b
On Mon, Jun 30, 2014 at 01:17:47AM +0200, Kai Krakow wrote:
> Zbigniew Jędrzejewski-Szmek schrieb:
>
> >> IMHO both xfs and btrfs should just not ship a fsck helper at all, not
> >> even as a symlink. This workaround made sense at some point, but now I
> >> believe both systemd _and_ fsck itself
Zbigniew Jędrzejewski-Szmek schrieb:
>> IMHO both xfs and btrfs should just not ship a fsck helper at all, not
>> even as a symlink. This workaround made sense at some point, but now I
>> believe both systemd _and_ fsck itself can deal gracefully with a
>> missing fsck helper.
> IMHO, this shows
Stefan G. Weichinger schrieb:
> Am 29.06.2014 23:52, schrieb Tom Gundersen:
>> On Sun, Jun 29, 2014 at 11:31 PM, Stefan G. Weichinger
>> wrote:
>>
>>> This is how gentoo currently implements things. So the devs there
>>> should link it to /bin/true ? We could open a bug for that at
>>> bugs.gen
Lennart Poettering schrieb:
> On Sun, 29.06.14 21:51, Kai Krakow (hurikha...@gmail.com) wrote:
>
>> > This sounds really unnecessary, no? We already have fsck_exists() in
>> > place that since a very recent commit of mine even detects a per-fstype
>> > fsck implementation being linked to /bin/t
On Mon, Jun 30, 2014 at 12:10 AM, Zbigniew Jędrzejewski-Szmek
wrote:
> On Sun, Jun 29, 2014 at 08:46:32PM +0200, Lennart Poettering wrote:
>> This sounds really unnecessary, no? We already have fsck_exists() in
>> place that since a very recent commit of mine even detects a per-fstype
>> fsck imp
On Sun, Jun 29, 2014 at 08:46:32PM +0200, Lennart Poettering wrote:
> This sounds really unnecessary, no? We already have fsck_exists() in
> place that since a very recent commit of mine even detects a per-fstype
> fsck implementation being linked to /bin/true... I also downgraded all
> warnings f
Am 29.06.2014 23:52, schrieb Tom Gundersen:
> On Sun, Jun 29, 2014 at 11:31 PM, Stefan G. Weichinger
> wrote:
>
>> This is how gentoo currently implements things. So the devs there
>> should link it to /bin/true ? We could open a bug for that at
>> bugs.gentoo.org ...
>
> IMHO both xfs and btrfs
On Sun, Jun 29, 2014 at 11:31 PM, Stefan G. Weichinger wrote:
> Am 29.06.2014 23:24, schrieb Lennart Poettering:
>> On Sun, 29.06.14 21:51, Kai Krakow (hurikha...@gmail.com) wrote:
>>> # /sbin/fsck.btrfs /dev/sdb3
>>> If you wish to check the consistency of a BTRFS filesystem or
>>> repair a damag
Am 29.06.2014 23:24, schrieb Lennart Poettering:
> On Sun, 29.06.14 21:51, Kai Krakow (hurikha...@gmail.com) wrote:
>> # /sbin/fsck.btrfs /dev/sdb3
>> If you wish to check the consistency of a BTRFS filesystem or
>> repair a damaged filesystem, see btrfs(8) subcommand 'check'.
>
> Is this an upstr
On Sun, 29.06.14 21:51, Kai Krakow (hurikha...@gmail.com) wrote:
> > This sounds really unnecessary, no? We already have fsck_exists() in
> > place that since a very recent commit of mine even detects a per-fstype
> > fsck implementation being linked to /bin/true... I also downgraded all
> > warn
Lennart Poettering schrieb:
> On Sat, 28.06.14 19:49, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl)
> wrote:
>
>> fsck.btrfs and fsck.xfs are documented to return immediately, so there is
>> little sense in running them. Avoids some user confusion and a few lines
>> in the logs.
>>
>> +stati
On Sat, 28.06.14 19:49, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> fsck.btrfs and fsck.xfs are documented to return immediately, so there is
> little sense in running them. Avoids some user confusion and a few lines
> in the logs.
>
> +static bool mount_skip_fsck(const char *fstype
On Sat, Jun 28, 2014 at 7:49 PM, Zbigniew Jędrzejewski-Szmek
wrote:
> fsck.btrfs and fsck.xfs are documented to return immediately, so there is
> little sense in running them. Avoids some user confusion and a few lines
> in the logs.
Is this special-casing really worth it? In general we don't kno
On Sun, Jun 29, 2014 at 6:08 PM, Andrey Borzenkov wrote:
> This sounds far too specific for a generic tool. If I read this bug
> report correctly, the primary complain was that systemd tries to
> install fsck service even though fstab says skip fsck. This appears to
> be the actual bug; I do not s
В Sat, 28 Jun 2014 19:49:07 +0200
Zbigniew Jędrzejewski-Szmek пишет:
> fsck.btrfs and fsck.xfs are documented to return immediately, so there is
> little sense in running them. Avoids some user confusion and a few lines
> in the logs.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1098799
This
18 matches
Mail list logo
