Bug 168989
| Summary: | RHEL4: losetup (and mount -o loop) wrap at 2GB | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Niels Basjes <fedora> |
| Component: | util-linux | Assignee: | Karel Zak <kzak> |
| Status: | CLOSED ERRATA | QA Contact: | Ben Levenson <benl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHBA-2006-0061 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-03-07 18:05:14 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 168429 | ||
Oeps forgot the version of my rpm: util-linux-2.12a-24.4 Ah.. good catch. The offset option in losetup in FC3 and RHEL4 is based on "int" datetype. The problem is fixed in FC4. In FC3 it will be fixed in next util-linux update. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2006-0061.html |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 (No IDN) Firefox/1.0.6 Description of problem: If you specify an offset value larger than 2GB (2^32) for losetup or mount -o loop you will not get the expected result (i.e. it will wrap). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Example of an actual situation: On an existing system I did: dd if=/dev/hda of=20GBDiskImageOfWin98.dd Later on my FC3 system I did: losetup /dev/loop0 20GBDiskImageOfWin98.dd fdisk -lu /dev/loop0 Disk /dev/loop0: 20.4 GB, 20419854336 bytes 16 heads, 63 sectors/track, 39566 cylinders, total 39882528 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/loop0p1 * 63 23489423 11744680+ c W95 FAT32 (LBA) /dev/loop0p2 23489424 39873455 8192016 f W95 Ext'd (LBA) /dev/loop0p5 23489487 39873455 8191984+ b W95 FAT32 So I make loop1 the first partition and mount it losetup -o $((63*512)) /dev/loop1 /dev/loop0 mount -t /dev/loop1 /mnt/C (Succesfully mounted) Sam for the other partition (nr 5): losetup -o $((23489487*512)) /dev/loop3 /dev/loop0 mount -t /dev/loop2 /mnt/D (Files miserably) Now if I use dd to extract the partition in a separate file I can mount that succesfully dd if=/dev/loop0 skip=23489487 of=D.img count=$((8191984*2)) mount -o loop D.img /mnt/D/ I asked some people to verify this and we came to the conclusion that losetup and mount -o loop must use some code that wraps the offset parameter at the 2^32 limit on a pentium (i386) system. Additional info: