/dev/loop* created with wrong permissions

[kevinfish]

when I first went to install tc to my notebook I plugged in my pen drive I was using for the tce on my desktop.  It went to load/mount a bunch of tce packages and blew chunks after about 80 of them.  I found out that all the loop files past 80 were created with root:root owner/group instead of root:staff.

As a hack/fix I chowned all of them to root:staff and added dev to my .filetool.lst but this should probably be fixed

Also, occasionally, for some reason unknown to me, ~tc is root:root, not write-able and X won't start because it can't create the .Xauthority file.

[curaga]

The devices don't really matter, it's the max_loop parameter which defaults to 80. The loop devices beyond that won't exist, so having the nodes there with wrong ownership doesn't matter.

They will get the proper ownership when you increase the limit, for all existing loop devices. Add max_loop=256 to your boot arguments to have the max amount.

[kevinfish]

the bizarre thing is that all the loop files (up to 256) are there when I look, but all the ones past 80 have root:root ownership, so apparently not having that flag is not really saving any space (at least on my system).

[maro]

I believe I can offer some explanation for the findings: The initrd of TC 2.9 contains 255 block devices ('/dev/loop0' to '/dev/loop254'), all of them with permission 664 and ownership of 'root:root'. Their only difference (apart from their minor number) is their respective time stamp ('2009-04-18 16:34:50' for 0 to 31, '2009-09-20 20:24:23' for 32 to 79, and '2009-10-03 19:32:54' for 80 to 254).

It appears that during the boot process the kernel creates a new set of loop devices. If no 'max_loop' kernel parameter is specified the devices 0 to 79 are re-created with permission 660, ownership of 'root:staff' and the current time stamp. For TC 2.9 the 'isolinux.cfg' contains 'max_loop=256' as parameter, so the kernel would re-create all 255 nodes provided by the initrd and add one more. I guess the default value is a kernel compile time choice, and if one would like to change it a kernel rebuild would be required.

By the way, I don't think that these block devices will "cost" much memory at all.

[curaga]

3.x will have unlimited loops.