/init: line 7: can't open /dev/sr0: No medium found

Bug #500822 reported by gibbylinks
144
This bug affects 31 people
Affects Status Importance Assigned to Milestone
Ubuntu
Confirmed
Undecided
Unassigned
Nominated for Lucid by gibbylinks
casper (Ubuntu)
Triaged
Low
Unassigned
Nominated for Lucid by gibbylinks

Bug Description

Seeing following error message when booting from live installer.

/init: line 7: can't open /dev/sr0: No medium found

== Explanation ==

This continues to affect desktop installers for 17.10 and 18.04.

There are a variety of underlying causes and the message seen isn't related to the cause, which creates immense confusion.

As soon as the kernel has booted it executes the /init script in the /casper/initrd.lz initial ramdisk.

One of the first things the /scripts/casper functions do is find the installer device in order to mount it's file-system. As part of that they scan various block devices looking for it, in a repeating loop. Each time through the loop existing devices get re-scanned. One device that is scanned is the CD/DVD drive, usually /dev/sr0.

When booting from USB any CD/DVD drive usually has no disc inserted and therefore we see repeated

/init: line 7: can't open /dev/sr0: No medium found

each time the loop runs.

There are many reasons why the installer file-system isn't found but here is a way to narrow down the cause:

1. The above message repeats rapidly many times in succession until the screen is filled with the same line and eventually it drops to the Busybox initramfs shell prompt.

  This means the USB mass storage device wasn't detected, or the usb_storage kernel module wasn't loaded by the kernel. This could be because the udev rules didn't match the device and therefore didn't create the device node (e.g. /dev/sdb)

2. The above message only appears once, or only repeats after long delays, and it takes many minutes to drop to the Busybox initramfs shell prompt.

  This indicates the udev daemon is hung whilst processing device detection rules, possibly due to it executing an external command which has hung. There are some calls to 'udevadm trigger' which has a default delay of 120 seconds if the kernel event queue isn't drained - which it may not be if some process/task has hung.

3. The device doesn't present on a device node or path the casper scripts look for.

  Setting the kernel command-line option live-media= (e.g: live-media=/dev/mmcblk0) which can be supported with live-media-path= (e.g: live-media-path=/casper) which is a directory where the live file system is, (e.g: by default /casper/filesystem.squashfs)

There may be other indirect causes of these headline symptoms.

I've just dealt with one where the UEFI boot failed in this way from a USB flash mass storage device. After hours helping the user diagnose it, the solution was to move the USB device from the rear USB port of the motherboard to a front port!

Some years ago I had a similar issue on Dell Poweredge servers where the CD-ROM device with the installer on was a true SCSI device on a SCSI controller, and the installer was not shipped with or loading the correct kernel module for that SCSI controller.

Systems with a Floppy disk controller but no floppy disk attached can also cause long timeouts as the FDC ports are probed and a long timeout expires before the OS decides there is no FDD attached.

Revision history for this message
Kjell L. (lkjell) wrote :

It happens with Karmic as well on an USB. But only on a selective pc. However if you wait like 5 min or more it should boot fine.

Changed in ubuntu:
status: New → Confirmed
Revision history for this message
Mikko Ohtamaa (mikko-red-innovation) wrote :

I had the same error with some desktop Acer computer.

I believe it might not be computer related, but some problem with usb-creator which fails to set-up the image correctly.

(I used Windows usb-creator)

Revision history for this message
Mikko Ohtamaa (mikko-red-innovation) wrote :

Also, I was using Karmic Koala 32-bit desktop ISO, not Lucid.

Revision history for this message
Mikko Ohtamaa (mikko-red-innovation) wrote :

I burned the same ISO to CD and the booting was different from the beginning... the installer menu had different options etc. And it works.

Revision history for this message
Chris S. (cszikszoy) wrote :

Disabling the floppy drive controller in the BIOS (as I have no floppy drive) fixed this issue for me.

Revision history for this message
Julien (julienmbpe) wrote :

Same bug for me on an persistant-USB drive created with usb-creator from an iso of Ubuntu Lucid Lynx 64bits (beta1)

