Bug 473524 - dosfslabel failed on device /dev/sda1: There are differences between boot sector and its backup
dosfslabel failed on device /dev/sda1: There are differences between boot sec...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: dosfstools (Show other bugs)
11
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jaroslav Škarvada
Fedora Extras Quality Assurance
anaconda_trace_hash:6e3fc84e4c535a850...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-28 22:27 EST by Danilo Câmara
Modified: 2010-03-16 08:49 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-16 08:49:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Attached traceback automatically from anaconda. (67.40 KB, text/plain)
2008-11-28 22:27 EST, Danilo Câmara
no flags Details
Attached traceback automatically from anaconda. (68.79 KB, text/plain)
2008-12-31 06:10 EST, Mike C
no flags Details
fsck output in corrupted partition (1.03 KB, text/plain)
2008-12-31 09:34 EST, Danilo Câmara
no flags Details

  None (edit)
Description Danilo Câmara 2008-11-28 22:27:25 EST
This bug was filed automatically by anaconda.
Comment 1 Danilo Câmara 2008-11-28 22:27:31 EST
Created attachment 325061 [details]
Attached traceback automatically from anaconda.
Comment 2 Danilo Câmara 2008-12-01 12:28:51 EST
During install I can not set the mount point for the Windows partition (/mnt/windows) otherwise the installer will fail. From the traceback:

SystemError: dosfslabel failed on device /dev/sda1: There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  430:46/52, 431:61/65, 432:6c/6d, 433:74/6f, 434:61/76, 435:20/61, 436:4e/20
  , 437:54/64, 438:4c/69, 439:44/73, 440:52/63, 441:ff/6f, 442:0d/73
  , 443:0a/20, 444:45/6f, 445:72/75, 446:72/20, 447:6f/6d, 448:2f/a1
  , 451:73/61, 452:63/2e, 453:6f/ff, 454:ff/0d, 455:0d/0a, 456:0a/45
  , 457:50/72, 459:65/6f, 460:73/2f, 461:73/64, 463:6f/73, 464:6e/63
  , 465:65/6f, 466:20/ff, 467:74/0d, 468:65/0a, 469:63/50, 470:6c/72
  , 471:61/65, 472:20/73, 473:70/73, 474:61/69, 475:72/6f, 476:61/6e
  , 477:20/65, 478:72/20, 479:65/74, 480:69/65, 481:6e/63, 482:69/6c
  , 483:63/61, 484:69/20, 485:61/70, 486:72/2f, 487:0d/72, 488:0a/65
  , 489:00/69, 490:00/6e, 491:00/69, 492:00/63, 493:00/69, 494:00/61
  , 495:00/72, 496:00/0d, 497:00/0a, 506:ba/c6, 507:c7/d3
  Not automatically fixing this.

I guess this is an uncommon situation so nobody else is complaining about. But it happened to me in every upgrade since Fedora 8. This is the first time the traceback was saved and I read it carefully.

Looks like I can not fix it with fsck. Maybe someday if I'm adventurous enough to run Windows and let it fix.
Comment 3 Danilo Câmara 2008-12-04 18:26:04 EST
My suggestion is for the installer to report the partitions that have problems and not use/configure them if they're not essential to the installation.
Comment 4 Mike C 2008-12-31 06:10:22 EST
Created attachment 328004 [details]
Attached traceback automatically from anaconda.
Comment 5 Mike C 2008-12-31 06:48:26 EST
In my case I had asked the install not to format a non-essential vfat partition but to have it mounted after the install completed, and anaconda crashed as above. I started the install again and this time asked it to format the vfat partition - which worked fine.

As a third test once the partitions had been formatted I stopped the install and restarted it - this time selected to label the vfat partition but not format it and it worked fine.

It seems there was some problem with the original partition that once the formatting had been completed by the partitioning tool in the install media it was happy to accept.
Comment 6 Danilo Câmara 2008-12-31 09:31:30 EST
The problem is in the partition (There are differences between boot sector and its backup.). fsck report this and offer to copy one over the other but actually does nothing (see next attachment). Nevertheless I can mount it and access data fine after installation. I was not willing to format it as I would have to reinstall Windows XP and have it mess with the MBR.
Comment 7 Danilo Câmara 2008-12-31 09:34:07 EST
Created attachment 328012 [details]
fsck output in corrupted partition
Comment 8 Orion Poplawski 2009-03-25 14:15:19 EDT
Looks like a dupe of bug #444386

I'm also seeing this with a USB drive:

# dosfslabel /dev/sdb1
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  71:54/74, 72:52/72, 73:54/74
  Not automatically fixing this.
TRT0_USB

Don't appear to be able to fix with dosfsck:

# dosfsck /dev/sdb1
dosfsck 3.0.0, 28 Sep 2008, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
  71:54/74, 72:52/72, 73:54/74
1) Copy original to backup
2) Copy backup to original
3) No action
? 1
Leaving file system unchanged.
/dev/sdb1: 91293 files, 1504407/7629261 clusters
Comment 9 Bug Zapper 2009-06-09 05:59:15 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Jaroslav Škarvada 2010-03-16 08:49:14 EDT
Tested with dosfstool-3.0.1-4 on F11 (the oldest supported version) and it works perfectly here, usage:

1) dosfsck -r DEVICE
2) Select if original or backup bootsector will be used
3) Confirm filesystem change

If you install without formatting, please repair your filesystems first. Having non matching boot sector backup is dangerous and I strictly encourage you not to use such a configuration in production environment. If you have problems with anaconda, please file bug to anaconda.

In case of trouble with dosfstools, please also try to use dosfstools-3.0.9-2.fc14 from rawhide - there are many bux fixes.

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