Bug 485304 - fsck.ext3: Device or resource busy while trying to open /dev/sda
fsck.ext3: Device or resource busy while trying to open /dev/sda
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
9
sparcv9 Linux
low Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-12 14:12 EST by Tom "spot" Callaway
Modified: 2009-02-12 15:40 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-12 15:40:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom "spot" Callaway 2009-02-12 14:12:47 EST
Description of problem:

SPARC systems need to have partition 1 start at cyl 0, this is a must. If we try to start on 1, the Prom won't boot the bootloader. This gives us an on-disk layout like this:

  /dev/sda1 Start: 0 End: 25 Boot
  /dev/sda2 Start: 25 End: 2495 LVM
  /dev/sda3 Start: 0 End: 2495 Sun Whole Disk

Where sda1 is /boot and sda2 is /.

The system boots until it gets to "Checking filesystems:", then fails with the error:
  fsck.ext3: Device or resource busy while trying to open /dev/sda
  Filesystem mounted or opened exclusively by another program?

/dev/sda is not in /etc/fstab, but there is an autogenerated UUID= label for /boot. If we replace the UUID= reference to /dev/sda1, it stops failing, but we really don't want to do that, as anaconda wants to support that by default.

The bug here seems to be that the code is not looking at partitions before trying whole disks, and it really should do that.
Comment 1 Eric Sandeen 2009-02-12 14:41:50 EST
Ok, this may be a dup of bug #400321, fixed by:

commit 38361bbbb55735cf0f4ed6d56079c70fb3328036
Author: Eric Sandeen <sandeen@sandeen.net>
Date:   Thu Nov 29 12:57:35 2007 -0600

    e2fsprogs: fix blkid whole-disk scanning heuristics

in the 1.40.3 release:

====

e2fsprogs (1.40.3-1) unstable; urgency=medium

  * New upstream release
  * libext2fs: Add checks to prevent integer overflows passed to
      malloc().  Fixes security issue related to Xen's pygrub: CVE-2007-5497
  * libss: Fix parallel build failure
  * e2fsprogs: fix blkid whole-disk scanning heuristics
  ...

====

since sda & sda1 overlap, blkid needs to return the partition not the whole disk when searching by tag.  This should be fixed ....

Could you test 1.40.3 or later & confirm that it fixes things?

Thanks,
-Eric
Comment 2 Eric Sandeen 2009-02-12 15:29:10 EST
Spot said later e2fsprogs still wasn't working... I think it's just that sda is now cached from the old version:

# blkid -l -t UUID=c66679d1-e625-487e-a21e-88db6ee4f449
/dev/sda: LABEL="/boot" UUID="c66679d1-e625-487e-a21e-88db6ee4f449" TYPE="ext3" SEC_TYPE="ext2" 

but

# blkid -c /dev/null -l -t UUID=c66679d1-e625-487e-a21e-88db6ee4f449
/dev/sda1: LABEL="/boot" UUID="c66679d1-e625-487e-a21e-88db6ee4f449" SEC_TYPE="ext2" TYPE="ext3" 

It'd be nice if this cleaned up automagically but since sparc is new (!) for fedora this shouldn't cause problems (no stale blkid caches should be out there).

Can you try removing /etc/blkid/blkid.tab or at least the "sda" line and give it another go?
Comment 3 Eric Sandeen 2009-02-12 15:40:59 EST
heh, oops, spot was testing old e2fsprogs.  latest f9 update already has this solved.  :)  If only my brain had infinite capacity.

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