search

OSInside / kiwi

KIWI - Appliance Builder Next Generation
https://osinside.github.io/kiwi
GNU General Public License v3.0
301 stars 152 forks source link

mounting devtmpfs fails with newer kernel #1105

Closed luizluca closed 5 years ago

luizluca commented 5 years ago

Problem description

Hello, I'm using kiwi to build LivePXE images. For OpenSUSE 15.1 (and before), it works. Since a couple of weeks (not sure), nbd fails to mount. I traced it to the fact that /dev/nbd0 device is not available when nbd-client runs, even though nbd module is loaded. Manually reloading nbd module does not work create the device file. However, if I manually create it with "mknod /dev/nbd0 b 43 0", I'm able to mount NBD as usual. The reason is that it was not mounting /dev/ as devtmpfs

It is mounted using https://github.com/SUSE/kiwi-descriptions/blob/master/custom_boot/functions.sh#L406

And newer kernels fails to mount it when nr_inodes=0 is used. I can only mount when nr_inodes is greater than 199 (in my case). It might be necessary to set that value to something greater.

Expected behaviour

devtmpfs should mount or else nothing more will work

Steps to reproduce the behaviour

Setup a squashfs for NBD root (it might also happen with other rootfs types)

OS and Software information

davidcassany commented 5 years ago

Thanks for the detailed information regarding the issue you see, I'll try to see if I can find the change in kernel that is causing this failure to get the full picture. Even I believe that using nr_inode=0 is probably not a good idea after reading the tmpfs docs. I guess it was set this way in order to avoid having to guess a reasonable value.

IMHO, at first, this should be solved by using the default value (thus removing the nr_inode option), which is dependent on the RAM available. I can see the issues derived from setting it to a predefined value (even if it is set to by default according to RAM size) as there might be some use cases in which it is not sufficient and this is hard to detect and not configurable from KIWI POV, having a value that suits every use case is not possible. Thus I think having some strategy to allow users to customize it could be evaluated, even I have no clue now about how feasible it is.

@schaefi do you have any idea if there was some specific motivation to include nr_inode=0 in mount options for tmpfs in PXE boot code? What you think on using the default value?

schaefi commented 5 years ago

[2]@schaefi do you have any idea if there was some specific motivation to include nr_inode=0 in mount options for tmpfs in PXE boot code?

The reason was because of this commit: #75475ac96e56c53c8e6121265f3892640892be5e It was done with regards to split systems.

What you think on using the default value?

Actually we don't support split systems (systems not using overlayfs) anymore. Thus I using nr_inodes causes us trouble I'm fine if we change this

davidcassany commented 5 years ago

right, thanks for the background, this is valuable. Then I'd say this is even simpler, using default values should be just fine. Gonna prepare a PR, thanks!

luizluca commented 5 years ago

I didn't tested exactly with this patch but I did a monkey patch using hooks:

eval "$(declare -f createInitialDevices | sed -e 's/,nr_inodes=0//')"

It boots nicely now.