Bug 168989 - RHEL4: losetup (and mount -o loop) wrap at 2GB
Summary: RHEL4: losetup (and mount -o loop) wrap at 2GB
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: util-linux
Version: 4.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Karel Zak
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: 168429
TreeView+ depends on / blocked
 
Reported: 2005-09-21 20:51 UTC by Niels Basjes
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version: RHBA-2006-0061
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-03-07 18:05:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0061 0 qe-ready SHIPPED_LIVE util-linux bug fix update 2006-03-06 05:00:00 UTC

Description Niels Basjes 2005-09-21 20:51:36 UTC
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:

Comment 1 Niels Basjes 2005-09-21 20:53:07 UTC
Oeps forgot the version of my rpm: util-linux-2.12a-24.4

Comment 2 Karel Zak 2005-09-21 21:15:46 UTC
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 18:05:14 UTC
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



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