Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #63458 > unrolled thread

Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook

Back to article view | Back to linux.debian.kernel

Contents

  Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook Jonas Smedegaard <dr@jones.dk> - 2019-02-27 17:50 +0100
    Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook Jonas Smedegaard <dr@jones.dk> - 2019-02-27 18:40 +0100
      Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook Ben Hutchings <ben@decadent.org.uk> - 2019-02-27 19:40 +0100
        Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook Jonas Smedegaard <dr@jones.dk> - 2019-02-27 20:10 +0100
    Processed: Re: Bug#923400: initramfs-tools: failure inside  chroot: W: Couldn't identify type of root file system for fsck hook "Debian Bug Tracking System" <owner@bugs.debian.org> - 2019-02-27 19:40 +0100
    Bug#923400: marked as done (Add option to override filesystem  type detection) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2020-09-11 22:40 +0200

#63458 — Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook

Package: initramfs-tools
Version: 0.133
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Building a system image using multistrap,
including generating an initial ramdisk,
worked fine recently.

Now it fails with this error message:

  W: Couldn't identify type of root file system for fsck hook

It seems to me that git commit a8ed874 intended to extend the code
operating on "auto" mounted filesystems to cover all _except_ root disk,
but that the logic is flipped around so that now it _only_ extends that
to include root disk:

- -               case "$MNT_TYPE" in
- -                       auto)
[...]
+               # Ignore filesystem type for /, as it is not available and
+               # therefore never used at boot time
+               if [ "${MNT_DIR}" = "/" ] || [ "${MNT_TYPE}" = "auto" ]; then


 - Jonas

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlx2vqoACgkQLHwxRsGg
ASF8ohAAjuJLFgguQyXi0Xp+v2YhFWxqiZxnSBav7/f85S3UjaqUNU3DjXdFv/FJ
7SkzZShmdqGIkpjxGyajRBGbFZzDJkR2Xn7p1T+CcYHvOcUNPfcWzHumc120l9mW
f74frkEC6J/IZX3tFRRXsEZaZ9ZasA16mvoQyL6lXR6ys22gQa3fEVRpGS95jxm2
hH4OorJSLeaGNYiXUMDmav29Aom1We7sojs/fdkQXiSE7Q0nc9jeuOOsSXLkFgKI
EvK88J3YpjuzXGNtwYbVn1QyVAYSAqrDyLyTtjtFwUjQbQc3jy/rYW/DeoTQ8lD2
syKc7e2N0xz02Y3JOQWxMdA+SdlQqeiGkQI7AHL23D0MXLcVkCp9WfWfOAlulpKd
tNrf7+Bc+tSBz4uNy04xP5UzhLcOKOPy1Rxz2ItSd6vZF0BL/4fptMZBMlvqxWsX
f3soeauNDC9F0584K0Fkuhta8jI3KYAJkNOw1omBzjunf8TpnAEKIvr7IfEk9RJp
FnE7TF9fUurxxnZx8crBCzNqFRkwj0oCjno/0HMvNKYbucPaXCD/Oco7aU4/KnbP
YVj5i9V/sfS7f68N3q6tZF09Tcd0IKPkItm7i796GtQRcVwvLpa7CPPMz4WK33bE
P6lP1/ldcx2+THYbL1i4xGhA3S24g4Nn1DSqNZRaZA90cLtZGKU=
=0zMd
-----END PGP SIGNATURE-----

[toc] | [next] | [standalone]

#63459

[Multipart message — attachments visible in raw view] — view raw

Quoting Jonas Smedegaard (2019-02-27 17:45:33)
> Building a system image using multistrap,
> including generating an initial ramdisk,
> worked fine recently.
> 
> Now it fails with this error message:
> 
>   W: Couldn't identify type of root file system for fsck hook
> 
> It seems to me that git commit a8ed874 intended to extend the code
> operating on "auto" mounted filesystems to cover all _except_ root disk,
> but that the logic is flipped around so that now it _only_ extends that
> to include root disk:

Please ignore my guess above: I think I understand now that it was 
intentional to check root disk (I got confused by the comment talking 
about ignoring root and then processing root not skipping it).

Let me clarify my use case: I generate a system image on a fast amd64 
system targeted a slower real device (that's the reason having initramfs 
generated is important).

fstab now unconditionally being distrusted for root disk makes it more 
difficult to build on a different host than intended for target boot.

