SEO

the "loop" module on my linux box is not loaded itself when needed by mount.

when I type mount -o loop ...

While this module does not appear in the blacklist of modprobe
(/etc/modprobe.d/blacklist)

--
heavytull

On Fri, 15 Dec 2006, heavytull wrote:
> the "loop" module on my linux box is not loaded itself when needed by mount.
> when I type mount -o loop ...
> While this module does not appear in the blacklist of modprobe
> (/etc/modprobe.d/blacklist)

i'll bet you've gone and mucked with your kernel, hey?
so what happens if you force a modprobe loop ?
and what do you get out of:

$ grep -i loop /boot/config /proc/devices

--
William Hunt, Portland Oregon USA

William Hunt wrote:

> On Fri, 15 Dec 2006, heavytull wrote:
>> the "loop" module on my linux box is not loaded itself when needed by
>> mount. when I type mount -o loop ...
>> While this module does not appear in the blacklist of modprobe
>> (/etc/modprobe.d/blacklist)
>
> i'll bet you've gone and mucked with your kernel, hey?
you mean?
you mean that i custom tuned the kernel?
yes i'm doing so since long. but I don't think this is related to that. the
troubles with loop and some others started when i upgraded to Slack11


> so what happens if you force a modprobe loop ?
the module gets loaded and works fine

> and what do you get out of:
>
> $ grep -i loop /boot/config /proc/devices
>
/boot/config : file does not exist
grep -i loop /proc/devices : nothing




--
heavytull

heavytull <heavytull@hotmail.com> wrote:
>>> the "loop" module on my linux box is not loaded itself when needed by
>>> mount. when I type mount -o loop ...
>>> While this module does not appear in the blacklist of modprobe
>>> (/etc/modprobe.d/blacklist)

I'm only guessing now, but this is what I would think is the
explanation: Blacklist is used by hotplug. Hotplug loads modules when it
finds new hardware. As there is no particular hardware associated with the
loopback module it won't be loaded by hotplug.

>> i'll bet you've gone and mucked with your kernel, hey?
> you mean?
> you mean that i custom tuned the kernel?
> yes i'm doing so since long. but I don't think this is related to that.

I think it does if the default kernel has loopback built in and not as a
module.

>> so what happens if you force a modprobe loop ?

> the module gets loaded and works fine

So you have 3 choices:

1) Manually load the module before doing a loopback mount and then maybe
manually unload the module after umount.

2) Allways have the module loaded, maybe from /etc/rc.d/rc.modules.

3) If you like the automatic solution nr 2 above you might just as well
build a kernel with loopback support built in.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc8(at)uthyres.com Examples of addresses which go to spammers:
root@variousus.net root@localhost

On Sat, 16 Dec 2006 00:23:23 +0100, heavytull wrote:

> William Hunt wrote:
>
>> On Fri, 15 Dec 2006, heavytull wrote:
>>> the "loop" module on my linux box is not loaded itself when needed by
>>> mount. when I type mount -o loop ...
>>> While this module does not appear in the blacklist of modprobe
>>> (/etc/modprobe.d/blacklist)
>>
>> i'll bet you've gone and mucked with your kernel, hey?
> you mean?
> you mean that i custom tuned the kernel?
> yes i'm doing so since long. but I don't think this is related to that. the
> troubles with loop and some others started when i upgraded to Slack11
>
>
>> so what happens if you force a modprobe loop ?
> the module gets loaded and works fine
>
>> and what do you get out of:
>>
>> $ grep -i loop /boot/config /proc/devices
>>
> /boot/config : file does not exist
> grep -i loop /proc/devices : nothing
>

Are you using loop for an encrypted file system? If so, note that
cryptoloop is deprecated and not recommended. device mapper is used now
and you will also need the dm-mod module. You also need to make sure the
relevant encryption modules (e.g. aes-256) are loaded

Exactly what is your mount command? Here is my routine for loading an
encrypted fs.

