Messages in this thread | | | Date | Thu, 3 Apr 2014 15:13:07 -0400 | From | Tejun Heo <> | Subject | Re: Initramfs FSID altered in 3.14 |
| |
Hello, Dave.
On Thu, Apr 03, 2014 at 01:57:44PM -0400, Dave Reisner wrote: > With Linux 3.14, you might notice in /proc/self/mountinfo that your > root's parent FSID is now 0, instead of the 1 that it's been for the > last N years. Tejun wrote the change (9e30cc9595303b27b48) that caused > this, but the change comes in a rather innocuous way. Instead of an > internal kernel mount of sysfs being assigned 0, it's now the initramfs. > > So far, this has already caused switch_root and findmnt (from > util-linux) to break, cp (from coreutils) to break when using the -x > flag in early userspace, and it's also been pointed out that systemd's > readahead code makes assumptions about a device number of 0. > > Are we now supposed to go and change all the assumptions in userspace > about 0 being special? I'm conflicted. The kernel isn't supposed to > break userspace, but it seems to me that FSIDs were never something to > rely on -- similar to the block device numbering scheme.
I think this is the same problem Alexandre Demers reported. Arch was failing to boot with the commit. There's already a patch pending to reinstate the internal mount but I think what Thomas is proposing - just starting allocating FSID from 1 is a better solution. Alexandre, can you please test Thomas' patch?
Thanks.
-- tejun
| |