Threaded Mode | Linear Mode

allenb · 2015-09-16, 17:47

Hi All,

I'm trying to boot CentOS 7 using the images in the images/pxeboot directory. The hardware is HP DL380 G9 in native (UEFI) mode. The kernel boots but always panics as follows:

[ 4.138406] List of all partitions:
[ 4.155273] No filesystem could mount root, tried:
[ 4.178291] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[ 4.218363] CPU: 6 PID: 1 Comm: swapper/0 Not tainted 3.10.0-229.14.1.el7.x86_64 #1
[ 4.238617] usb 3-1: New USB device found, idVendor=03f0, idProduct=7029
[ 4.238620] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 4.238622] usb 3-1: Product: Virtual Keyboard
[ 4.238623] usb 3-1: Manufacturer: BMC
[ 4.245099] input: BMC Virtual Keyboard as /devices/pci0000:00/0000:00:1c.2/0000:01:00.4/usb3/3-1/3-1:1.0/input/input1
[ 4.245234] hid-generic 0003:03F0:7029.0001: input,hidraw0: USB HID v1.01 Keyboard [BMC Virtual Keyboard ] on usb-0000:01:00.4-1/input0
[ 4.248961] input: BMC Virtual Keyboard as /devices/pci0000:00/0000:00:1c.2/0000:01:00.4/usb3/3-1/3-1:1.1/input/input2
[ 4.249135] hid-generic 0003:03F0:7029.0002: input,hidraw1: USB HID v1.01 Mouse [BMC Virtual Keyboard ] on usb-0000:01:00.4-1/input1
[ 4.402238] usb 4-3: new high-speed USB device number 2 using xhci_hcd
[ 4.566421] usb 4-3: New USB device found, idVendor=0424, idProduct=2660
[ 4.566423] usb 4-3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 4.566691] hub 4-3:1.0: USB hub found
[ 4.566715] hub 4-3:1.0: 2 ports detected
[ 4.723865] Hardware name: HP ProLiant DL380 Gen9, BIOS P89 05/06/2015
[ 4.755295] ffffffff81813288 0000000087d94de8 ffff881fd320bd60 ffffffff81604516
[ 4.790669] ffff881fd320bde0 ffffffff815fddba ffffffff00000010 ffff881fd320bdf0
[ 4.826215] ffff881fd320bd90 0000000087d94de8 0000000087d94de8 ffff881fd320be00
[ 4.862665] Call Trace:
[ 4.874754] [<ffffffff81604516>] dump_stack+0x19/0x1b
[ 4.900648] [<ffffffff815fddba>] panic+0xd8/0x1e7
[ 4.923954] [<ffffffff81a455fa>] mount_block_root+0x2a1/0x2b0
[ 4.952414] [<ffffffff81a4565c>] mount_root+0x53/0x56
[ 4.976825] [<ffffffff81a4579b>] prepare_namespace+0x13c/0x174
[ 5.005060] [<ffffffff81a45268>] kernel_init_freeable+0x1f0/0x217
[ 5.036263] [<ffffffff81a449db>] ? initcall_blacklist+0xb0/0xb0
[ 5.064963] [<ffffffff815f2ad0>] ? rest_init+0x80/0x80
[ 5.089948] [<ffffffff815f2ade>] kernel_init+0xe/0xf0
[ 5.114528] [<ffffffff816142d8>] ret_from_fork+0x58/0x90
[ 5.141171] [<ffffffff815f2ad0>] ? rest_init+0x80/0x80

This seems identical to the bug described here https://bugs.centos.org/print_bug_page.php?bug_id=8295 but switching to one of the fixed kernels makes no difference.

Has anyone seen this? For reference, here's the relevant bit of my iPXE config:

kernel http://blah.blah/allen/vmlinuz ro initrd=initrd.img console=ttyS1,115200n8
initrd http://blah.blah/allen/initrd.img

Thanks,
Allen

***mcb30*** · 2015-09-16, 19:35

(2015-09-16 17:47)allenb Wrote: This seems identical to the bug described here https://bugs.centos.org/print_bug_page.php?bug_id=8295 but switching to one of the fixed kernels makes no difference.

Could you post the first few lines of the kernel output (including the kernel version and the command line)?

Thanks,

Michael

allenb · 2015-09-16, 19:48

(2015-09-16 19:35)mcb30 Wrote: Could you post the first few lines of the kernel output (including the kernel version and the command line)?

Sure, here's the last one I've got handy. It's with the most current CentOS kernel but that doesn't appear to have changed the failure any. It should match up with the other lines I posted earlier:

http://myhost:***@10.130.64.16/allen/vml....x86_64... ok
http://myhost:***@10.130.64.16/allen/initrd.img... ok
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Initializing cgroup subsys cpuacct
[ 0.000000] Linux version 3.10.0-229.14.1.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Tue Sep 15 15:05:51 UTC 2015
[ 0.000000] Command line: vmlinuz-3.10.0-229.14.1.el7.x86_64 ro initrd=initrd.img console=ttyS1,115200n8
[ 0.000000] e820: BIOS-provided physical RAM map:

Thanks for taking a look!

Allen

***mcb30*** · 2015-09-16, 20:21

(2015-09-16 19:48)allenb Wrote: Sure, here's the last one I've got handy. It's with the most current CentOS kernel but that doesn't appear to have changed the failure any. It should match up with the other lines I posted earlier:

[ 0.000000] Linux version 3.10.0-229.14.1.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #1 SMP Tue Sep 15 15:05:51 UTC 2015

That log shows a RHEL7 kernel, but you are talking about the "latest CentOS kernel".

The relevant kernel fix was in 3.16.0. You are using a 3.10.0 kernel to which the fix may or may not have been backported. I really do need to know exactly which kernel version you are using.

Michael

allenb · 2015-09-16, 20:33

(2015-09-16 20:21)mcb30 Wrote: That log shows a RHEL7 kernel, but you are talking about the "latest CentOS kernel".

The relevant kernel fix was in 3.16.0. You are using a 3.10.0 kernel to which the fix may or may not have been backported. I really do need to know exactly which kernel version you are using.

Hi Michael,

Kernel is definitely CentOS. It's from here:

http://mirror.centos.org/centos/7/centos...x86_64.rpm

Per the reference in https://bugs.centos.org/view.php?id=8295, this should contain the backported patch. In my experience, it fails identically to the stock CentOS pxelinux image at http://mirror.centos.org/centos/7/os/x86...t/vmlinuz.

As best I can determine, either I'm hitting a different (but similar) bug, or the fix isn't really in that centosplus kernel.

Thanks,
Allen

longjohngolf · 2015-12-08, 02:15

Allen,

Did you have any luck with this? I'm having the exact same problem, same hardware, also Centos 7.

Best,

John

longjohngolf · 2015-12-08, 02:28

(2015-09-16 20:33)allenb Wrote:
(2015-09-16 20:21)mcb30 Wrote: That log shows a RHEL7 kernel, but you are talking about the "latest CentOS kernel".

The relevant kernel fix was in 3.16.0. You are using a 3.10.0 kernel to which the fix may or may not have been backported. I really do need to know exactly which kernel version you are using.

Hi Michael,

Kernel is definitely CentOS. It's from here:

http://mirror.centos.org/centos/7/centos...x86_64.rpm

Per the reference in https://bugs.centos.org/view.php?id=8295, this should contain the backported patch. In my experience, it fails identically to the stock CentOS pxelinux image at http://mirror.centos.org/centos/7/os/x86...t/vmlinuz.

As best I can determine, either I'm hitting a different (but similar) bug, or the fix isn't really in that centosplus kernel.

Thanks,
Allen

Hi Allen,

Did you ever find a solution to this issue? I'm having the same issue, same hardware, etc.

Thanks!

fbacchella · 2015-12-17, 13:09

Any news about that ? Just tried on Centos 7.2, no change.

allenb · 2016-02-01, 21:49

(2015-12-17 13:09)fbacchella Wrote: Any news about that ? Just tried on Centos 7.2, no change.

Hi All,

I worked around it at the time, because CentOS 7 wasn't critical to me yet. But I'm back there now. Am building latest (as of today) iPXE from source, including 64 bit ipxe.efi module.

On an HP G8 box (BIOS), I'm able to boot as expected, using the "vmlinuz" and "initrd.img" files provided at http://mirrors.greenmountainaccess.net/c...ot/vmlinuz (just an example).

On an HP G9 box (UEFI), the kernel boots but ultimately comes crashing down in the usual manner:

No filesystem could mount root, tried:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Am going to swap in a different kernel and drivers to see if that makes any difference, will report back.

allenb · 2016-02-02, 00:44

Ok, tried a variety of things. Most notably, took the kernel that's provided by EL Repo at http://elrepo.org/linux/kernel/el7/x86_6...x86_64.rpm and experimented. Will skip the details of various things which did not work.

What I've got at the moment seems to work, or at least gets me to the point in anaconda where I've got a problem with Kickstart. That's progress.

Solution, or should I say workaround, was to take the kernel image itself from the elrepo package above and replace the pxeboot/vmlinuz file. Then I took apart the pxeboot/initrd.img file and removed the lib/modules/3.10 drivers and replaced them with the ones from elrepo. Ran the necessary depmod and packaged up a new initrd.

With all of that, I'm able to boot right into anaconda. Seems like a solution even if it's far from ideal.

If this is interesting to anyone else, I'm happy to provide specific instructions. Will do so tomorrow, time permitting.

Allen

(2016-02-01 21:49)allenb Wrote:
(2015-12-17 13:09)fbacchella Wrote: Any news about that ? Just tried on Centos 7.2, no change.

Hi All,

I worked around it at the time, because CentOS 7 wasn't critical to me yet. But I'm back there now. Am building latest (as of today) iPXE from source, including 64 bit ipxe.efi module.

On an HP G8 box (BIOS), I'm able to boot as expected, using the "vmlinuz" and "initrd.img" files provided at http://mirrors.greenmountainaccess.net/c...ot/vmlinuz (just an example).

On an HP G9 box (UEFI), the kernel boots but ultimately comes crashing down in the usual manner:

No filesystem could mount root, tried:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Am going to swap in a different kernel and drivers to see if that makes any difference, will report back.

MultimediaMan · (This post was last modified: 2016-02-02 01:29 by MultimediaMan.)

The message you are seeing occurs because the vmlinuz cannot find the initrd.

In a UEFI system, the EFI_STUB in the Kernel needs initrd to specified as a path. PCBIOS can "figure it out". Typically, "initrd=initrd.img" is enough. If you have multiple initrd files you may need to specify them as "initrd=initrd.img,drivers.ko" or "initrd=initrd.img initrd=drivers.ko"

Example:

Code:

#!ipxe

echo EFI or PCBIOS

initrd ${17}/Media-Depot/linux/CentOS/latest/EL/x86-64/OEM/os/images/pxeboot/initrd.img

chain ${17}/Media-Depot/linux/CentOS/latest/EL/x86-64/OEM/os/images/pxeboot/vmlinuz initrd=initrd.img

allenb · (This post was last modified: 2016-02-02 17:59 by allenb.)

Hi MM,

Have been using "initrd=" in all of my UEFI testing. Still finding that things work when I replace the kernel & drivers with ones from ELRepo and do not work when using the standard releases from CentOS 7. Would be curious if this workaround does the trick for anyone else.

This is on HP G9 hardware, DL380 specifically, in UEFI mode.

Was unaware that multiple initrd files could be used. That's handy, thanks!

Allen

(2016-02-02 01:27)MultimediaMan Wrote: The message you are seeing occurs because the vmlinuz cannot find the initrd.

In a UEFI system, the EFI_STUB in the Kernel needs initrd to specified as a path. PCBIOS can "figure it out". Typically, "initrd=initrd.img" is enough. If you have multiple initrd files you may need to specify them as "initrd=initrd.img,drivers.ko" or "initrd=initrd.img initrd=drivers.ko"

Example:

Code:

#!ipxe echo EFI or PCBIOS initrd ${17}/Media-Depot/linux/CentOS/latest/EL/x86-64/OEM/os/images/pxeboot/initrd.img chain ${17}/Media-Depot/linux/CentOS/latest/EL/x86-64/OEM/os/images/pxeboot/vmlinuz initrd=initrd.img

Ah, unbelievable!

There was an important bit of detail in MM's response that I almost missed. It turns out the method that I was using in our config files wasn't quite right. I'd inherited it from previous efforts and because it worked in many cases, including UEFI with an alternate kernel, it seemed correct.

What I was doing:

kernel blahblah initrd=foobar.img
initrd foobar.img
boot

What actually works with the "out of the box" pxeboot files:

initrd foobar.img
chain blahblah initrd=foobar.img

Better to know now than never. Hope this helps some others. Thanks, MM.

Cheers,
Allen

(2016-02-02 01:27)MultimediaMan Wrote: The message you are seeing occurs because the vmlinuz cannot find the initrd.

In a UEFI system, the EFI_STUB in the Kernel needs initrd to specified as a path. PCBIOS can "figure it out". Typically, "initrd=initrd.img" is enough. If you have multiple initrd files you may need to specify them as "initrd=initrd.img,drivers.ko" or "initrd=initrd.img initrd=drivers.ko"

Example:

Code:

#!ipxe echo EFI or PCBIOS initrd ${17}/Media-Depot/linux/CentOS/latest/EL/x86-64/OEM/os/images/pxeboot/initrd.img chain ${17}/Media-Depot/linux/CentOS/latest/EL/x86-64/OEM/os/images/pxeboot/vmlinuz initrd=initrd.img

***mcb30*** · 2016-02-03, 11:26

(2016-02-02 17:25)allenb Wrote: What I was doing:

kernel blahblah initrd=foobar.img
initrd foobar.img
boot

What actually works with the "out of the box" pxeboot files:

initrd foobar.img
chain blahblah initrd=foobar.img

Those are identical as far as iPXE is concerned: the only difference is in which file gets downloaded first. This will affect the placement in memory, which could potentially make a difference if your kernel does not include the backported fix mentioned earlier.

Michael

allenb · 2016-02-03, 17:46

Ah, thanks Michael. That makes a lot of sense. It hadn't occurred to me that the CentOS pxeboot/vmlinuz might not have that backported but it seems to be the case.

I'll stick with things as I have them now (ie, loading the initrd first, then the kernel) unless it shows any signs of instability. If it does, will replace the kernel with one I'm sure has the patch.

And Michael, thanks a bunch for your work on the project and UEFI/EFI issues!

Allen

(2016-02-03 11:26)mcb30 Wrote: Those are identical as far as iPXE is concerned: the only difference is in which file gets downloaded first. This will affect the placement in memory, which could potentially make a difference if your kernel does not include the backported fix mentioned earlier.

Michael

karakTaka · 2016-02-18, 16:54

Hi,

I managed to get centos booting by adding the squash image directly to my ipxe config.
Seems like in BIOS mode this file can be retrieved autimatically by the system, but not in UEFI mode.

This squashfs image is located here by example: http://mirror.centos.org/centos-7/7/os/x86_64/LiveOS/

:centos-install-7
echo Starting CentOS 7 ${archl} installer
set base-url ${boot-url}/unattended/centos
kernel ${base-url}/centos7_${archl}.kernel initrd=centos7_${archl}.initrd inst.repo=http://${128.1:string}/centos/7/os/x86_64
initrd ${base-url}/centos7_${archl}.initrd
initrd ${base-url}/centos7_${archl}.squash
boot || goto failed
goto start

allenb · 2016-03-22, 04:59

Hi All,

Wanted to pass along a little bit more information which could be of use down the line. I've got two workable methods for booting the CentOS 7 installer via iPXE on a UEFI system. I hope this information is useful to someone.

Method 1: The somewhat ugly workaround for unmodified images.

It seems possible to consistently boot the completely stock CentOS 7 pxeboot files with something like this:

initrd <%= kickstart %>/allen/blank32m.bin
initrd <%= kickstart %>/allen/centos7-initrd.img
initrd <%= kickstart %>/allen/blank32m.bin
kernel <%= kickstart %>/allen/centos7-vmlinuz initrd=centos7-initrd.img
initrd <%= kickstart %>/allen/blank32m.bin
boot

The files called "blank32m.bin" contain 32MB of nulls. The idea was to take up space and prevent anything from being overwritten due to the pre-3.16 bug in EFISTUB. I came up with this in a moment of semi-desperation and I've not read the ipxe source to understand how useful it may actually be. However, it does work in our environment and may be worth a try for other folks. Perhaps mcb30 or another dev can weigh in.

(this came up when I ran into a hardware combination where merely reversing the order of initrd & kernel as described above no longer worked)

Method 2: Using a newer ELRepo kernel which has the relevant EFISTUB fix which appeared in 3.16

This works without any silly magical guesswork/hacks with the loading of initrd as in the first method. The downside is that it requires you to extract, modify, and rebuild the pxeboot/initrd.img provided by CentOS 7. Essentially what you'll be doing is inserting the necessary /lib/modules directory from a newer ELRepo kernel package and then making a few changes so that it will all work. Note that this does not affect which kernel is eventually installed via Kickstart.

NOTE: I posted this a few hours ago using the CentOS kernelplus kernel which claims to have backported the EFISTUB patch, per https://bugs.centos.org/view.php?id=8295. As best I can determine, it doesn't work, or doesn't work reliably on all of my hardware. This update appears to.

1. Download the ELRepo kernel rpm. I'm using kernel-ml-4.5.0-1.el7.elrepo.x86_64.rpm from http://elrepo.org/linux/kernel/el7/x86_6...x86_64.rpm

2. Extract that rpm to a temporary directory via "rpm2cpio ../kernel-ml-4.5.0-1.el7.elrepo.x86_64.rpm | cpio -idum"

3. Download the initrd.img, such as from http://mirror.centos.org/centos-7/7/os/x...initrd.img

4. Extract that into another temporary directory via "xzcat ../initrd.img | cpio -idum"

Note that my temporary directories are called "kernel" and "initrd", within a "repack" directory. I'm running as root to keep file ownership correct.

5. Within initrd, "rm -r lib/modules/3.10.0-327.el7.x86_64"

6. From the upper "repack" directory, copy over the modules provided with the new kernel by using "rsync -a kernel/lib/modules/4.5.0-1.el7.elrepo.x86_64 initrd/lib/modules"

7. Build the dependency information. You'll need to adjust your absolute path but for me it's "depmod -ae -b /home/abelletti/repack/initrd 4.5.0-1.el7.elrepo.x86_64"

8. Within initrd, mkdir "etc/modules-load.d"

9. echo "loop" >etc/modules-load.d/loop.conf

10. echo -e "libcrc32c\nxfs" >etc/modules-load.d/xfs.conf

11. echo -e "fat\nvfat" >etc/modules-load.d/fat.conf

NOTE: Why steps 9-11? It turns out that the kernel signing key that's used for the regular CentOS 7 kernel and modules isn't the same as the one used by ELRepo. By the time these modules (loop, libcrc32c, xfs, fat, and vfat) are called for, Dracut has already replaced our /lib/modules directory with the one in squashfs.img. As a result, the modules won't load. Listing them in modules-load.d forces them to be loaded earlier, when the kernel and module keys still match.

12. Again from initrd, build the new img file. NOTE: The CentOS kernelplus kernel which I originally tried to use seems to be built without support for xz compression. I'm using lzma instead, which does work: "find . | cpio --create --format='newc' | lzma > /your/boot/files/centos7-elrepo45-initrd-lzma.img

13. From repack, "cp kernel/boot/vmlinuz-4.5.0-1.el7.elrepo.x86_64 /your/boot/files/vmlinuz-4.5.0-1.el7.elrepo.x86_64"

14. Adjust your ipxe configuration as needed. I'm using:

initrd <%= kickstart %>/allen/centos7-elrepo45-initrd-lzma.img
chain <%= kickstart %>/allen/4.5.0-1.el7.elrepo.x86_64 initrd=centos7-elrepo45-initrd-lzma.img lots-of-other-kernel-options

15. Give it a try! I went through the process as I wrote the above, and it's working for me so hopefully will work for you. If you have any questions, I'll be glad to assist if I can.

Cheers,
Allen Belletti

Donofap · 2017-04-04, 06:54

(2016-02-18 16:54)karakTaka Wrote: Hi,

I managed to get centos booting by adding the squash image directly to my ipxe config.
Seems like in BIOS mode this file can be retrieved autimatically by the system, but not in UEFI mode.

This squashfs image is located here by example: http://mirror.centos.org/centos-7/7/os/x86_64/LiveOS/

:centos-install-7
echo Starting CentOS 7 ${archl} installer
set base-url ${boot-url}/unattended/centos
kernel ${base-url}/centos7_${archl}.kernel initrd=centos7_${archl}.initrd inst.repo=http://${128.1:string}/centos/7/os/x86_64
initrd ${base-url}/centos7_${archl}.initrd
initrd ${base-url}/centos7_${archl}.squash
boot || goto failed
goto start

Worked for me. Thanks a lot.

adokania · 2017-04-18, 07:09

Hi Allen,

I am trying to install RHEL 7 (kernel version is 3.10.0-123.e17.x86_64). I used the same set of commands as mentioned by you...loading the initrd first and then kernel. I still get the issue "No file systems could mount root, kernel panic: unable to mount root fs on unknown block"
Any idea how to resolve it?

(2016-02-02 17:25)allenb Wrote: Hi MM,

Have been using "initrd=" in all of my UEFI testing. Still finding that things work when I replace the kernel & drivers with ones from ELRepo and do not work when using the standard releases from CentOS 7. Would be curious if this workaround does the trick for anyone else.

This is on HP G9 hardware, DL380 specifically, in UEFI mode.

Was unaware that multiple initrd files could be used. That's handy, thanks!

Allen

(2016-02-02 01:27)MultimediaMan Wrote: The message you are seeing occurs because the vmlinuz cannot find the initrd.

In a UEFI system, the EFI_STUB in the Kernel needs initrd to specified as a path. PCBIOS can "figure it out". Typically, "initrd=initrd.img" is enough. If you have multiple initrd files you may need to specify them as "initrd=initrd.img,drivers.ko" or "initrd=initrd.img initrd=drivers.ko"

Example:

Code:

#!ipxe echo EFI or PCBIOS initrd ${17}/Media-Depot/linux/CentOS/latest/EL/x86-64/OEM/os/images/pxeboot/initrd.img chain ${17}/Media-Depot/linux/CentOS/latest/EL/x86-64/OEM/os/images/pxeboot/vmlinuz initrd=initrd.img

Ah, unbelievable!

There was an important bit of detail in MM's response that I almost missed. It turns out the method that I was using in our config files wasn't quite right. I'd inherited it from previous efforts and because it worked in many cases, including UEFI with an alternate kernel, it seemed correct.

What I was doing:

kernel blahblah initrd=foobar.img
initrd foobar.img
boot

What actually works with the "out of the box" pxeboot files:

initrd foobar.img
chain blahblah initrd=foobar.img

Better to know now than never. Hope this helps some others. Thanks, MM.

Cheers,
Allen

(2016-02-02 01:27)MultimediaMan Wrote: The message you are seeing occurs because the vmlinuz cannot find the initrd.

In a UEFI system, the EFI_STUB in the Kernel needs initrd to specified as a path. PCBIOS can "figure it out". Typically, "initrd=initrd.img" is enough. If you have multiple initrd files you may need to specify them as "initrd=initrd.img,drivers.ko" or "initrd=initrd.img initrd=drivers.ko"

Example:

Code:

#!ipxe echo EFI or PCBIOS initrd ${17}/Media-Depot/linux/CentOS/latest/EL/x86-64/OEM/os/images/pxeboot/initrd.img chain ${17}/Media-Depot/linux/CentOS/latest/EL/x86-64/OEM/os/images/pxeboot/vmlinuz initrd=initrd.img

fdge · 2017-07-12, 23:45

did you try snponly.efi instead of ipxe.efi?

aiirii · 2019-07-19, 04:04

Worked for me. Thanks a lot.

(2016-02-18 16:54)karakTaka Wrote: Hi,

I managed to get centos booting by adding the squash image directly to my ipxe config.
Seems like in BIOS mode this file can be retrieved autimatically by the system, but not in UEFI mode.

This squashfs image is located here by example: http://mirror.centos.org/centos-7/7/os/x86_64/LiveOS/

:centos-install-7
echo Starting CentOS 7 ${archl} installer
set base-url ${boot-url}/unattended/centos
kernel ${base-url}/centos7_${archl}.kernel initrd=centos7_${archl}.initrd inst.repo=http://${128.1:string}/centos/7/os/x86_64
initrd ${base-url}/centos7_${archl}.initrd
initrd ${base-url}/centos7_${archl}.squash
boot || goto failed
goto start