The interaction between CONFIG_MTD_UBI_BLOCK and CONFIG_MTD_UBI_GLUEBI

what's happenin' boys,

long time no talk.

a recent change to the mainline kernel caught my attention:

and richard weinberger brought daniel golle, our resident mtd expert, into the fold.

but daniel wasn't around when the old guys were using gluebi, so neither of us have any clue.

here are the relevant portions of the bootlog under discussion:

[    2.958157] Support this Device in MTK table! c8d1
[    2.968055] [NAND]select ecc bit:4, sparesize :64 spare_per_sector=16
[    2.980930] nand: device found, Manufacturer ID: 0xc8, Chip ID: 0xd1
[    2.993590] nand: ESMT NAND 128MiB 3,3V 8-bit
[    3.002281] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    3.017376] Scanning device for bad blocks
[    3.169277] MT7621-NAND: parsing partitions cmdlinepart
[    3.180264] MT7621-NAND: got parser (null)
[    3.188484] 9 fixed-partitions partitions found on MTD device MT7621-NAND
[    3.202005] Creating 9 MTD partitions on "MT7621-NAND":
[    3.212430] 0x000000000000-0x000000080000 : "Bootloader"
[    3.224024] 0x0000000c0000-0x000000100000 : "Config"
[    3.234684] 0x000000100000-0x000000140000 : "Factory"
[    3.245518] 0x000000140000-0x000000180000 : "Config2"
[    3.256379] 0x000000180000-0x000002d80000 : "sysv"
[    3.895176] 1 squashfs-split partitions found on MTD device sysv
[    3.907164] 0x0000005c1000-0x000002d60000 : "ddwrt"
[    3.920925] 2 uimage-fw partitions found on MTD device sysv
[    3.932031] Creating 2 MTD partitions on "sysv":
[    3.941232] 0x000000000000-0x000000400000 : "kernel"
[    3.951995] 0x000000400000-0x000002c00000 : "ubi"
[    3.962325] 0x000002d80000-0x000004d80000 : "private"
[    3.973322] 0x000004d80000-0x000007580000 : "firmware2"
[    3.984759] 0x000007580000-0x000007b80000 : "mydlink"
[    3.995699] 0x000007b80000-0x000008000000 : "reserved"
[    4.006687] [mtk_nand] probe successfully!
[    4.015584] Signature matched and data read!
[    4.024090] load_fact_bbt success 1023

and

[    5.462504] auto-attach mtd7
[    5.462525] ubi0: default fastmap pool size: 15
[    5.477309] ubi0: default fastmap WL pool size: 7
[    5.486683] ubi0: attaching mtd7
[    5.811240] UBI: EOF marker found, PEBs from 273 will be erased
[    5.811299] ubi0: scanning is finished
[    5.874546] gluebi (pid 1): gluebi_resized: got update notification for unknown UBI device 0 volume 1
[    5.892927] ubi0: volume 1 ("rootfs_data") re-sized from 9 to 28 LEBs
[    5.906683] ubi0: attached mtd7 (name "ubi", size 40 MiB)
[    5.917446] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[    5.931132] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[    5.944654] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[    5.958513] ubi0: good PEBs: 320, bad PEBs: 0, corrupted PEBs: 0
[    5.970472] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
[    5.984859] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1613475955
[    6.003045] ubi0: available PEBs: 0, total reserved PEBs: 320, PEBs reserved for bad PEB handling: 15
[    6.021426] rootfs: parsing partitions cmdlinepart
[    6.021444] ubi0: background thread "ubi_bgt0d" started, PID 97
[    6.043694] rootfs: got parser (null)
[    6.051426] mtd: device 12 (rootfs) set to be root filesystem
[    6.062891] rootfs_data: parsing partitions cmdlinepart
[    6.073669] rootfs_data: got parser (null)
[    6.211240] block ubiblock0_0: created from ubi0:0(rootfs)
[    6.259545] rtc-pcf8563 0-0051: hctosys: unable to read the hardware clock
[    6.282125] VFS: Cannot open root device "(null)" or unknown-block(31,12): error -6
[    6.297406] Please append a correct "root=" boot option; here are the available partitions:
[    6.314054] 1f00             512 mtdblock0
[    6.314060]  (driver?)
[    6.327077] 1f01             256 mtdblock1
[    6.327081]  (driver?)
[    6.340101] 1f02             256 mtdblock2
[    6.340105]  (driver?)
[    6.353124] 1f03             256 mtdblock3
[    6.353129]  (driver?)
[    6.366153] 1f04           45056 mtdblock4
[    6.366158]  (driver?)
[    6.379175] 1f05           40572 mtdblock5
[    6.379179]  (driver?)
[    6.392217] 1f06            4096 mtdblock6
[    6.392222]  (driver?)
[    6.405240] 1f07           40960 mtdblock7
[    6.405244]  (driver?)
[    6.418272] 1f08           32768 mtdblock8
[    6.418277]  (driver?)
[    6.431296] 1f09           40960 mtdblock9
[    6.431300]  (driver?)
[    6.444324] 1f0a            6144 mtdblock10
[    6.444328]  (driver?)
[    6.457518] 1f0b            4608 mtdblock11
[    6.457523]  (driver?)
[    6.470720] fe00           33604 ubiblock0_0
[    6.470724]  (driver?)
[    6.484090] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,12)

i have learned that GLUEBI is useless, i get it, but the question is this: can GLUEBI highjack a block device created by UBI_BLOCK? in the above example we see that ubiblock creates the block device ubiblock0_0 for the rootfs, but it fails to get mounted because of the diff linked above

now, if i disable gluebi, will this fix the problem? it's strange that the device is created by UBI_BLOCK but cannot be mounted since it has an MTD_UBIVOLUME flag.

answer: it does.

for archival purposes, please see full exchange here on the lists:

https://lore.kernel.org/lkml/12400272-4449-040c-1ccd-6494a67f4da0@huawei.com/T/#m8c6e285ebe9e2d6e76cc409b84ce2c09832b90cc