Bugzilla – Bug 141950
the kernel of the installation dvd supports only 8 /dev/loop* . That is not enough for some setups.
Last modified: 2006-04-26 23:05:17 UTC
Generally this is not a kernel, but a kernel module configuration bug. Though there is no such a category to submit. The whatever file that fit into SuSE desiɡn from a set of /etc/modprobe.* /etc/modprobe.d/* should contain the following option, that should satisfy most setups. options loop max_loop=64 Though if setting this to a 128 is not an issue - the option should be set to 128 or whatever allowed. Generally, as you know, the loop devices are needed for custom expert encrypted partitions and file as partition setup. The default is maximum of 8 loop devices. This is insuffitient for some setups. If you try just mknod /dev/loop8 usage of new loop device anyway will require increasing of max_loop, or will just return somthing like ¨no suh device or address¨ . I can imagine some other setups that may be trapped here. For example if you have a raid 5 array that cannot be split into two raid 5. And if you whish to have many partitions, you may block at the maximum number of partitions allowed. The possible way to still have many partitions is mounting some directories from files. Then you may try to mount some as loop devices, but there´s also a maximum of 8 and it is lesser if you also using enccryption - each encrypted partition eats a loop device. So since it´s a cause of installation fails (returning to beginning reoporting error) in custom setup cases - it's major accessibility/usability bug and should be documnented. Since it is a thing that stops me from getting more than 8 encrypted devices from a box install - it is also minor security related thing - I have to do all by hands. ;) The fix is ready and here. :)
Not a kernel issue, an installer issue. Reassigning...
I do not see how this should be an installer issue. The suggestion with an entry in /etc/modprobe.conf make sense, so why not simply add that line there. Reassigning to maintainer of /etc/modprobe.conf
Sorry, that didn't mention this before - the loop support is compiled in the kernel, not a module. Thus ' max_loop=64' (or better 'max_loop=128' ;) if it doesn't eat memory) should be appended to default strings of lilo / grub / or whatever loader is currently used. And again the string 'options loop max_loop=64' should be anyway present in the modules.conf since user may recompile loop support as a module & thus get trapped into defaults (default is 8).
The compiled in default could only be changed by the kernel people. They should decide if we either change the compiled in default, add max_loop= as option to booloader or let this simply as an configuration option that the user has to do by himself.
I'd prefer setting the module option as needed in the bootloader.
Reassigned to maintainer of bootloader
The loop device is a module now. The default number of devices can be set up in /etc/modprobe.conf. Setting this in the kernel commandline has no effect anymore. Since it is not influenced by the kernel commandline, this cannot be set by the bootloader. When someone wants to change the number of loop devices he can easily do this in modprobe.conf.
*** Bug 164288 has been marked as a duplicate of this bug. ***
*** Bug 157357 has been marked as a duplicate of this bug. ***
Olaf, you write: "When someone wants to change the number of loop devices he can easily do this in modprobe.conf." This is perfectly true. For us! But not for all. And XEN does NOT report something like "not enough loop back devices: look at page 123 of the manual" It just give a cryptic failure and bails out. What's the cost of increasing the amount, or at least spent a two-liner in the manual (xen-paragraph) why and how to increase it.... If it's too costly, increase the amount when the xend is launched!