Bug 27218

Summary:	mkinitrd error, All of your loopback devices are in use!
Product:	[Retired] Red Hat Linux	Reporter:	kithanas
Component:	mkinitrd	Assignee:	Matt Wilson <msw>
Status:	CLOSED RAWHIDE	QA Contact:	David Lawrence <dkl>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.0	CC:	abartlet
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-08-14 21:44:10 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:

Description kithanas 2001-02-12 22:26:30 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (Win98; U)


I used the Redhat Network to download the new kernel rpms (2.2.17-14smp) and installed them. I then rebooted and discovered that it was still 
using the old kernel 2.2.16-22smp. The ethernet and sound modules did not load properly either. I was surprised to find out that the lilo.conf 
wasn't appended with the new kernel information and that the initrd.img files were not created either. After realizing this I attempted to create 
the initrd files and encountered the following error from mkinitrd: "All of your loopback devices are in use!" I can't seem to get mkinitrd to work 
at 
all now.

System configuration:

Celeron 500 x2, on Abit BP6 motherboard, 128MB RAM, Adaptec 2940U2W SCSI controller, IBM SCSI 9GB hard drive.


Reproducible: Always
Steps to Reproduce:
1. Use Redhat Update Agent to download and install kernel-2.2.17-14 ( and associated files)
2. Reboot machine after installation completes.
3. attempt to run "mkinitrd -v 2.2.17-14smp.img 2.2.17-14smp" to create the appropriate .img files
	

Actual Results:  mkinitrd fails with the following error: All of your loopback devices are in use!


Expected Results:  2.2.17-14smp.img is created

Comment 1 Bill Nottingham 2001-02-12 23:05:16 UTC

It upgraded your kernel, so 2.2.16-22 isn't there anymore. Since it isn't
there is no loop module to insert, so you can't make an initrd.

Comment 2 kithanas 2001-02-12 23:53:58 UTC

I understand that. How do I go about correcting this? That was my main concern.

Comment 3 Bill Nottingham 2001-02-13 00:33:52 UTC

If you have an install CD, you can boot off of that in 'rescue' mode, and
then make an initrd.

Comment 4 kithanas 2001-02-13 18:51:10 UTC

I attempted to create initrd after booting into rescue mode from CD and mounting /boot. However, mkinitrd does not appear to exist in /sbin folder used by 
rescue mode. I attempted to mount the system's root drive under /system. I then attempted to use /system/sbin/mkinitrd but received the error: "No such 
file or directory" How am I supposed to create the initrd in this situation?

Comment 5 David Lawrence 2001-03-06 19:47:44 UTC

It may be complaining that it doesnt know where your /etc/fstab is. It uses
/etc/fstab as the default if one is not given. Try adding the extra argument

--fstab=/system/etc/fstab

and see if that helps.

Comment 6 Andrew Bartlett 2001-03-10 06:17:22 UTC

I am wondering, could the kernel RPM be told to 'modprobe loop' just before it
gets upgraded?  As in the unfortunate case where the sys-admin forgets the
special case of -i for kernel upgrades, this would at least allow the generation
of initrds.  Perhaps this could also be automated.  

I understand the reluctance to take the next logical step and actualy install
the kernel in lilo, but at least getting the sysadmin that far would make things
*very* convenient.

Comment 7 lethalwp 2001-08-14 21:44:06 UTC

I've just had the same problem, i had it because i wasn't root on the file
system, and only root is able to handle that. (of course, you need to have
support for loop devices)

That errormsg is a little confusing, that's all

Comment 8 Erik Troan 2002-01-11 16:39:52 UTC

error message added for case where user isnt' logged in as root

Comment 9 Andrew Bartlett 2002-01-12 02:39:31 UTC

Another similar case is where you (not RH default, but a scheme I like) mount
/tmp as tmpfs.  Becouse you can't do loopback on tmpfs (I assume becouse loop
requires block backing) it all fails rather miserably.  

A better error message could be useful - but this one might be a little harder
to detect.