Bug 724920

If you run your own kernels, you can put the parameter in a
/etc/modprobe.d/ config file, and do the mknod loop0 in
/lib/udev/devices/ yourself.

This will load the module and create as many devices as specified
in the config.

Compiled-in loop can be configured on the kernel command line.

I'm currently trying to fix loop to support auto-loading
out-of-the-box, and support proper on-demand creation of loop
devices, so all that should be history pretty soon, if things
work out like planned.

(In reply to comment #1)
> I'm currently trying to fix loop to support auto-loading
> out-of-the-box, and support proper on-demand creation of loop
> devices, so all that should be history pretty soon, if things
> work out like planned.

That would be nice but note there are some magic loops hardcoded when searching for free loop devices which expects /dev/loop* exist. I am not sure why loop must behave differently here than other block devices though.  But it is reality.

Anyway, please keep loop module working with udev (no problem with minor config change like modprobe.d line, just please do not hardcode assuption that loop is compiled in kernel).

Some people are still using patched loop modules as well.

(In reply to comment #2)
> Anyway, please keep loop module working with udev.

We can not safely create dead device nodes besides /dev/loop0, that's
why the hack in the spec file got removed. If loop devices are configured
to support partitions, they will look like:
  $ ls -l /dev/loop*
  brw-rw---- 1 root disk  7,   0 Jul 25 01:10 /dev/loop0
  brw-rw---- 1 root disk  7,  32 Jul 25 01:10 /dev/loop1
  brw-rw---- 1 root disk  7,  64 Jul 25 01:10 /dev/loop2

Nothing besides /dev/loop0 must ever be created by userspace, we can not
to that properly. Unconditionally created devices nodes, which are not
controlled by the kernel, just don't really work on today's systems.

I have a patch now that introduces /dev/loop-control now, and losetup will be
able to request new devices there. Also /sys/module/loop/parameters/min_loop
can be increased. Access of /dev/loop-control will trigger the auto-loading
of the loop module.

Kernel patch for /dev/loop-control posted:
  https://lkml.org/lkml/2011/7/26/148

If things work out, we will make mount(8) and losetp(8) use the new
interface, and loop does not even be loaded before calling any of these
tools.

Thanks, I have patch for crypsetup as well, LOOP_CTL_GET_FREE works fine for me (and autoload of module too).

I should probably mention here when the  loop module is removed - the /dev/loop-control is removed.  IMHO it seems like udev  should not be removing nodes which have been created from modules.devname parsing - but I could be wrong here - it does not seem to be documented.  (The same issue happens with dm_mod removal - however lvm tools are able to go around when control device is missing.

Right, it's a known limitation. If something decides to remove a module,
all nodes belonging to that module get removed by the kernel itself or
by udev. We could probably teach udev about it, but if the kernel has
created it we can not really do anything.

Udev creates the 'dead' autoload-nodes only at startup. Currently we
only support auto-loading the first time after bootup, but not after
manual module removal.

Does anything depend on removed modules, or does something else than
an admin calls rmmod? Removing modules is not really supported officially,
it's mainly a developer or debug tool, and should never be done by
anything automatically.

(In reply to comment #7)
> Right, it's a known limitation. If something decides to remove a module,
> all nodes belonging to that module get removed by the kernel itself or
> by udev. We could probably teach udev about it, but if the kernel has
> created it we can not really do anything.
> 
> Udev creates the 'dead' autoload-nodes only at startup. Currently we
> only support auto-loading the first time after bootup, but not after
> manual module removal.
> 
> Does anything depend on removed modules, or does something else than
> an admin calls rmmod? Removing modules is not really supported officially,
> it's mainly a developer or debug tool, and should never be done by
> anything automatically.

Well IMHO udev then 'kills' 'the good old' behaviour, when /dev contained static nodes and kernel module auto-loading was working well all the time.

With current udev implementation you get different behaviour from the boot time and from the runtime after the first module removal.

I know it's not the top urgent problem, but I would prefer, udev would keep the list of nodes it has created on the startup and would preserve such nodes on module unload.

As said, we don't support module unload at the moment. If a user unloads a
module, he can not expect module auto-loading to work any more. He needs
to re-load it manually just like he unloaded it manually. Module unload
in general is not supported setup.

I know what you mean, it would be useful and less surprising, but it isn't
entirely trivial to make udev preserve the static nodes, because we don't
have any, and we can not create a udev database entry for these nodes
before the device is known by the kernel.

We could maybe add hacks like adding the 'sticky' bit to the device node
at udev startup, and skip the removal of all file with the sticky bit set. :)

Works now in udev-git. We set the 'sticky' bit on these nodes, and
'remove' events will not delete the nodes:
  # ls -l /dev/loop*; modprobe loop; rmmod loop; ls -l /dev/loop*;
  crw------T 1 root root 10, 237 Aug 14 19:03 /dev/loop-control
  crw------T 1 root root 10, 237 Aug 14 19:04 /dev/loop-control

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.