On 03/05/2018 10:47 PM, Dave Chinner wrote: > On Mon, Mar 05, 2018 at 09:12:03PM -0800, Randy Dunlap wrote: >> On 03/05/2018 08:45 PM, Eric Sandeen wrote: >>> On 3/5/18 10:42 PM, Randy Dunlap wrote: >>>>>> It's a new OS/installer. OpenSUSE Tumbleweed, which is their bleeding edge >>>>>> rolling updates release. >>>>> Hrmph. A lot of things go into this behavior, it may not be a kernel change at >>>>> all that has made it show up now... >>>> Yes, it could be that wonderful systemd or something else. >>> >>> I think I'd pursue a parallel track of bugging SUSE about the issue... ;) >>> >>> (I don't think the kernel will ever just downgrade an rw mount request to >>> ro, or skip an ro->rw transition silently... leaving it ro does seem >>> like an init bug, but *shrug* init long ago transitioned into deep magic.) >> >> More info: :( >> >> This problem happens when booting my own custom 4.16-rc3 kernel. >> If I boot the OpenSUSE-supplied (4.15.7) kernel, the / fs is remounted rw later on. >> >> So I'm more or less back to "what am I doing wrong"? > > The filesystem probing order has probably changed. mount tries to > use blkid to determine the filesytem type to use, and if that > doesn't find a known type it will fall back to trying mounts with > explicit types as per the filesystem type order listed in > /proc/filesystems. (it's in the man mount page) Maybe the device > module hasn't been loaded when blkid runs to probe existing block > devices? > > These sorts of whacky behaviours have occurred for me in the past > when either userspace behaviour changed, the order of filesystems > listed in /proc/filesystems or module load order changed. Typically > it's a difference in kernel config that causes such shenanigans. There is also a (big) difference in the $DISTRO using initramfs and my custom kernel not using one. But in both cases the SATA/AHCI driver is loaded/ready before ext4fs, so it's still a mystery to me. Eric, I tested your patch but it didn't help in my environment. thanks, -- ~Randy
