Bug 27218 - mkinitrd error, All of your loopback devices are in use!
mkinitrd error, All of your loopback devices are in use!
Product: Red Hat Linux
Classification: Retired
Component: mkinitrd (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Matt Wilson
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-02-12 17:26 EST by kithanas
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-14 17:44:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description kithanas 2001-02-12 17:26:30 EST
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 
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 18:05:16 EST
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 18:53:58 EST
I understand that. How do I go about correcting this? That was my main concern.
Comment 3 Bill Nottingham 2001-02-12 19:33:52 EST
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 13:51:10 EST
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 14:47:44 EST
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


and see if that helps.
Comment 6 Andrew Bartlett 2001-03-10 01:17:22 EST
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 17:44:06 EDT
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 11:39:52 EST
error message added for case where user isnt' logged in as root
Comment 9 Andrew Bartlett 2002-01-11 21:39:31 EST
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.

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