XFS root filesystem - install fails with "noexec or nodev" error

[david wood]

I got a failure while performing a clean install with the Hardy Alpha 2 AMD64 Alternate Install CD.

I set up RAID 0 on a SATA drive (other drives not added yet), then set up LVM on md0, then created swap, root (75G), and home (~700G) partitions. Root and home were formatted with XFS.

Although the Gutsy installer would allow this to work (though I found other serious issues with XFS in Gutsy in this configuration, see Bug #175214), the new Hardy installer now fails while attempting to bootstrap base:

...debootstrap: /usr/sbin/debootstrap:
...debootstrap: /usr/sbin/debootstrap: 317:
...debootstrap: /usr/sbin/debootstrap: cannot create /target/test-dev-null/: No such device or address
...debootstrap: /usr/sbin/debootstrap:
...debootstrap: /usr/sbin/debootstrap: E: NOEXEC
...debootstrap: /usr/sbin/debootstrap: EF: Cannot install into target /target mounted with noexec or nodev

Checked mount and saw

/dev/mapper/mainvg-rootlv on /target type xfs (rw,ikeep,noquota)

So, XFS is not mounted noexec or nodev, but the test is nonetheless failing. I wonder if this is a more mundane installer regression, or if there's some new issue with XFS and special files. I'm not sure how common a choice XFS is for a root filesystem? Then again, there is no documentation to that effect, and no warnings in the installer one way or another.

Hardware:
Intel Core 2 X9650 cpu
Asus Maximus Formula Intel X38 mobo, used onboard sata...

[alteeno (alteeno-sina)]

I creat /boot ext3, / xfs, /home xfs, The installer report the same error message as above.
When I change the / from xfs to reiserfs, the installer will continue succesed.

[Stephan Rügamer (sruegamer)]

I have the same problem with debootstrap on an updated gutsy -> hardy system.
On gutsy it was working like a charm..now I'm stucked and can't do any builds..

How to fix it?

\sh

[Stephan Rügamer (sruegamer)]

not the source of the problem

[Stephan Rügamer (sruegamer)]

Ok, here it goes...
just create a XFS partition and mount it normally (rw,exec,dev -> default).
now do this:
cd /your/newly/mounted/xfs/partition
mknod test-dev-null c 1 3
echo "test" > test-dev-null ; echo $?

it results in "1" and doesn't work.
e.g.

root@home-emt64:~# echo "test" > /home/shermann/hardy_chroot/test-dev-null ; echo $?
-su: /home/shermann/hardy_chroot/test-dev-null: No such device or address
1

So, XFS has a problem with devices...
A Kernel Problem.

[Leann Ogasawara (leannogasawara)]

Hi Stephen,

After you run the test you outlined above, can you capture your dmesg output and attach it to this bug report? I'm just curious if there are any other messages that may be logged that could help. Thanks.

[Stephan Rügamer (sruegamer)]

Hi Leann,

since the last updated linux image this behaviour is gone...

So what was it really? :)

Regards,

\sh

[Leann Ogasawara (leannogasawara)]

Hi Stephan,

I'm glad to hear things are now working. Per your last comment I'm going to close this report. The kernel team most recently sync'd with upstream's 2.6.24-rc8 kernel which probably explains where the fix originated. I browsed through the changelog and the only xfs related note I saw was the following:

[XFS] fix unaligned access in readdir

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.