/init: line 7: can't open /dev/sr0: No medium found
/init: line 7: can't open /dev/sr0: No medium found
stdin : error
/init: line 7: can't open /dev/sr0: No medium found
/init: line 7: can't open /dev/sr0: No medium found
stdin : error
/init: line 7: can't open /dev/sr0: No medium found
/init: line 7: can't open /dev/sr0: No medium found
stdin : error

Revision history for this message
Jan Kraeck (jan-kraeck) wrote :

built (k)ubuntu 10.04 live-usb with "usb startup disk creator (ubuntu 9.10)" and have same problem:

first:
(process: xxx): Glib-Warning ** getpwuid_r(): failed due to unknown user id(0)

then a lots of:
stdin: error0
/init: line 7: can't open /dev/sr0: No medium found

after a while:
opens ash and writes:
(initramfs)Unable to find a medium containing a live file system

Revision history for this message
antesdelalba (antesdelalba) wrote :

Same thing here on an IBM R51.

I used the same pendrive to install 10.04 on another two boxes, so it's not the key.

Revision history for this message
Nguyen Anh Minh (minhna) wrote :

I had this problem.
Desktop mainboard: ECS 780GM-A
CPU: AMD athlon II X2 240

Revision history for this message
Jorge Liechocki (jliechocki) wrote :

as well as Jan Kraeck #7:

built (k)ubuntu 10.04 live-usb with "usb startup disk creator (ubuntu 9.10)" and have same problem:

first:
(process: xxx): Glib-Warning ** getpwuid_r(): failed due to unknown user id(0)

then a lots of:
stdin: error0
/init: line 7: can't open /dev/sr0: No medium found

Revision history for this message
Ulisses de C. Soares (ulisses-soares) wrote :

Disabling floppy drive, as said by Chris S., USB boot ran well.

Revision history for this message
John Hollar (john-p-hollar) wrote :

Likewise, disabling the floppy drive worked. I think its because this error is followed by a stream of

end_request: I/O error, device fd0, sector 0
Buffer I/O error on device fd0, logical block 0

over and over, which would explain the connection to the floppy. I also have no floppy drive.

Revision history for this message
Merritt Boyd (mboyd) wrote :

This is in fact a bug in casper, and not a dupe of #492301. The error message we're seeing is an annoying by-product of casper searching for its filesystem image across all removable media, some of which (the floppy drive in particular) may cause an error to be printed when queried. Whether or not you see it depends on the order casper queries the various system media, as it stops as soon as it finds the one it wants.

This bug alone shouldn't prevent the system from booting, but if casper is unable to find an image, it will keep looking in a loop, causing the error to be printed repeatedly. People seeing repetitions of this message and then dropping into an initrd shell have bigger problems, unrelated to the reasons for seeing this message on successful boots.

As has already been pointed out, disabling the floppy drive will suppress the message. A better fix would be for the casper devs to change line 44 of /scripts/casper-helpers from "eval $(fstype < $1)" to "eval $(fstype $1 2>/dev/null)".

Revision history for this message
Diver (diver) wrote :

Unfortunately my bios doesn't have an option to disable floppy drive (and I don't have one at all). I also found several other reports about this problem from people with notebooks without this option too. Shouldn't this bug be reopened and fixed in casper?

Revision history for this message
Narcis Garcia (narcisgarcia) wrote :

I'm affected with Ubuntu-Gnome 13.04 Live-USB created with usb-creator from a Ubuntu 12.04 machine.
In my case it has no relation with bug 492301 because I've also tried to boot with a multiboot USB stick (grub2 to select an ISO file in the stick; no usb-creator intervention) and the init message is the same:

/init: line 7: can't open /dev/sr0: No medium found

Can it be related with UEFI installed on the hard disk?
(my today's testing case is a notebook with Windows 7 preinstalled; BIOS hasn't any option to disable UEFI)

Ubuntu 13.04 Live-USB: error
Ubuntu 13.04 ISO in a grub-USB: error
Ubuntu 13.04 Live-DVD: boots (only acpi=off needed)
* Ubuntu 13.04 Live-USB boots if there is also the Live-DVD inserted in the optical drive (after kernel loading Live-USB jumps to get all the data from DVD; sr0).

- I've tried with Nguyen's workaround (altering casper parameters) with no success.
- Once the hard disk is formatted, problem remains.
- This is the second machine I've found in a month with the same problem (preinstalled Windows 7/8 that prevents Live-USB to boot).

