Messages in this thread Patch in this message | | | Subject | Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot | From | Rob Landley <> | Date | Sun, 10 Sep 2017 18:43:24 -0500 |
| |
Taking another stab at this old issue from last merge window...
> Rob Landley <rob@landley.net> writes: >> On 05/23/2017 03:01 AM, Yury Norov wrote: >>> On Mon, May 22, 2017 at 09:07:54PM -0500, Rob Landley wrote: >>>> Your userspace mounted a tmpfs over /dev when it couldn't mount a second >>>> identical instance of devtmpfs over itself. If you had a static /dev in >>>> initramfs but didn't configure _in_ devtmpfs to your kernel, your broken >>>> error path would have taken that out too with a pointless tmpfs mount. >>> >>> CONFIG_DEVTMPFS_MOUNT is enabled on my machine, so I think your >>> suggestion is correct. But I didn't do that specifically - I run >>> almost default kernel based on Ubuntu 14.04 config and environment. >> >> I.E. ubuntu has a bug: they enabled CONFIG_DEVTMPFS_MOUNT and then >> launchd an initramfs instead (which didn't do the automount they >> requested so why request it), but if CONFIG_DEVTMPFS_MOUNT actually >> starts working in initramfs they have an insane error path that breaks >> the system, and does nothing _except_ break the system.
...
On 05/25/2017 01:13 AM, Michael Ellerman wrote: > Hi Rob, > > This is breaking a bunch of my powerpc boxes, for the exact same > reason, they use a config that has DEVTMPFS_MOUNT=y and that trips > up the initramfs.
I've continued to use this locally but should probably make another stab at submitting upstream. The obvious workaround until debian fixes its 100% obvious bug seems to be:
diff --git a/fs/namespace.c b/fs/namespace.c index f8893dc..f57d5df 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -2417,7 +2417,17 @@ static int do_add_mount(struct mount *newmnt, struct path *path, int mnt_flags) err = -EBUSY; if (path->mnt->mnt_sb == newmnt->mnt.mnt_sb && path->mnt->mnt_root == path->dentry) + { + if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT) && + !strcmp(path->mnt->mnt_sb->s_type->name, "devtmpfs")) + { + printk(KERN_WARNING "Debian bug workaround for devtmpfs overmount."); + printk(KERN_WARNING "This line doesn't output for some reason."); + + err = 0; + } goto unlock; + } err = -EINVAL; if (d_is_symlink(newmnt->mnt.mnt_root)) Except for the second printk line: If you boot with rdinit=/bin/hush then the first time you mount -t devtmpfs /dev /dev after boot (with CONFIG_DEVTMPFS_MOUNT already having mounted it), you get the 0 return value but the last printk() doesn't output? The second and later times you repeat it, both printk() lines are output.
What's up with printk?
(I added the second printk because the _first_ one wasn't outputting that first time. Something is happening to flush the printk() queue instead of writing it out? Built for x86-64, miniconfig attached for reference. I tested commit 4dfc2788033d from yesterday.)
Rob # make ARCH=x86 allnoconfig KCONFIG_ALLCONFIG=x86_64.miniconf # make ARCH=x86 -j $(nproc) # boot arch/x86/boot/bzImage
CONFIG_64BIT=y
CONFIG_PCI=y CONFIG_BLK_DEV_SD=y CONFIG_ATA=y CONFIG_ATA_SFF=y CONFIG_ATA_BMDMA=y CONFIG_ATA_PIIX=y
CONFIG_NET_VENDOR_INTEL=y CONFIG_E1000=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_RTC_CLASS=y
# CONFIG_EMBEDDED is not set CONFIG_EARLY_PRINTK=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_SCRIPT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y
CONFIG_BLK_DEV=y CONFIG_BLK_DEV_INITRD=y CONFIG_RD_GZIP=y
CONFIG_BLK_DEV_LOOP=y CONFIG_EXT4_FS=y CONFIG_EXT4_USE_FOR_EXT2=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_UTF8=y CONFIG_MISC_FILESYSTEMS=y CONFIG_SQUASHFS=y CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_ZLIB=y CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y
CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IPV6=y CONFIG_NETDEVICES=y #CONFIG_NET_CORE=y #CONFIG_NETCONSOLE=y CONFIG_ETHERNET=y
| |