How to make extra loop devices? (Solved)

[sunburnt]

I've heard a number of folks talk about needing more loop devices, & I"ve needed more too.
I've made a GUI utility tool to make extra loop devices, but the files it makes don't show the drive icon.
The commands I got from the web are:

mknod -m660 /dev/loop$i b 7 $i
chown root.root /dev/loop$i
chmod 666 /dev/loop$i

$i is the number of course.
Are they still good anyway, even though they don't show as loop devices?

How about just copying an existing loop device to a temp. dir., rename it to loop5, & then copy it back to /dev?
This would certainly be much easier than the commands that don't seem to work.

[Flash]

I think I've seen a post that answers your question, but I can't quite remember it. Have you tried using the forum search engine?

[sunburnt]

Yes, I seem to recall a post about it, can't find it, & can't remember if it had a solution, the search isn't very specific.
I think I'll just have to do it the good old fashion way... the way I do most everything, EXPERIMENT!
So time consuming for little things that shouldn't have to be done in the first place.
If I find a solution I'll post it in the How To forum.

[Flash]

OK, and thanks. Sorry I couldn't help. I did find one post that pretty well explained what a loop device is, but I figured you already knew that.

[jmarsden]

I've heard a number of folks talk about needing more loop devices, & I"ve needed more too.
I've made a GUI utility tool to make extra loop devices, but the files it makes don't show the drive icon.

Can you rephrase that, or provide a clear example someone else can follow? Either it makes a loopback device file, or it doesn't... how stuff appears in some GUI tool or other may or may not reflect reality. Trust the simple well known tools -- what does ls -l /dev/loop* display, for instance?

Code: Select all

22:32:52 root@jm:/dev# ls -l loop*
brw-r-----    1 root     6          7,   0 Sep 27  2000 loop0
brw-r-----    1 root     6          7,   1 Sep 27  2000 loop1
brw-r-----    1 root     6          7,   2 Sep 27  2000 loop2
brw-r-----    1 root     6          7,   3 Sep 27  2000 loop3
brw-r-----    1 root     6          7,   4 Sep 27  2000 loop4
22:32:56 root@jm:/dev#

OK, those are the default loop device nodes in 1.0.8r1 on my box here. Now, we can try the commands you suggest, first setting i=5, and then run the ls command again:

Code: Select all

22:32:56 root@jm:/dev# i=5
22:34:50 root@jm:/dev# mknod -m660 loop$i b 7 $i
22:34:57 root@jm:/dev# chown root:root loop$i
22:35:15 root@jm:/dev# chmod 666 loop$i
22:35:21 root@jm:/dev# ls -l loop$i
brw-rw-rw-    1 root     root       7,   5 Feb 28 22:35 loop5
22:36:06 root@jm:/dev#

We can immediately see that your commands generate a device with different ownership and permissions from the ones Puppy provides. (I also note that it seems odd to use the mknod -m option to set a mode for the created device file, and then change it to somethong else just two lines later -- what is the point?). I'd suggest that

Code: Select all

mknod -m640 loop$i b 7 $i
chown root:6 loop$i

might get you something closer to the Puppy originals. Let's set i=6 and try that:

Code: Select all

22:38:19 root@jm:/dev# i=6; mknod -m640 loop$i b 7 $i ; chown root:6 loop$i ; ls -l loop$i
brw-r-----    1 root     6          7,   6 Feb 28 22:41 loop6
22:38:32 root@jm:/dev#

Yes, looks much more like the originals to me.

Now to test the results. I have a .iso file or two around, so I can loopmount one onto /dev/loop6 and see if that works:

Code: Select all

22:55:26 root@jm:/dev# losetup /dev/loop6 /mnt/home/puppy/puppy2alpha-seamonkey.iso 
22:55:40 root@jm:/dev# mount /dev/loop6 /mnt/cdrom
22:55:45 root@jm:/dev# ls -l /mnt/cdrom
-r--r--r--    1 root     root         2048 Feb 12 14:54 boot.cat
-rw-r--r--    1 root     root      1676267 Feb 12 14:51 initrd.gz
-rw-rw-r--    1 1026     1026        10648 Feb 12 01:39 isolinux.bin
-rw-r--r--    1 root     root           61 Feb 11 18:21 isolinux.cfg
-rwx------    1 root     root     66019328 Feb 12 14:53 pup_003.sfs
-rw-r--r--    1 root     root      1297152 Feb 12 14:51 vmlinuz
22:55:49 root@jm:/dev# umount /mnt/cdrom

Seems to work fine here. So, the code you really wanted to provide was probably:

Code: Select all

 for i in {5..7} ; do mknod -m 640 /dev/loop$i b 7 $i ; chown root:6 /dev/loop$i ; done

That gets you 3 extra working loop devices in one line. Going to more that 8 loop devices (replacing 5..7 with 5..255 for example) creates the nodes just fine (of course), but whether the kernel can use them all becomes kernel-compilation-option dependent... and I'm not testing that right now, it's time for bed!

Only once the new device files are tested and known to work at the command line should we start thinking about how well or badly they may work with GUI tools like MUT. That's a whole extra layer of complexity we don't need in our initial experiments (and one I'll let you explore further at your leisure, since I rarely use MUT myself).

Question: Why would a tool to make device nodes need a GUI? What sort of graphical user interaction is needed? At most, you could package the one liner above into a dotpup, which people can click to execute?

Final thought: Since Puppy comes with files having gid 6, it would be a nice touch to have that gid in /etc/group so we can refer to it by name... please Barry? Or should they really be set to some other gid?

Jonathan

[sunburnt]

Thanks jmarsden; you did what I was thinking of doing, adjusting the properties of the device file.
I don't have a very clear picture of this & the tools I have don't clarify it much.
Somewhere I saw a list of the property codes for working with all of this.

Puppy should have the max default 8 loops at least, 8 is enough for most purposes.
To get more than the kernel default amount of 8 loop devices there's 2 ways:

Add to the kernel argument: vmlinuz ....... max_loop=16
Add line in the file /etc/modules.conf: options loop max_loop=16

Being as the modules.conf file doesn't seem to persist on reboot (see other post), the kernel argument should work.

The GUI is a tool to make/mount image files (image, iso, & squash) & to add extra loops if needed.

[jmarsden]

The GUI is a tool to make/mount image files (image, iso, & squash) & to add extra loops if needed.

Since these all have reasonably well-known file extensions, perhaps making this a simple script that is executed when such files are clicked on in Rox is sufficient? No need for creating a GUI, no input is needed from the user except "I want to work with this file" and (maybe) where to mount it. In practice, does the user care where to mount each filesystem? Probably not, in most cases they just want to mount it and have Rox open a window onto the newly mounted fs. They will use any default you provide. So why ask them the question, it only adds delay and complexity. Instead, just create /mnt/loop/[0-7] and mount stuff there when clicked? If all the first 8 loop devices are in use, create the next 8 and start using them, automatically?

This approach would (I think) mean that you script itself has no UI, and so can be used from the command line too

Code: Select all

# loopmount somefile.iso

or whatever. (You might need an error message function which could either echo or xmessage any error output depending on whether the script was called from Rox or from a shell?).

Just some thoughts, ignore them if you wish -- it's your script

Jonathan

[sunburnt]

Yep, I said in a post awhile back that it'd be nice if the ROX right click menu did much more.
File compress & decompress: tar, gz, zip, rar, & file mounting: image, iso, squash.
Inhancements to ROX would GREATLY improve Puppy for all, especially noobies & no extra apps. needed.
I haven't looked at ROX much & I don't know how the right click menu works.
But MU gave me XFE which I like MUCH better (ROX drives me nuts jumping all over the place, but it works).
Being a Win. convert I find the tree+list file browser to be a very fast & easy way to work.
Unfortunately it was made with the Fox ToolKit & it's menu setup doesn't seem to be easy to change.
Why can't the menu be a single text file, or dirs. (ala Win.), after all... it's only a menu.

[jmarsden]

Yep, I said in a post awhile back that it'd be nice if the ROX right click menu did much more. ...
I haven't looked at ROX much & I don't know how the right click menu works.

Read the manual: http://rox.sourceforge.net/Manual/Manual/Manual.html

Puppy often makes it really hard for people to learn, by omitting documentation... even omitting a working man command. I think it's a very unfortunate design choice, even though I understand the space constraints that led to it. Do we want Puppy users to be passive consumers, or active learners? Maybe one day a revised usr_devx.sfs will "add back in" the documentation, so at least developers have it right there to read.

Jonathan

[GuestToo]

Puppy may not have included all documentation, but it has not omitted the Rox documentation, of course ... just hit F1 when the Rox window has focus, or click the Help icon, or click Show Help Files in the Rox menu ... Rox is an easy to use file manager with convenient and useful features, and reading the documentation is worthwhile