Revision history for this message
gerdkolano (gerdkolano) wrote :

I've got the same problem booting 13.04 from USB , disabled both floppy and floppy controller in the BIOS.

Revision history for this message
ice (ice-simx) wrote :

[ SOLVED ]

facing same problem, ( HP Compaq 6910p )
used ubuntu-12.04-desktop-amd64 to create startup disk of ubuntu-12.04.3-desktop-amd64
but no luck so far.

as mentioned, disabled boot from floppy (as there was no option to disable floppy controller)
but nothing happened

then i tried to enable SATA Native Mode in BIOS, reboot and wait for about five minutes,
it print error message
                          timeout: killing '/sbin/modprobe -bv pci:-------- ' [197]
repeatedly, then show ubuntu logo and booted fine.

Revision history for this message
Ian! D. Allen (idallen) wrote :

Failure booting from USB using ubuntu-12.04.3-desktop-i386.iso on a Dell Inspiron 9300:
- Repeated "/init: line 7: can't open /dev/sr0: No medium found" over and over
- Error: Unable to find a medium containing a live file system
- Drops into shell prompt: (initramfs)

The USB was made with a direct "dd" onto the USB key: dd if=ubuntu-12.04.3-desktop-i386.iso of=/dev/sdb
(Same errors happened with a USB key loaded using some other Windows USB creator utility.)

Solution:
- Use F6 to interrupt the boot.
- Optional: remove the keywords "quiet splash" from the kernel line.
- Add the keywords "break debug" to the kernel line and continue the boot.
- Part way into the boot, it will drop to the "(initramfs)" prompt.
- Doing "ls -l /dev/sd*" will show only sda devices - no sdb devices.
- Wait a few minutes. Various messages will print. Keep waiting.
- After a few minutes, doing "ls -l /dev/sd*" will show the USB key (sdb* devices).
- Now, exit the shell and continue the boot.
- It comes up fine.

