[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <533DAF1B.1070502@draigBrady.com>
Date: Thu, 03 Apr 2014 19:57:31 +0100
From: Pádraig Brady <P@...igBrady.com>
To: Dave Reisner <d@...conindy.com>
CC: linux-kernel@...r.kernel.org, tj@...nel.org
Subject: Re: Initramfs FSID altered in 3.14
On 04/03/2014 06:57 PM, Dave Reisner wrote:
> Hi,
>
> [This is a repost of a G+ post at Tejun's request]
>
> 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.
For reference we've changed coreutils not to assume 0 is an invalid device ID:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=d0294ff3
> 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 would say the kernel doesn't care what the value is,
so to ease compat worries just use >= 1.
cheers,
Pádraig
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists