Bug 141950

Summary:	the kernel of the installation dvd supports only 8 /dev/loop* . That is not enough for some setups.
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Olli Artemjev <grey-olli>
Component:	Installation	Assignee:	Olaf Dabrunz <odabrunz>
Status:	RESOLVED FIXED	QA Contact:	Klaus Kämpf <kkaempf>
Severity:	Major
Priority:	P3 - Medium	CC:	hwit, suse-beta
Version:	Final	Keywords:	accessibility, documentation, easy_fix, Fix_is_Ready, security, Usability
Target Milestone:	---
Hardware:	i686
OS:	SuSE Linux 10.0
Whiteboard:
Found By:	Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Olli Artemjev 2006-01-07 20:00:06 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. :)

Comment 1 Greg Kroah-Hartman 2006-01-07 23:56:29 UTC

Not a kernel issue, an installer issue.  Reassigning...

Comment 2 Thomas Fehr 2006-01-11 14:18:12 UTC

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

Comment 3 Olli Artemjev 2006-01-11 18:01:01 UTC

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).

Comment 4 Thomas Fehr 2006-01-12 10:49:05 UTC

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.

Comment 5 Lars Marowsky-Bree 2006-01-17 11:04:31 UTC

I'd prefer setting the module option as needed in the bootloader.

Comment 6 Thomas Fehr 2006-01-17 11:21:03 UTC

Reassigned to maintainer of bootloader

Comment 7 Olaf Dabrunz 2006-04-07 12:47:16 UTC

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.

Comment 8 Christian Boltz 2006-04-07 23:54:23 UTC

*** Bug 164288 has been marked as a duplicate of this bug. ***

Comment 9 Christian Boltz 2006-04-07 23:55:08 UTC

*** Bug 157357 has been marked as a duplicate of this bug. ***

Comment 10 Hans Witvliet 2006-04-26 23:05:17 UTC

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!