~/stuff is the encrypted fs as a file.
~/mnt/stuff is the mount location.

# losetup /dev/loop0 ~/stuff
# cryptsetup create -h plain stuff /dev/loop0
# mount -t ext2 /dev/mapper/stuff ~/mnt/stuff

using cryptoloop, the mount command would look like this:

# mount -t ext2 ~/stuff ~/mnt/stuff -o loop,encryption=aes-256,rw

I am not even sure the mount command supports cryptoloop anymore.
You may need to upgrade and use device mapper.
--
Peter

Peter wrote:

> On Sat, 16 Dec 2006 00:23:23 +0100, heavytull wrote:
>
>> William Hunt wrote:
>>
>>> On Fri, 15 Dec 2006, heavytull wrote:
>>>> the "loop" module on my linux box is not loaded itself when needed by
>>>> mount. when I type mount -o loop ...
>>>> While this module does not appear in the blacklist of modprobe
>>>> (/etc/modprobe.d/blacklist)
>>>
>>> i'll bet you've gone and mucked with your kernel, hey?
>> you mean?
>> you mean that i custom tuned the kernel?
>> yes i'm doing so since long. but I don't think this is related to that.
>> the troubles with loop and some others started when i upgraded to Slack11
>>
>>
>>> so what happens if you force a modprobe loop ?
>> the module gets loaded and works fine
>>
>>> and what do you get out of:
>>>
>>> $ grep -i loop /boot/config /proc/devices
>>>
>> /boot/config : file does not exist
>> grep -i loop /proc/devices : nothing
>>
>
> Are you using loop for an encrypted file system?
no
> If so, note that
> cryptoloop is deprecated and not recommended. device mapper is used now
> and you will also need the dm-mod module. You also need to make sure the
> relevant encryption modules (e.g. aes-256) are loaded
>
> Exactly what is your mount command? Here is my routine for loading an
> encrypted fs.
>
> ~/stuff is the encrypted fs as a file.
> ~/mnt/stuff is the mount location.
>
> # losetup /dev/loop0 ~/stuff
> # cryptsetup create -h plain stuff /dev/loop0
> # mount -t ext2 /dev/mapper/stuff ~/mnt/stuff
>
> using cryptoloop, the mount command would look like this:
>
> # mount -t ext2 ~/stuff ~/mnt/stuff -o loop,encryption=aes-256,rw
>
> I am not even sure the mount command supports cryptoloop anymore.
> You may need to upgrade and use device mapper.

--
heavytull

Henrik Carlqvist wrote:

> heavytull <heavytull@hotmail.com> wrote:
>>>> the "loop" module on my linux box is not loaded itself when needed by
>>>> mount. when I type mount -o loop ...
>>>> While this module does not appear in the blacklist of modprobe
>>>> (/etc/modprobe.d/blacklist)
>
> I'm only guessing now, but this is what I would think is the
> explanation: Blacklist is used by hotplug. Hotplug loads modules when it
> finds new hardware. As there is no particular hardware associated with the
> loopback module it won't be loaded by hotplug.
>
>>> i'll bet you've gone and mucked with your kernel, hey?
>> you mean?
>> you mean that i custom tuned the kernel?
>> yes i'm doing so since long. but I don't think this is related to that.
>
> I think it does if the default kernel has loopback built in and not as a
> module.
>
no, i have always built loop as module.

I told that this problem started since i upgraded to slack11. thought I'm
not 100% sure.

>>> so what happens if you force a modprobe loop ?
>
>> the module gets loaded and works fine
>
> So you have 3 choices:
>
> 1) Manually load the module before doing a loopback mount and then maybe
> manually unload the module after umount.
>
> 2) Allways have the module loaded, maybe from /etc/rc.d/rc.modules.
>
> 3) If you like the automatic solution nr 2 above you might just as well
> build a kernel with loopback support built in.
>
> regards Henrik

--
heavytull