Seems to be a timing issue with getting the USB /dev/sdb* devices recognized right after boot. Adding the break and debug (probably only one of these is actually needed but I don't know which) slows down the process and waits long enough so that the USB device can be found by the kernel correctly.

Revision history for this message
ALi (ali-goli-1234567890-g) wrote :

Simple fix on grub4dos:

title Ubuntu 15.04

find --set-root /path-to-casper/casper/initrd.lz

kernel /path-to-casper/casper/vmlinuz --ignore-floppies cdrom-detect/try-usb=true live-media-path=/path-to-casper/casper/ ignore_uuid boot=casper -- lang=us

initrd /path-to-casper/casper/initrd.lz

quiet

boot

Revision history for this message
RajaSekharReddy Genupula (genupulas) wrote :

[New and Quick solution ]

Hello Ian ,

I have tried as you up to adding break and debugging to booting parameters. Then I have tried ls /dev/sd* and same its not showing sdb. I have waited for sometime
But its still not happening.

So just my curiosity forced me to remove USB even system running on initramfs mode and I reinserted USB again and it shown up right away.

Then I type exit and its starting booting.

Than you Ian and I hope this will help others to solve their issue quickly.

Regards
Raja

Revision history for this message
Sean Leavey (seanleavey) wrote :

Hi all,

I've got a fix for the iMac 2009 I tried to install Ubuntu on. I had the same problem and the boot config fix didn't work. The instructions from Ian Allen (comment 19) did not work initially - I got to the initramfs prompt and waited for the usb device to show up with the ls -l /dev/sd* command. Unplugging the USB and reinserting didn't work either, but I did see the message "rejected 1 configuration due to insufficient available bus power" when I pugged it in. It turns out there was not enough power to run the USB drive on the iMac keyboard I had it plugged into. Plugging the USB drive into the back, the device registered as a /dev/sdb device and I was able to run the Ubuntu installer.

Revision history for this message
Sean Leavey (seanleavey) wrote :

In fact, the installer works without the grub configuration hack if I just use a USB port with enough power! Just selecting the boot device from the rEFInd menu worked with the other USB port.

TJ (tj)
Changed in casper (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Revision history for this message
TJ (tj) wrote :

This continues to affect desktop installers for 17.10 and 18.04.

There are a variety of underlying causes and the symptom seem isn't related to the cause, which causes immense confusion.

As soon as the kernel has booted it executes the /init script in the /casper/initrd.lz

One of the first things the /scripts/casper functions do is find the installer device in order to mount it's file-system. As part of that they scan various block devices looking for it, in a repeating loop. Each time through the loop existing devices get re-scanned. One device that is scanned is the CD/DVD drive, usually /dev/sr0.

When booting from USB any CD/DVD drive usually has no disc inserted and therefore we see repeated

/init: line 7: can't open /dev/sr0: No medium found

each time the loop runs.

There are many reasons why the installer file-system isn't found but here is a way to narrow down the cause:

1. The above message repeats rapidly many times in succession until the screen is filled with the same line and eventually it drops to the Busybox initramfs shell prompt.

  This means the USB mass storage device wasn't detected, or the usb_storage kernel module wasn't
  loaded by the kernel. This could be because the udev rules didn't match the device and therefore
  didn't create the device node (e.g. /dev/sdb)

2. The above message only appears once, or only repeats after long delays, and it takes many minutes to drop to the Busybox initramfs shell prompt.

  This indicates the udev daemon is hung whilst processing device detection rules, possibly due to
  it executing an external command which has hung. There are some calls to 'udevadm trigger' which
  has a default delay of 120 seconds if the kernel event queue isn't drained - which it may not be
  if some process/task has hung.

3. The device doesn't present on a device node or path the casper scripts look for.

  Setting the kernel command-line option live-media= (e.g: live-media=/dev/mmcblk0) which can be
  supported with live-media-path= (e.g: live-media-path=/casper) which is a directory where the live
  file system is, (e.g: by default /casper/filesystem.squashfs)

There may be other indirect causes of these headline symptoms.

I've just dealt with one where the UEFI boot failed in this way from a USB flash mass storage. After hours helping the user diagnose it, the solution was to move the USB device from the rear USB port of the motherboard to a front port!

Some years ago I had a similar issue on Dell Poweredge servers where the CD-ROM device with the installer on was a true SCSI device on a SCSI controller, and the installer was not shipped with or loading the correct kernel module for that SCSI controller.

Systems with a Floppy disk controller but no floppy disk attached can also cause long timeouts as the FDC ports are probed and a long timeout expires before the OS decides there is no FDD attached.

TJ (tj)
description: updated
TJ (tj)
description: updated
Revision history for this message
MUHAMMAD FAHAD (m-fahadirshad) wrote :

This bug is due to usb burning tool, I had the same issue with Ultraiso but with the latest version of Rufus; I didn't face it again.

Thank you

Revision history for this message
Bougron (francis-bougron) wrote :

Hello

One possible cause may be forgetting duplication of the directory .disk

Revision history for this message
Shea Rodgers (shea-rodgers) wrote :

Ubuntu 18.10 install from USB on a Dell Optiplex 7040 Micro. I was getting the same error (mostly), but here's what fixed it for me...

I had a USB flash drive with the installation on it (followed directions from https://tutorials.ubuntu.com/tutorial/tutorial-create-a-usb-stick-on-windows#0). This flash drive and a USB keyboard were plugged into the front USB ports. Would try both "Install Ubuntu" and "Try before installing" and would get the message: (initramfs) unable to find a live medium containing a live file system.

From the GRUB menu, I edited the parameters for the installation, removing the "quiet splash ---" from the line to install, then booted to that option. Got the repeated message "/init: line 7: can't open /dev/sdb: No medium found" repeatedly.

After fumbling around a bit, I guessed that it was some weird APCI setting that I couldn't change, so on a whim, while it was repeating that 'No medium found message', I swapped the ports that the flash drive and keyboard were plugged into, and it started booting up...

[MAY BE TOTALLY WRONG]: I think that somewhere along the way, the power to the port where the flash drive is plugged in has its power turned off or something. Port for the KB is on. Maybe the action of plugging the flash drive into that specific port fixed it, or maybe the action of plugging it back in to any port caused it to re-mount, I'm not sure. Just wanted to share what did it for me...

TL;DR - When the installation starts firing that "/init: line 7: can't open /dev/sr0: No medium found" repeatedly, swap the flash drive and keyboard USB ports.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.