Jump to content











Photo
- - - - -

/dev/sr0: No medium found when trying to boot from a linux ISO

isolinux windows10 bcd

  • Please log in to reply
10 replies to this topic

#1 someoneinthedark

someoneinthedark

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 4 weeks ago

I tried booting from a Pop!OS ISO from the Windows 10 BCD, but it fails and shows "init: line 3: can't open /dev/sr0: No medium found"

 

I've made the ISO to run from the RAM and the file exists on an NTFS partition. The ISO uses ISOLINUX and to check that i ran "file -s /path/to/ISO" which showed 

pop-os_19.04_amd64_nvidia_4.iso: ISO 9660 CD-ROM filesystem data 'Pop_OS 19.04 amd64' (bootable)

so i thought it wasn't intended to be run from USB; so i added isohybrid feature using the latest syslinux-utils and again ran "file -s /path/to/ISO" and it showed 

pop-os_19.04_amd64_nvidia_4.iso: ISO 9660 CD-ROM filesystem data (DOS/MBR boot sector) 'Pop_OS 19.04 amd64' (bootable)

but the same error persists

 

I've even tried booting the ISO on an AIO-boot USB through Grub2 but the same error persists...

 

I've also made changes to ISOLINUX.CFG to disable loading floppy (as suggested somewhere) but no change



#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15921 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 4 weeks ago

To boot a Linux from ISO (generally speaking) there are three possibilities:
1) the Linux distro has already built-in settings that allow it <- this would be too d@mn easy so each and every other Linux distro either doesn't have this provision or has the approach #2 below, and the developers make sure that the cheat codes are in public display in a locked file cabinet in a disused lavatory with the sign beware of the leopard on the door
2) the Linux distro has kernel parameters (so called cheat codes) that allow it to boot from ISO with - say - grub4dos or using the loopback device with GRUB2 or syslinux <- this is the most common situation, issue is that the specific needed cheat codes are often difficult to find
3) none of the above <- in this case there is a workaround, but it involves writing an entry to the partition table of the disk where the .iso is saved , usually using grub4dos, the so called "fake partition" method

The kernel parameter is usually something like fromiso=

Pop!OS should be an Ubuntu derivative, Ubuntu uses - I believe - iso-scan/filename=

BUT Pop!OS specifically seemingly has not this feature:
https://github.com/p.../iso/issues/243

So you either modify the initrd.gz or you can try #3 above (which normally works but might or might not work specifically with it).
Basically it consists in writing to the MBR partition table a partition table entry with id 00 (like if it was empty) and covering the extents of the .iso on the disk volume, this can be done manually or - say - grub4dos has a provision to write this entry (command partnew).

Some details are here:
http://reboot.pro/in...ic=9916&p=88531

You could try Easy2Boot that can use this approach making it almost automatic.

:duff:
Wonko


  • someoneinthedark likes this

#3 someoneinthedark

someoneinthedark

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 4 weeks ago

Thank you for the prompt reply, and sorry for the delay got busy with few things

 

should the loopback.cfg be present inside the ISO? or the external loopback.cfg from AIO-boot is used?

 

i'll try adding the kernel key parameters found in scripts/casper-premount/20iso_scan and test later



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15921 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 4 weeks ago

It would go into the .iso, but the loopback cfg by itself does nothing, it is just a handy way to automate "external" GRUB2 grub.cfg entries.

 

The general idea is that the initrd.gz is decompressed at boot time and becomes the "initial ramdisk", its contents take command (namely the "casper" subsystem) them what is missing is *something* that tells "casper" to look for the .iso, this *something* is NOT loopback.cfg.

 

The loopback.cfg is just a "normal" GRUB2 configuration file, see:

https://www.supergru...ki/Loopback.cfg

 

What is missing here is - besides and before the loopback.cfg, which is optional and limited to GRUB2 booting - are the "casper"  scripts that allow for passing the .iso path to the kernel and thus allow it to load the rest of the system and boot.

 

If you prefer the loopback.cfg is a "commodity" that may exist "on top" of the casper scripts (but that is only useful if you use directly or indirectly GRUB2 to boot the .iso).

 

:duff:

Wonko



#5 someoneinthedark

someoneinthedark

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 3 weeks ago

I've copied 20iso_scan from casper-premount & lupin-helpers and placed in filesystem.squashfs, also loopback.cfg into GRUB directory

 

Here's my ISOLINUX.CFG:

default pop-os


label pop-os
    kernel /casper/vmlinuz.efi
    append initrd=/casper/initrd.gz boot=casper iso-scan/filename=/pop-os_19.04_amd64_nvidia_4.iso hostname=pop-os username=pop-os noprompt floppy.allowed_drive_mask=0 ignore_uuid ---

and GRUB.CFG:

menuentry "Pop!OS ISO" --hotkey=${hotkey} {
set isofile="/AIO/grub/pop-os_19.04_amd64_nvidia_4.iso"
loopback loop (hd1,1)$isofile
echo "Starting $isofile..."
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=${isofile} 
initrd (loop)/casper/initrd.gz}

Still the same issue persists when i boot from both GRUB2 or Windows BCD...i didn't see what changes I've to make to initrd.gz (because casper-premount is present inside filesystem.squashfs)

I'm not sure what i'm doing wrong..pardon me and correct me


Edited by someoneinthedark, 3 weeks ago.


#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15921 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 weeks ago

I would gladly help you if I actually knew how/what is "wrong" in your setup :unsure:, there could be several things gone wrong in the editing of the initrd.gz or in re-creating the .iso.

 