Would it perhaps make sense to support passing pre-resolved root 
filesystem fstype as an environment variable, taking precedence over 
probing?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#63461

[Multipart message — attachments visible in raw view] — view raw

Control: severity -1 wishlist
Control: retitle -1 Add option to override filesystem type detection

On Wed, 2019-02-27 at 18:38 +0100, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2019-02-27 17:45:33)
> > Building a system image using multistrap,
> > including generating an initial ramdisk,
> > worked fine recently.
> >
> > Now it fails with this error message:
> > 
> >   W: Couldn't identify type of root file system for fsck hook
> > 
> > It seems to me that git commit a8ed874 intended to extend the code
> > operating on "auto" mounted filesystems to cover all _except_ root disk,
> > but that the logic is flipped around so that now it _only_ extends that
> > to include root disk:

This commit went into version 0.123, before stretch, so if your use
case "worked fine recently" then this is not the change that broke it.

> Please ignore my guess above: I think I understand now that it was 
> intentional to check root disk (I got confused by the comment talking 
> about ignoring root and then processing root not skipping it).
> 
> Let me clarify my use case: I generate a system image on a fast amd64 
> system targeted a slower real device (that's the reason having initramfs 
> generated is important).
> 
> fstab now unconditionally being distrusted for root disk makes it more 
> difficult to build on a different host than intended for target boot.
>
> Would it perhaps make sense to support passing pre-resolved root 
> filesystem fstype as an environment variable, taking precedence over 
> probing?

I don't think this should be an environment variable but it does seem
like a useful option.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
                                                           - Bill Gates

[toc] | [prev] | [next] | [standalone]

#63462

[Multipart message — attachments visible in raw view] — view raw

Quoting Ben Hutchings (2019-02-27 19:37:41)
> Control: severity -1 wishlist
> Control: retitle -1 Add option to override filesystem type detection
> 
> On Wed, 2019-02-27 at 18:38 +0100, Jonas Smedegaard wrote:
> > Quoting Jonas Smedegaard (2019-02-27 17:45:33)
> > > Building a system image using multistrap,
> > > including generating an initial ramdisk,
> > > worked fine recently.
> > >
> > > Now it fails with this error message:
> > > 
> > >   W: Couldn't identify type of root file system for fsck hook
> > > 
> > > It seems to me that git commit a8ed874 intended to extend the code 
> > > operating on "auto" mounted filesystems to cover all _except_ root 
> > > disk, but that the logic is flipped around so that now it _only_ 
> > > extends that to include root disk:
> 
> This commit went into version 0.123, before stretch, so if your use
> case "worked fine recently" then this is not the change that broke it.

Heh.  I even looked briefly at the date thinking "hmm, committed in 
January, not February when released was made, but oh well...", and 
noticed that corresponding bug#767471 had a quite low number... :-)


> > Please ignore my guess above: I think I understand now that it was 
> > intentional to check root disk (I got confused by the comment 
> > talking about ignoring root and then processing root not skipping 
> > it).
> > 
> > Let me clarify my use case: I generate a system image on a fast 
> > amd64 system targeted a slower real device (that's the reason having 
> > initramfs generated is important).
> > 
> > fstab now unconditionally being distrusted for root disk makes it 
> > more difficult to build on a different host than intended for target 
> > boot.
> >
> > Would it perhaps make sense to support passing pre-resolved root 
> > filesystem fstype as an environment variable, taking precedence over 
> > probing?
> 
> I don't think this should be an environment variable but it does seem 
> like a useful option.

Thanks for considering.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#63460 — Processed: Re: Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook

Processing control commands:

> severity -1 wishlist
Bug #923400 [initramfs-tools] initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook
Severity set to 'wishlist' from 'normal'
> retitle -1 Add option to override filesystem type detection
Bug #923400 [initramfs-tools] initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook
Changed Bug title to 'Add option to override filesystem type detection' from 'initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook'.

-- 
923400: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923400
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#68101 — Bug#923400: marked as done (Add option to override filesystem type detection)

[Multipart message — attachments visible in raw view] — view raw

Your message dated Fri, 11 Sep 2020 20:36:04 +0000
with message-id <E1kGpm8-000Io2-0N@fasolo.debian.org>
and subject line Bug#923400: fixed in initramfs-tools 0.138
has caused the Debian Bug report #923400,
regarding Add option to override filesystem type detection
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
923400: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923400
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web