Bug 497568
Summary: | RFE: livecd-tools should make images that default max_loop=14 or higher | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul W. Frields <stickster> |
Component: | livecd-tools | Assignee: | Jeremy Katz <katzj> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | davidz, katzj |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-04-24 23:41:05 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Paul W. Frields
2009-04-24 18:54:25 UTC
Once upon a time, we did. Then we changed the kernel default. Now we don't do anything special because a) loop is built-in, not modular b) the kernel automatically starts to allocate more loop devices for you as you need them I understand (a), sorry I missed that important point. But as for (b), are you sure? I just tried this in a Rawhide VM guest, and I stop getting loop devices (using 'losetup -f <file>') after the eight pre-created devices /dev/loop{0..7} are exhausted. I'd be tempted to reopen this if you find this isn't another PEBCAK problem. Erratum: I guess it wouldn't be reopening as much as opening a new bug to the kernel if autocreation of /dev/loop* is not happening as expected. Upstream support for dynamic loop allocation is commit http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a47653fc2643cf61bcabba8c9ff5c45517c089ba And from the try I did on Friday with lots of losetup -f [katzj@erebor ~]$ sudo losetup -a /dev/loop0: [fd03]:892295 (/var/tmp/imgcreate-2u4B_K/tmp-T4locA/ext3fs.img) /dev/loop1: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop2: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop3: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop4: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop5: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop6: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop7: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop8: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop80: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop81: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop82: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) /dev/loop83: [fd01]:42401853 (/home/live/live/rawhide-20090423/rawhide-i686-20090423.0.iso) Ah, according to that commit, you still have to mknod manually, but the new device will be supported on demand. Too bad the all-in-one process broke things, it would have been nice to be a little more automatic. Thanks for the info though! |