At first sight the isolinux configuration and the grub one are attempting to do two different things.

 

First one seems like being the "inside the .iso" menu, second one seems external to it.

 

The GRUB one cannot possibly work as there are brackets around isofile :dubbio:

${isofile} 

 

You define the isofile variable using double quotes (WHY?)

set isofile="/AIO/grub/pop-os_19.04_amd64_nvidia_4.iso"

, then you map its value prepended by (hd1,1), which should be where the .iso resides, to the loop device:

loopback loop (hd1,1)$isofile 

BUT the expanded variable should include the quotes, so it would become

loopback loop (hd1,1)"/AIO/grub/pop-os_19.04_amd64_nvidia_4.iso"

which I don't think it can work

THEN you pass as kernel parameter ${isofile} (WHY?)

linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=${isofile}

 

I mean, I would try first:

 

menuentry "Pop!OS ISO"  {
set isofile=/AIO/grub/pop-os_19.04_amd64_nvidia_4.iso

search --set=root --file $isofile
loopback loop $isofile
echo "Starting $isofile..."
linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile
initrd (loop)/casper/initrd.gz

}

 

But no idea if it will work.

 

:duff:

Wonko



#7 someoneinthedark

someoneinthedark

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 3 weeks ago

Ok but what about initrd.gz, what changes do i make to it? the casper-premount exists in squashfs, i'm not sure what exactly has to be modified in the initrd.gz

Also for the user who made it work also used live-media-path parameter too

#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15921 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 weeks ago

Mind you I am way off  my "comfort zone", but what do you mean  by squashfs? It should be inside the initrd.gz AFAICR/AFAIK, i.e. the initrd.gz is the squashfs.

 

casper-premount is a directory that should contain several scripts.

 

One of these should be20iso_scan that should be containing the relevant setting.

 

The post that is seemingly understandable on the mentioned thread and that should be replicated (including - for initial tests - direct booting as opposed to loopback booting) is this one:

https://github.com/p...mment-686336063

 

but of course it is related to older versions of both Ubuntu and PopOS, so it may have become inaccurate.

 

To sum up there are 4 main things that can go bad:

1) editing/expanding/recreating the initrd.gz

2) adding to it the relevant (whatever they are) scripts

3) editing/recreating the .iso

4) adding a working GRUB2 menu entry

 

You had #4 seemingly wrong, you can by-pass #3 replicating (again for tests only) the direct booting like space88man  detailed, buit for #1 and #2 I cannot add anything, maybe you can ask on some PopOS - related forum?

 

Like here:

https://pop-planet.info/forums/

 

:duff:

Wonko



#9 someoneinthedark

someoneinthedark

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 3 weeks ago

Mind you I am way off  my "comfort zone", but what do you mean  by squashfs? It should be inside the initrd.gz AFAICR/AFAIK, i.e. the initrd.gz is the squashfs.

 

Yes, you're right, I'm sorry i'd a misconception here; I'm on Windows and using WSL for linux related tasks

 

When i pulled out the initrd.gz from ISO and opened it using 7-zip, it listed only two directories which were "kernel" & "." as shown below

 

https://wtf.roflcopt...GLuP/zz07VPgb?t

 

So after i'd posted you yesterday, i had a doubt and wanted to verify this, so i tried extracting the GZip with WinRAR, the resultant file was a 200MB file named "INITRD" containing all you'd said 

 

I checked what type of archive it was:

INITRD: ASCII cpio archive (SVR4 with no CRC)

7-zip can open it & extract it (so assuming it can do it properly and i can skip using the skipcpio utility from dracut to extract it)

 

(Just for info: skipcpio is used to “skip past” the CPIO-compressed CPU microcode to access the boot image.)

 

but i'm finding it hard to recompress everything back using cpio right now... 


Edited by someoneinthedark, 3 weeks ago.


#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15921 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 3 weeks ago

Yep, cpio (+gz) is already tricky by itself, but dealing with CPIO with microcode is even worse.

 

Personally I wouldn't trust *any*  Windows tool to deal with those files (they may work, but likely they won't,. or - worse - won't work "fully").

 

AFAIK/AFAICT you need a "real" Linux (you can use a VM just fine), and you need to run the native Linux tools (command line only) and extract on a Linux filesystem (such as Ext2/3/4) to be sure that permissions and other file metadata are preserved, and - moreover - you need to check the specific distro way to create the initrd.gz, as each one may have some particular settings in the compression.

 

:duff:

Wonko



#11 someoneinthedark

someoneinthedark

    Newbie

  • Members
  • 12 posts
  •  
    United States

Posted 3 weeks ago

Yep, cpio (+gz) is already tricky by itself, but dealing with CPIO with microcode is even worse.

 

Personally I wouldn't trust *any*  Windows tool to deal with those files (they may work, but likely they won't,. or - worse - won't work "fully").

 

AFAIK/AFAICT you need a "real" Linux (you can use a VM just fine), and you need to run the native Linux tools (command line only) and extract on a Linux filesystem (such as Ext2/3/4) to be sure that permissions and other file metadata are preserved, and - moreover - you need to check the specific distro way to create the initrd.gz, as each one may have some particular settings in the compression.

 

:duff:

Wonko

 

The extraction is easy but re-compressing needs following some sequence of steps.

 

It is quite surprising that on the NTFS (Windows) i'm able to extract almost all the files but on EXT2/3 or MSDOS it omits some of the files when extracting...







Also tagged with one or more of these keywords: isolinux, windows10, bcd

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users