Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 168989 - RHEL4: losetup (and mount -o loop) wrap at 2GB
RHEL4: losetup (and mount -o loop) wrap at 2GB
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: util-linux (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
Depends On:
Blocks: 168429
  Show dependency treegraph
Reported: 2005-09-21 16:51 EDT by Niels Basjes
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version: RHBA-2006-0061
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-07 13:05:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0061 qe-ready SHIPPED_LIVE util-linux bug fix update 2006-03-06 00:00:00 EST

  None (edit)
Description Niels Basjes 2005-09-21 16:51:36 EDT
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:

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:
Comment 1 Niels Basjes 2005-09-21 16:53:07 EDT
Oeps forgot the version of my rpm: util-linux-2.12a-24.4
Comment 2 Karel Zak 2005-09-21 17:15:46 EDT
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.
Comment 9 Red Hat Bugzilla 2006-03-07 13:05:14 EST
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.


Note You need to log in before you can comment on or make changes to this bug.