On Sat, 16 Dec 2006, heavytull wrote:

> William Hunt wrote:
>> On Fri, 15 Dec 2006, heavytull wrote:
>>> the "loop" module on my linux box is not loaded itself when needed by
>>> mount. when I type mount -o loop ...
[...]
>> i'll bet you've gone and mucked with your kernel, hey?
> you mean?
> you mean that i custom tuned the kernel?

Right, tuned, tinkered, or trashed it, ie, not one of the reliable
pre-built distribution jobbers passed out by slackware inc. That's
a uesful bit to know for understanding your problem, what you are
trying to ask, helps narrows things down.

> yes i'm doing so since long. but I don't think this is related to that. the
> troubles with loop and some others started when i upgraded to Slack11

It is not only related, but in fact key and central to your issue.
This is not to be ashamed of, many people muck with their kernels,
myself i have too. But as we see here:

[...]
>> $ grep -i loop /boot/config /proc/devices
>>
> /boot/config : file does not exist
> grep -i loop /proc/devices : nothing
>

.... you've gone and removed the very feature you're now looking
for a solution to make it work just the way you want, like it did
before some round of upgrades. But since it used to work,
it's a good guess that some upgraded component is responsible for
the change in behaviour, be it bug, bugfix, or feature. Other
possibilities still exist, (eg., are you giving mount a -t arg ?
have you mucked with your /etc/mtab too ?) , but as in any case,
the first thing to do is look at our friend and yours, the manual.

yes, RTFM.

you -did- RTFM, didn't you?
i mean, -everybody- here knows to always RTFM, don't they?

Maybe you missed the section in RTFM mount(8) titled 'THE LOOP DEVICE',
where it says, "see losetup(8)." Or maybe you saw that and actually did
RTFM losetup(8) but just missed the part in RTFM losetup(8) where it
says:
"
If you are using the loadable module you must have the
module loaded first with the command

# insmod loop.o
"

hmmmmmmmmmmmmmmmmmmmmmm.




Well it seems to me that whether it worked that way before or not is
moot, that the way it works now -is- the correct way according to the
fine manual. myself i don't know enough about kernel autoloading
modules to guess why that is what it is. It just is what it is.

So it seems to me that you've got a few options,

(a) the live-with-it option:
explicitly insmod loop.o before mount -o loop.

(b) the easy option, aka the slackware way:
don't rip loop.o out of your kernel if you want to use it.

(c) the hard option, aka the obstinate way:
dig out the losetup and kernel module autoloader code and
see what's changed and if anything can be done about it.

(d) the smart option, aka the Bozo way:
create a little alias script for mount, which checks the
arguments for "-o loop" and does the insmod loop.o as needed,
befor calling /sbin/mount to finish the job.

myself i would go (b) but would suggest you do (d) because it
is minimally invasive, trivial to implement, and should let
you do exactly what you want without further concern. well,
at least until the next upgrade :*)

HTH and RTFM!
--
William Hunt, Portland Oregon USA

On Sat, 16 Dec 2006, heavytull wrote:
> Henrik Carlqvist wrote:
>> heavytull <heavytull@hotmail.com> wrote:
[...]
>>>> i'll bet you've gone and mucked with your kernel, hey?
>>> you mean?
>>> you mean that i custom tuned the kernel?
>>> yes i'm doing so since long. but I don't think this is related to that.
>> I think it does if the default kernel has loopback built in and not as a
>> module.
>>
> no, i have always built loop as module.

yes, but why?


--
William Hunt, Portland Oregon USA

William Hunt wrote:

> On Sat, 16 Dec 2006, heavytull wrote:
>
>> William Hunt wrote:
>>> On Fri, 15 Dec 2006, heavytull wrote:
>>>> the "loop" module on my linux box is not loaded itself when needed by
>>>> mount. when I type mount -o loop ...
> [...]
>>> i'll bet you've gone and mucked with your kernel, hey?
>> you mean?
>> you mean that i custom tuned the kernel?
>
> Right, tuned, tinkered, or trashed it, ie, not one of the reliable
> pre-built distribution jobbers passed out by slackware inc. That's
> a uesful bit to know for understanding your problem, what you are
> trying to ask, helps narrows things down.
>
>> yes i'm doing so since long. but I don't think this is related to that.
>> the troubles with loop and some others started when i upgraded to Slack11
>
> It is not only related, but in fact key and central to your issue.
> This is not to be ashamed of, many people muck with their kernels,
> myself i have too. But as we see here:
>
> [...]
>>> $ grep -i loop /boot/config /proc/devices
>>>
>> /boot/config : file does not exist
>> grep -i loop /proc/devices : nothing
>>
>
> ... you've gone and removed
what????? config?
I have never removed it. probably it has been removed when I upgraded ST
or never existed in slack 10.2 or 11




> the very feature you're now looking
> for a solution to make it work just the way you want, like it did
> before some round of upgrades. But since it used to work,
> it's a good guess that some upgraded component is responsible for
> the change in behaviour, be it bug, bugfix, or feature. Other
> possibilities still exist, (eg., are you giving mount a -t arg ?
> have you mucked with your /etc/mtab too ?) , but as in any case,
> the first thing to do is look at our friend and yours, the manual.
>
> yes, RTFM.
>
> you -did- RTFM, didn't you?
i did;
they also talk about how to custom tune the kernel.

> i mean, -everybody- here knows to always RTFM, don't they?
>
> Maybe you missed the section in RTFM mount(8) titled 'THE LOOP DEVICE',
> where it says, "see losetup(8)." Or maybe you saw that and actually did
> RTFM losetup(8) but just missed the part in RTFM losetup(8) where it
> says:
> "
> If you are using the loadable module you must have the
> module loaded first with the command
>
> # insmod loop.o
> "
>
> hmmmmmmmmmmmmmmmmmmmmmm.
>
>
>
>
> Well it seems to me that whether it worked that way before or not is
> moot, that the way it works now -is- the correct way according to the
> fine manual.
well I'm not sure actually whether I built it in or not.
It was probably built in. I actually think that's it because I was having a
problem with it, It was working fine at the beginning but after some time I
noticed the loop devices were never released, so after having mounted and
unmounted 6 or 7 times I couldn't do anything. I had to kill the process
which was sucking the loop device and didn't want to release.
So at my later update of kernel i might have decided to build the loop as
module.


> myself i don't know enough about kernel autoloading
> modules
I need to study how auto loader works.


> to guess why that is what it is. It just is what it is.
>
> So it seems to me that you've got a few options,
>
> (a) the live-with-it option:
> explicitly insmod loop.o before mount -o loop.
>
> (b) the easy option, aka the slackware way:
> don't rip loop.o out of your kernel if you want to use it.
>
> (c) the hard option, aka the obstinate way:
> dig out the losetup and kernel module autoloader code and
> see what's changed and if anything can be done about it.
>
> (d) the smart option, aka the Bozo way:
> create a little alias script for mount, which checks the
> arguments for "-o loop" and does the insmod loop.o as needed,
> befor calling /sbin/mount to finish the job.
>
> myself i would go (b) but would suggest you do (d) because it
> is minimally invasive, trivial to implement, and should let
> you do exactly what you want without further concern. well,
> at least until the next upgrade :*)
but you say it is the bozo option.
I don't like that I prfer my option above first then i'll do the job.

anyway you seem a bit angry at people who custom tune their linux box,
probably you don't know that this is the advantage of Open src OS over
closed src OS.
how would you do if you had hardware that stable driver was released
yesterday? stay with the unstable one shipped with your distro? wait for
the next release of your distro?
or remove the old one and install the new one? then probably you'll have to
put your hands into the kernel. this often happens.



>
> HTH and RTFM!

--
heavytull