Bug 437009

Summary:	Anaconda fails to properly create/destroy loop devices
Product:	[Fedora] Fedora	Reporter:	Will Woods <wwoods>
Component:	anaconda	Assignee:	Anaconda Maintenance Team <anaconda-maint-list>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-03-17 21:50:23 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:	430962

Description Will Woods 2008-03-11 16:49:28 UTC

(this started with bug 436855)

If loader fails to pull down .discinfo, it tries to unmount the stage2.img that
it found previously. When it attempts this, the following happens: 

INFO  : umounting loopback /mnt/runtime /dev/loop0
ERROR : LOOP_CLR_FD failed for /mnt/runtime /dev/loop0 (Device or resource busy)

So loop0 stays active. When you get the right URL, it will pull down stage2 and
try to mount it again, but since loop0 is active, it fails to mount with an
error about LOOP_SET_FD. And then you're stuck.

Since we have the normal mount binary, maybe we should let mount -o loop handle
creating/destroying loop devices?

Comment 1 Chris Lumens 2008-03-14 16:02:42 UTC

Okay, we're using mount -o loop=/dev/loopX now so this should be taken care of.
 You're still bound to see some similar looking error messages on hdiso installs
but that's only because it's attempting to mount images/stage2.img which is not
guaranteed to exist on every ISO image in a set.  In other words, they should be
harmless errors now.

Comment 2 Will Woods 2008-03-17 21:50:23 UTC

Everything seems to work as expected now.