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
thanks
[ 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
>bios_grub
> 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
>freespace:
>
>10GB / xfs
>2GB swap
>remainder /home xfs
>
>Opted to install grub to /dev/sda. No error messages.
OK...
>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:
https://bugzilla.redhat.com/show_bug.cgi?id=1001279
http://lists.opensuse.org/opensuse-factory/2014-06/msg00179.html
https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1103187
https://groups.google.com/forum/#!topic/voidlinux/8hE0cEV38dU
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: