heavytull <heavytull@hotmail.com> wrote:
>>>> $ grep -i loop /boot/config /proc/devices
>>>>
>>> /boot/config : file does not exist

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

In Slackware /boot/config comes from your kernel package. The file config
should be a copy of the file .config from the kernel source tree. This
file is really usable when you want to compile a custom kernel. Instead of
starting from scratch you start with a good known working configuration
and change only the things that you want to change.

In Slackware 11 as well as in Slackware 10.2 in the a directory there is a
package called kernel-ide-* That package contains the boot/config file. If
you have the file /var/log/packages/kernel-ide-* it means that you have
this package installed and at least once had the config file on your
system.

In the kernels directory there are also other kernels with different
configurations. All those kernels have a corresponding config file
included.

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 Sun, 17 Dec 2006, heavytull wrote:
> 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?

no, no, not the config file. You've "removed", aka "disabled",
aka "switched off" the builtin loop device drivers by modifying
your kernel config file and then compiling and installing a
custom kernel from that modified config. The lack of builtin
loop device is why you currently need to load the loop.o module
before mounting a filesystem "-o loop". That's what your
original questions were about, right?


> I have never removed it. probably it has been removed when I upgraded ST
> or never existed in slack 10.2 or 11

"CONFIG_BLK_DEV_LOOP=y" is in all slackware kernels, excepting
lowmem.i, since at least slackware-8.0, and also in the kernel
distribution default config. i suppose it's possible you started
your custom config from lowmem.i, or a pre-loop distribution, but
in any case, i don't need to play twenty questions to figure out
-how- you got where you are. what matters is knowing where you
are -now-, where you -want- to go next, and then what's the best
way to get there from here.

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


???

maybe you missed:

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

doesn't matter -how- you got there. where you're at now is
discussed in losetup(8).

a free clue: there are 8 loop devices, by default.
a free clue: mount -o loop requires an unused loop device.
a free clue: umount does not always free loop devices.
a free clue: loop devices may be freed for reuse.
a free clue: loop devices may be reused without freeing.

you can learn all that and MORE yes MORE at the
unbelievable LOW LOW price of ZERO ZERO ZERO duckets
and not one thin dime more by simply reading RTFM losetup.

if you're going to mess with "mount -o loop" at all, you really
really really should read RTFM losetup(8). Which is what one
would learn if one read RTFM mount(8).


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

sure, myself i suspect a kernel autoloader solution would
be dificult for mortals like us to achieve.

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

that's 'Bozo' not 'bozo', as in 'aols Bozo'. aols Bozos promote
principles which include 'do what you want, but do it right' and
Bozos like goal-oriented solutions that can be implemented trivially
with standard facilities in a minimally invasive manner. And Bozos
promte the education, liberation and empowerment of all through RTFM.

> I don't like that I prfer my option above first then i'll do the job.

option (a) the live-with-it option ?
Then you really better RTFM losetup(8) so to avoid potential problems.
see free clues listed above.

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

hey, it's your machine, tune it any way you want, okay by me. that
is exactly what i'm trying to help you to do!

myself i'm running all slackware default kernels right now, but have
built and run custom kernels many times, sometimes for good reasons.
(I may have one custom kernel out there still - one of my operators
still has a 20MB 486 for a workstation but i'm not planning on
deploying any more of those :*) I'm running default kernels because
i don't have any reason not to.

The -only- time it matters to me what kernel someone else is running,
is when that someone else is here on aols asking for help with a
problem and i suspect that the problem is directly related to the
kernel in use and even more so when i suspect the problem is directly
related with the use of a custom kernel.

Which, as it turns out, is exactly the case here.

So,
- i gave you a correct diagnosis of your problem,
- i gave you the man pages which specifically discusses
your problem.
- i gave you 4 options to achieve your goal, of which
none in any way suggests not using a custom kernel.

jeez, what more do you want?






oh, uh, "You're welcome", i guess.

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

William Hunt wrote:

> no, no, not the config file. You've "removed", aka "disabled",
> aka "switched off" the builtin loop device drivers by modifying
> your kernel config file and then compiling and installing a
> custom kernel from that modified config. The lack of builtin
> loop device is why you currently need to load the loop.o module
> before mounting a filesystem "-o loop". That's what your
> original questions were about, right?
>
>
what?
re-say it!


>> I have never removed it. probably it has been removed when I upgraded ST
>> or never existed in slack 10.2 or 11
>
> "CONFIG_BLK_DEV_LOOP=y" is in all slackware kernels, excepting
> lowmem.i, since at least slackware-8.0, and also in the kernel
> distribution default config. i suppose it's possible you started
> your custom config from lowmem.i, or a pre-loop distribution, but
> in any case, i don't need to play twenty questions to figure out
> -how- you got where you are. what matters is knowing where you
> are -now-, where you -want- to go next, and then what's the best
> way to get there from here.
>
>>
>>
>>> 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.
>
>
> ???
>
> maybe you missed:
>
>>> 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.
>
> doesn't matter -how- you got there. where you're at now is
> discussed in losetup(8).
>
> a free clue: there are 8 loop devices, by default.
> a free clue: mount -o loop requires an unused loop device.
> a free clue: umount does not always free loop devices.
> a free clue: loop devices may be freed for reuse.
> a free clue: loop devices may be reused without freeing.
>
> you can learn all that and MORE yes MORE at the
> unbelievable LOW LOW price of ZERO ZERO ZERO duckets
> and not one thin dime more by simply reading RTFM losetup.
>
> if you're going to mess with "mount -o loop" at all, you really
> really really should read RTFM losetup(8). Which is what one
> would learn if one read RTFM mount(8).
>
ok, you mean the slack book?

i will read it again.
i have read it partly for what i needed before and after install of slack,
but have mostly found it incomplete and useless.





>
>>
>>> myself i don't know enough about kernel autoloading
>>> modules
>> I need to study how auto loader works.
>
> sure, myself i suspect a kernel autoloader solution would
> be dificult for mortals like us to achieve.
>
>>
>>> 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.
>
> that's 'Bozo' not 'bozo', as in 'aols Bozo'. aols Bozos promote
> principles which include 'do what you want, but do it right' and
> Bozos like goal-oriented solutions that can be implemented trivially
> with standard facilities in a minimally invasive manner. And Bozos
> promte the education, liberation and empowerment of all through RTFM.
>
>> I don't like that I prfer my option above first then i'll do the job.
>
> option (a) the live-with-it option ?
> Then you really better RTFM losetup(8) so to avoid potential problems.
> see free clues listed above.
>
>>
>> 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.
>
> hey, it's your machine, tune it any way you want, okay by me. that
> is exactly what i'm trying to help you to do!
>
> myself i'm running all slackware default kernels right now, but have
> built and run custom kernels many times, sometimes for good reasons.
> (I may have one custom kernel out there still - one of my operators
> still has a 20MB 486 for a workstation but i'm not planning on
> deploying any more of those :*) I'm running default kernels because
> i don't have any reason not to.
>
> The -only- time it matters to me what kernel someone else is running,
> is when that someone else is here on aols asking for help with a
> problem and i suspect that the problem is directly related to the
> kernel in use and even more so when i suspect the problem is directly
> related with the use of a custom kernel.
>
> Which, as it turns out, is exactly the case here.
>
> So,
> - i gave you a correct diagnosis of your problem,
> - i gave you the man pages which specifically discusses
> your problem.
> - i gave you 4 options to achieve your goal, of which
> none in any way suggests not using a custom kernel.
>
> jeez, what more do you want?
>
nothing else
>
>
>
>
>
> oh, uh, "You're welcome", i guess.
>
>>
>>
>>>
>>> HTH and RTFM!

--
heavytull

On Sun, 17 Dec 2006, heavytull wrote:

> William Hunt wrote:
>
>> no, no, not the config file. You've "removed", aka "disabled",
>> aka "switched off" the builtin loop device drivers by modifying
>> your kernel config file and then compiling and installing a
>> custom kernel from that modified config. The lack of builtin
>> loop device is why you currently need to load the loop.o module
>> before mounting a filesystem "-o loop". That's what your
>> original questions were about, right?
>>
>>
> what?
> re-say it!

WTF is with this "re-say it!" crap?
Didn't your mommy teach to to say 'Please' and 'Thank You' ?
I'll put it to you one more time as simple as i can:

You've fucked yourself.

You've modified your system by installing a custom kernel which among
whatever other joys it brings you also features CONFIG_BLK_DEV_LOOP=m
which disables features of the mount command that are otherwise
available, specifically the abilitty of the mount command to
automatically associate a loop device. This choice became manifest as
a problem when the mount command did not operate for you as expected
but then you fucked yourself by failing to use the "man" command to
read the manual page ("RTFM") for the mount command, "man mount", thus
missing the key pieces of information given there which is pretty much
all you need to know to quickly create a solution to your problem
yourself. So after that it mostly went downhill for you. You fucked
yourself again by getting all pissy thinking your custom tuned kernel
was under attack. And now you've fucked yourself again by pissing me
off just trying to help you with your questions.
i'm done with you.
Bye.


>
>>> I have never removed it. probably it has been removed when I upgraded ST
>>> or never existed in slack 10.2 or 11
[...]

--
William Hunt, Portland Oregon USA

William Hunt <wjh@prv8.net> wrote:
> So it seems to me that you've got a few options,

You missed option e):
explicitly (always) load loop from the rc.modules file (you can use
"/sbin/modprobe loop" there).
That's what I always done, the line will fail (but not abort) when the
module has been built-in but will always load it when it IS a module.
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************

William Hunt wrote:

> On Sun, 17 Dec 2006, heavytull wrote:
>
>> William Hunt wrote:
>>
>>> no, no, not the config file. You've "removed", aka "disabled",
>>> aka "switched off" the builtin loop device drivers by modifying
>>> your kernel config file and then compiling and installing a
>>> custom kernel from that modified config. The lack of builtin
>>> loop device is why you currently need to load the loop.o module
>>> before mounting a filesystem "-o loop". That's what your
>>> original questions were about, right?
>>>
>>>
>> what?
>> re-say it!
>
> WTF is with this "re-say it!" crap?
> Didn't your mommy teach to to say 'Please' and 'Thank You' ?
> I'll put it to you one more time as simple as i can:
>
> You've fucked yourself.
>
hey calm down;

> You've modified your system by installing a custom kernel
when i stated with slack it was the 10.2, all the kernel configs suggested
by the distro were unsuitable for my machine. there were so many problems
(for both bare.i and other 2.4.xx and the test26.i) that i couldn't even
start the X.
anyway i don't even have to explain all this just regarding how much you
seem to be dumb and kook but i do because I believe you need a last chance.


> which among
> whatever other joys it brings you also features CONFIG_BLK_DEV_LOOP=m
> which disables features of the mount command that are otherwise
> available, specifically the abilitty of the mount command to
> automatically associate a loop device. This choice became manifest as
> a problem when the mount command did not operate for you as expected
> but then you fucked yourself
shut up

> by failing to use the "man" command to
> read the manual page ("RTFM") for the mount command
I always use the manuals in unix and I really like the way they are done.
when you told me before i though you were talking about the slack book
which i find to be quite useless.

At the beginning when I was mounting a fs with the loop option, all devices
were released automatically by umount, so when some day it appeared to no
more do like that i obviously thought that something is no more running
well in this Linux box, and this is not the man pages that can help you.
you have to manage. I knew that i could release them, but since they hadn't
been done automatically I tried to solve to problem. so now whether or not
the problem was only because the loop device was built in or compiled as
module: i don't know! but there are often such phenomenon in linux. someday
it works and some day it doesn't anymore. sometimes i locate the problem
and sometimes my knowledge of linux is not enough. And people like you a
bit over excited come up and have finally spend their energy inefficiently.

> , "man mount", thus
> missing the key pieces of information given there which is pretty much
> all you need to know to quickly create a solution to your problem
> yourself.
I was not looking for finding a solution, but to find what created the
problem.
Actually the way you seem to do is always to put a solution on top of all
instead of finding why the system is no more doing like before. this is
like covering of paper a wall that is cracking.

> So after that it mostly went downhill for you. You fucked
> yourself again by getting all pissy thinking your custom tuned kernel
> was under attack.
shut up

> And now you've fucked yourself again by pissing me
> off
no i have never done that, i think you believe like that just because you
are used to be pissed on by others.


anyway i finish with a positive thing.

the thing that helped in you actions is when you put:
>> 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
>>

yes it has emerged tha idea on whether I actually forgot whether when the
problem started the kernel was just compiled with the loop device as mod.

if yes then everything is ok.
but this thing was flooded into all useless lines you put.






> just trying to help you with your questions.
> i'm done with you.
> Bye.
>
>
>>
>>>> I have never removed it. probably it has been removed when I upgraded
>>>> ST or never existed in slack 10.2 or 11
> [...]
>

--
heavytull

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> In Slackware /boot/config comes from your kernel package. The file config
> should be a copy of the file .config from the kernel source tree.

That is: the one modified for THAT specific kernel build. The one in
the "source" package is generic, not customied at all yet.
This is because there's only one "kernel-source" package, but a lot of
different kernel builds. So each of the latter packages contain their own
/boot/config-<kernel_version>
which is the one, used to build that specific kernel.

Just to make this clear for readers, you probably already know this!
--
************************************************** ******************
** Eef Hartman, Delft University of Technology, dept. EWI/TW **
** e-mail: E.J.M.Hartman@math.tudelft.nl, fax: +31-15-278 7295 **
** snail-mail: P.O. Box 5031, 2600 GA Delft, The Netherlands **
************************************************** ******************

Eef Hartman wrote:

> Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>> In Slackware /boot/config comes from your kernel package. The file config
>> should be a copy of the file .config from the kernel source tree.
>
> That is: the one modified for THAT specific kernel build. The one in
> the "source" package is generic, not customied at all yet.
> This is because there's only one "kernel-source" package, but a lot of
> different kernel builds. So each of the latter packages contain their own
> /boot/config-<kernel_version>
> which is the one, used to build that specific kernel.
>
> Just to make this clear for readers, you probably already know this!
yes
--
heavytull

William Hunt wrote on 12/18/2006 02:03:
> On Sun, 17 Dec 2006, heavytull wrote:
>
>> William Hunt wrote:
>>
>>> no, no, not the config file. You've "removed", aka "disabled",
>>> aka "switched off" the builtin loop device drivers by modifying
>>> your kernel config file and then compiling and installing a
>>> custom kernel from that modified config. The lack of builtin
>>> loop device is why you currently need to load the loop.o module
>>> before mounting a filesystem "-o loop". That's what your
>>> original questions were about, right?
>>>
>>>
>> what?
>> re-say it!
>
> WTF is with this "re-say it!" crap?
> Didn't your mommy teach to to say 'Please' and 'Thank You' ?
> I'll put it to you one more time as simple as i can:
>
> You've fucked yourself.
>
> You've modified your system by installing a custom kernel which among
> whatever other joys it brings you also features CONFIG_BLK_DEV_LOOP=m
> which disables features of the mount command that are otherwise
> available, specifically the abilitty of the mount command to
> automatically associate a loop device.

That is BS.
Modules are loaded as needed, like when mount needs it. That's what
modules are for.
The only thing would be to specify the correct way to load the module
automatically when needed.
Now I suggest you get off your high horse, since you obviously are not
as knowledgeable as you think you are.

On Mon, 25 Dec 2006, Joe Feise wrote:
> William Hunt wrote on 12/18/2006 02:03:
>> On Sun, 17 Dec 2006, heavytull wrote:
>>> William Hunt wrote:
>>>> no, no, not the config file. You've "removed", aka "disabled",
>>>> aka "switched off" the builtin loop device drivers by modifying
>>>> your kernel config file and then compiling and installing a
>>>> custom kernel from that modified config. The lack of builtin
>>>> loop device is why you currently need to load the loop.o module
>>>> before mounting a filesystem "-o loop". That's what your
>>>> original questions were about, right?
>>>>
>>> what?
>>> re-say it!
>>
>> WTF is with this "re-say it!" crap?
>> Didn't your mommy teach to to say 'Please' and 'Thank You' ?
>> I'll put it to you one more time as simple as i can:
>>
>> You've fucked yourself.
>> You've modified your system by installing a custom kernel which among
>> whatever other joys it brings you also features CONFIG_BLK_DEV_LOOP=m
>> which disables features of the mount command that are otherwise
>> available, specifically the abilitty of the mount command to
>> automatically associate a loop device.
>
> That is BS.
> Modules are loaded as needed, like when mount needs it. That's what
> modules are for.
>

You really should read the thread before replying: your assumption
is contradicted by the symptoms the OP reports, That is what the
OP question was: -why- is the module -not- getting loaded? I can
independently confirm that the symptoms reported by the OP can be
demonstrated trivially, having built and tested a kernel to spec
just for that purpose. But don't take my word for it:

$ strings /bin/mount | grep loop
[...]
%s: Could not find any loop device. Maybe this kernel does not know
about the loop device? (If so, recompile or `modprobe loop'.)
[...]

Why do you suppose the authors of mount would have put that in
there, if, as you say, loop.o would be automatically loaded ?



> The only thing would be to specify the correct way to load the module
> automatically when needed.

What way would be the correct way?
If that's the only thing, then why not provide it?
Is the correct way among the 4, 5, 6? different ways already posted?
Are those different ways all incorrect?

You really should read the thread before replying.



> Now I suggest you get off your high horse, since you obviously are not
> as knowledgeable as you think you are.

<ffft>

Now I suggest you kiss my ass, ibid.

I mean, WTF are you attacking ne for ? ? ? If you can show me
where i'm wrong, then great, please do so. Educate me, educate
the OP. Educate the others who've offered solutions. But don't
attack me for just trying to help answer a question! At least
-read- the thread before attacking me. I've already stated, up
front, that my knowledge of the mechanism is limited.

But i do know how to RTFM and i've already quoted the freaking
man page text which yeilds the conclusion you call BS. How about
addressing the text, and pay no mind to the size of my horse.

You may well possess much much more knowledge than my admittedly
meager accumulation, surely it is not a difficult feat to surpass
that measure. But I see little here to support this premise.

oh well.


--
William Hunt, Portland Oregon USA