[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#801961: debian stretch amd64 netinst: no xfsprogs. xfs on root fails to boot.

clone 801961 -1
reassign -1 grub-pc
retitle -1 grub-pc: can't boot off newer xfs filesystems: "not a correct xfs inode"
severity -1 important
reassign 801961 base-installer
retitle 801961 base-installer: needs to install queued packages before linux-image
severity 801961 important

[ Julian, please keep bug addresses in CC - it helps if all the
  information is available to everybody. ]

Hi Julian, KiBi!

On Sat, Oct 17, 2015 at 12:03:34AM +0100, Julian Hughes wrote:
>On Fri, 16 Oct 2015 15:40:07 +0100
>Steve McIntyre <steve@einval.com> wrote:
>> Hi Julian,
>> If possible, it would be very helpful to see the installer logs from
>> that system. The current stretch netinst images include both the
>> xfsprogs .deb and .udeb, and I've just checked that partman-xfs is
>> marking xfsprogs for installation (it is). Something has broken, and
>> logs may help us track it down.
>> Cheers,
>> Steve
>Hi Steve,
>OK I started over.  As before, start point is a disk with gpt and
>already existing and fully functional Debian Stretch (upgraded from
>Jessie) with bios_grub, / and /home on xfs and a swap partition and a
>little over 100GB free space. Output of parted -l:
>Model: ATA ST9160301AS (scsi)
>Disk /dev/sda: 160GB
>Sector size (logical/physical): 512B/512B
>Partition Table: gpt
>Disk Flags: 
>Number  Start   End     Size    File system     Name              Flags
> 2      1049kB  2097kB  1049kB
> 1      2097kB  10.7GB  10.7GB  xfs             Linux filesystem
> 5      10.7GB  53.7GB  42.9GB  xfs             Linux filesystem
> 3      158GB   160GB   2146MB  linux-swap(v1)  Linux swap
>Then used weekly netinstaller of 2015-10-12 (md5sum checked and good)
>to install standard debian system (no desktop, no print server) using
>debian installer in non-graphical non-expert mode to create in
>10GB / xfs
>2GB swap
>remainder /home xfs
>Opted to install grub to /dev/sda.  No error messages.


>Install apparently succeeds but fails on reboot with grub error.

Assuming this is still the same error as earlier ("error: not a
correct xfs inode"), then that's apparently caused by a "new" (3yo)
feature in XFS that's not supported in grub2. A quick google search
for that error turns up several hits:


If you want to use XFS as your root filesystem, I'd suggest for now
that you use another filesystem on a small separate /boot partition.

I've cloned this bug report and move the new bug over to the grub-pc
package now, to help us track it. Until that's fixed, it's probably
worth us adding a check in d-i and recommending the use of a /boot
partition with XFS for now. KiBi: what do you think about that?

>Then used systemrescue to chroot and copy /var/log/installer to
>external media.

ACK, and thanks for the logs. They *do* show a problem as well. In the
first installation, I can see

Oct 16 21:37:38 apt-install: Queueing package xfsprogs for later installation
Oct 16 21:41:25 in-target: Setting up linux-base (4.0) ...
Oct 16 21:41:25 in-target: Setting up linux-image-4.2.0-1-amd64 (4.2.1-2) ...
Oct 16 21:41:27 in-target: update-initramfs: Generating /boot/initrd.img-4.2.0-1-amd64
Oct 16 21:41:32 in-target: Warning: /sbin/fsck.xfs doesn't exist, can't install to initramfs, ignoring.
Oct 16 21:41:46 in-target: Setting up linux-image-amd64 (4.2+68) ...
Oct 16 21:41:58 in-target: Preparing to unpack .../xfsprogs_4.2.0_amd64.deb ...
Oct 16 21:41:58 in-target: Unpacking xfsprogs (4.2.0) ...
Oct 16 21:41:58 in-target: Setting up libreadline5:amd64 (5.2+dfsg-3)...
Oct 16 21:41:59 in-target: Setting up xfsprogs (4.2.0) ...

which means there's an ordering problem here - update-initramfs is
being run before we've had a chance to install xfsprogs and so it's
failing there. It looks like we need to explicitly add some sequencing
for the package installations here to fix that. If we just made sure
xfsprogs was installed first, that would help!

For now, there should a simple workaround here - re-run the package
installation step for linux-image-* and it'll get xfsprogs on the
second pass.

<snip - ext4 works>

>Booting to new install fails with message:
>"systemd[1]: /etc/mtab is not a symlink or not pointing
>to /proc/self/mounts.  This is not supported anymore.  Please
>replace /etc/mtab with a symlink to /proc/self/mounts.
>systemd[1]: Freezing execution." (timestamps omitted)

ACK - I've just seen that mentioned in another bug log elsewhere today
(#802025 - a stupid systemd mis-feature to hang hard here,
sigh). Currently grub-installer (at the very least) faithfully updates
/etc/mtab during d-i, and I guess we should also change that
too. Maybe just simply rm /target/etc/mtab as part of d-i
finalisation. KiBi?

Steve McIntyre, Cambridge, UK.                                steve@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Reply to: