Hi, im trying to boot iso with grub2 but i cant make it boot.
Fedora-Live-KDE-x86_64-23_Beta-1.iso
Is it possible to to this? Anyone tried?
Hi, im trying to boot iso with grub2 but i cant make it boot.
Fedora-Live-KDE-x86_64-23_Beta-1.iso
Is it possible to to this? Anyone tried?
Yes it is possible, but quite cryptic and cumbersome to do it from GRUB2 prompt for example.
this might work, haven't tested, but I have something like this in /etc/grub.d/40_custom
In GRUB2 prompt:
Code:insmod loopback insmod iso9660 insmod udf # Assumed your iso-image is on the usb stick which is (hd1) for Grub2. It may not be so. loopback loop (hd1,0)/Fedora-Live-KDE-x86_64-23_Beta-1.iso # here you can try to examine what Grub2 has found if it succeeded to loop-mount that iso ls (loop)/<tab> # In case you have UEFI-PC. If BIOS machine, or in BIOS-mode, then linuxefi = linux, and initrdefi = initrd linuxefi (loop)/syslinux/vmlinuz0 root=live:CDLABEL=LIVE rootfstype=auto ro rd.live.image rd.live.check initrdefi (loop)/syslinux/initrd0.img boot
I got it to boot another way but i have a new problem.
I can mount all partitions of the hard drive but the strange thing is
i cant get the installer to detect the hard drive.
What can i do?
I am using a 64 bit UEFI machine. The iso files are at the top level on partition 11.
The UUID of that partition is obtained using blkid.
The following entries in grub.cfg work:
Adjust the inst.lang and inst.keymap kernel parameters for your location.Code:menuentry 'Install Fedora 23 Beta' --class fedora --class gnu-linux --class gnu --class os { insmod loopback set isofile=Fedora-Workstation-netinst-x86_64-23_Beta.iso loopback loop (hd0,gpt11)/$isofile set root=(loop) linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:UUID=********-****-****-****-************:/$isofile inst.lang=en_GB.UTF-8 inst.keymap=uk quiet initrdefi /images/pxeboot/initrd.img } menuentry 'Live Fedora 23 Beta' --class fedora --class gnu-linux --class gnu --class os { insmod loopback set isolabel=Fedora-Live-WS-x86_64-23_B-1 set isofile=Fedora-Live-Workstation-x86_64-23_Beta-1.iso loopback loop (hd0,gpt11)/$isofile set root=(loop) linuxefi /isolinux/vmlinuz0 iso-scan/filename=$isofile root=live:LABEL=$isolabel ro rd.live.image quiet rhgb initrdefi /isolinux/initrd0.img }
You will need to add the loopback module to the ESP so that Grub can find it
I can also confirm that the netinst iso is not finding my 'Local Standard Disk'.Code:# dnf install grub2-efi-modules # mkdir /boot/efi/EFI/fedora/x86_64-efi # cp /usr/lib/grub/x86_64-efi/loopback.mod /boot/efi/EFI/fedora/x86_64-efi
I am currently looking into that. If you find anything, please let us know.
Bug reported:
https://bugzilla.redhat.com/show_bug.cgi?id=1274668
I finally got it to work with this configuration.
It found my hard drive and all worked fine during installation process.Code:menuentry 'Live Fedora 23 Beta' --class fedora --class gnu-linux --class gnu --class os { insmod loopback set isolabel=Fedora-Live-KDE-x86_64-23_B-1 set isofile=Fedora-Live-KDE-x86_64-23_Beta-1.iso loopback loop (hd0,4)/$isofile set root=(loop) linux /isolinux/vmlinuz0 iso-scan/filename=$isofile root=live:LABEL=$isolabel ro rd.live.image quiet rhgb initrd /isolinux/initrd0.img }
But booting from USB media with the same image did not work, no hard drive found in installer.
It might be some bug affecting there also even it was not netinstaller i used.
Thanks for your help
Your USB-media has which filesystem?
Grub may not have the right modules installed without "insmod <module>" .
My bug has just been closed as NOTABUG.on the pretext that the storage hardware the installer is on cannot be used to install to despite the fact that I have done precisely that since Fedora 20.
There is no logical reason for this, what would appear to be, new restriction.
If I understand you correctly, Nordicruler, you have installed successfully with the live iso to the same disk that contained the live iso?.
I have 4 primary partitions on my only hard drive and sda4 contains the live iso.
Fedora 23 beta is now successfully installed on sda3.
Code:/dev/sda1: LABEL="System Reserved" UUID="F85A988B5A9847F0" TYPE="ntfs" PARTUUID="d0e3722e-01" /dev/sda2: LABEL="Main" UUID="6EEC7AE4EC7AA64D" TYPE="ntfs" PARTUUID="d0e3722e-02" /dev/sda3: UUID="9bbff56f-8bba-4be3-b165-c8c3d39c7368" TYPE="ext4" PARTUUID="d0e3722e-03" /dev/sda4: UUID="f3509f2b-477d-44e6-beb7-7828973728c0" TYPE="ext4" PARTUUID="d0e3722e-04"Code:menuentry 'Live Fedora 23 Beta' --class fedora --class gnu-linux --class gnu --class os { insmod loopback set isolabel=Fedora-Live-KDE-x86_64-23_B-1 set isofile=Fedora-Live-KDE-x86_64-23_Beta-1.iso loopback loop (hd0,4)/$isofile set root=(loop) linux /isolinux/vmlinuz0 iso-scan/filename=$isofile root=live:LABEL=$isolabel ro rd.live.image quiet rhgb initrd /isolinux/initrd0.img }
Last edited by Nordicruler; 24th October 2015 at 01:34 AM.
The most difficult thing above would be to guess what is isolabel.
How did you get that information?
There should be some standard or guideline how CD/DVD labels are named in Fedora LIVE-isos. Why couldn't their LABELs be just "LIVE" as I've seen in some live-isos.
Guessing from isofile-name wouldn't be successful. How to know "Beta-1" becomes "B_1"?
Mounting the iso first would ofcourse tell the LABEL and also the path where vmlinuz0 and initrd0.img are. Mounting, I guess, can be done in GRUB-prompt and then see the path, but the CD/DVD label cannot seen in GRUB-prompt I think.
Why grub cannot just use what ever CD/DVD-label it finds? Why it needs both "iso-scan/filename" and "root=live:LABEL" and yet third time to tell we are working on LIVE-image here: "rd.live.image" ? Or actually, it is not GRUB which is so picky and needs those all, but kernel.
Last edited by zimon; 24th October 2015 at 11:09 AM.
Nordicruler: Thanks for that. Perhaps we can get Redhat to see sense eventually.
Zimon: for example:
Code:# losetup /dev/loop0 Fedora-Workstation-netinst-x86_64-22.iso # blkid /dev/loop0 /dev/loop0: UUID="2015-05-21-23-34-18-00" LABEL="Fedora-22-x86_64" TYPE="iso9660" PTUUID="51a721b5" PTTYPE="dos" # losetup -d /dev/loop0
Last edited by kldixon; 24th October 2015 at 11:06 AM.
Those parameters on the line beginning 'linux' ar kernel parameters. Grub does nothing with them. They are handed to the kernel which then hands them to whatever init program is run.in the initrd.
There is still a question, how to tell the CD/DVD-label if all you have is a USB-stick which has Grub2 and the ISO-file on the same USB-stick, and then empty hard disk or SSD.
I've quite often been in such a situation, and always I had ended up installing the live image in some other machine. Of course initially I downloaded the live images to this usb-stick in some other working OS, but would be nice to have several different LIVE isos on a USB-stick and try them all selecting from a GRUB prompt.
Breaking the kernel parameters in pieces and trying to understand all what is passed:
rhgb = redhat graphical boot - This is a GUI mode booting screen with most of the information hidden while the user sees a rotating activity icon spining and brief information as to what the computer is doing. [1]linux /isolinux/vmlinuz0 iso-scan/filename=$isofile root=live:LABEL=$isolabel ro rd.live.image quiet rhgb
quiet = hides the majority of boot messages before rhgb starts. These are supposed to make the common user more comfortable. They get alarmed about seeing the kernel and initializing messages, so they hide them for their comfort. [1]
iso-scan/filename
Using iso-scan/filename with a Fedora/Red Hat/CentOS Live iso should
just work by copying the original kernel cmdline parameters. [2]
(But what does it do and who uses this information?)
root=<path to blockdevice>
specify the block device to use as the root filesystem. [2]
(OK, kernel needs to know where the root-fs is.)
ro
force mounting / and /usr (if it is a separate device) read-only.
If none of ro and rw is present, both are mounted according to
/etc/fstab. [2]
rd.live.image
???
(Tells root-fs is in live media. Kernel needs this information why? It already knows this from "root=" parameter where is "live:")
In dracut's parse-dmsquash-live.sh [3] there is something about this. Quickly checking the shell code [3] seem to me the "rd.live.image" is unnecessary redundant information.
[1] https://www.redhat.com/archives/rhl-.../msg07775.html
[2] http://man7.org/linux/man-pages/man7...cmdline.7.html
[3] https://code.openhub.net/file?fid=pA...lected=true#L0
Yes lets hope so, you are welcome kldixon