| 2009-12-27 17:00:28 |
gibbylinks |
nominated for series |
|
Ubuntu Lucid |
|
| 2009-12-27 17:00:28 |
gibbylinks |
bug |
|
|
added bug |
| 2009-12-28 00:19:18 |
Kjell L. |
ubuntu: status |
New |
Confirmed |
|
| 2010-02-06 21:04:40 |
Gábor Lipták |
marked as duplicate |
|
492301 |
|
| 2010-05-09 07:06:07 |
gibbylinks |
removed subscriber gibbylinks |
|
|
|
| 2010-05-19 04:47:11 |
Jan Kraeck |
removed subscriber Jan Kraeck |
|
|
|
| 2010-11-09 02:38:16 |
Merritt Boyd |
bug |
|
|
added subscriber Merritt Boyd |
| 2011-03-19 18:38:52 |
Diver |
bug |
|
|
added subscriber Diver |
| 2013-10-25 15:09:13 |
Ryan |
removed duplicate marker |
492301 |
|
|
| 2014-11-12 15:44:30 |
Peter Thoemmes |
bug |
|
|
added subscriber Peter Thoemmes |
| 2015-04-25 02:21:08 |
jdb2 |
bug |
|
|
added subscriber jdb2 |
| 2018-03-11 20:28:37 |
TJ |
bug task added |
|
casper (Ubuntu) |
|
| 2018-03-11 20:28:46 |
TJ |
casper (Ubuntu): status |
New |
Triaged |
|
| 2018-03-11 20:28:50 |
TJ |
casper (Ubuntu): importance |
Undecided |
Low |
|
| 2018-03-11 21:08:20 |
TJ |
description |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
affects ubuntu/lucid lynx
Seeing following error message when booting Lucid Lynx daily builds
from USB stick.
/init: line 7: can't open /dev/sr0: No medium found
Boots ok
using DELL Inspiron 1501 laptop with 2gb Ram
I get same error if image written to disk with
* USB Startup Disk Creator
* Create DELL recovery media
* Unetbootin
all three packages return same error so looks like ISO at fault ?
see http://ubuntuforums.org/showthread.php?t=1345125
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAks3kkYACgkQRT+RNEgk9JhxQACfT9zIpm/O8NPk/gNVKoy+JftF
574An1lZaOutT1kVQFbqjF98bgJMIcfv
=cOYl
-----END PGP SIGNATURE----- |
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 causes 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. |
|
| 2018-03-11 21:27:11 |
TJ |
bug |
|
|
added subscriber TJ |
| 2018-03-12 11:04:31 |
TJ |
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 causes 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. |
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. |
|
