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


Groups > linux.debian.kernel > #63461

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

From Ben Hutchings <ben@decadent.org.uk>
Newsgroups linux.debian.bugs.dist, linux.debian.kernel
Subject Bug#923400: initramfs-tools: failure inside chroot: W: Couldn't identify type of root file system for fsck hook
Date 2019-02-27 19:40 +0100
Message-ID <xwchz-21Z-1@gated-at.bofh.it> (permalink)
References <xwaz7-VZ-3@gated-at.bofh.it> <xwaz7-VZ-3@gated-at.bofh.it> <xwblv-1rR-5@gated-at.bofh.it> <xwaz7-VZ-3@gated-at.bofh.it> <xwblv-1rR-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Cross-posted to 2 groups.

Show all headers | View raw


[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


Back to linux.debian.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web