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 <[email protected]> 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. [email protected] "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
