Black screen and blinking cursor after vesamenu
-
@george1421 said in Black screen and blinking cursor after vesamenu:
Is there a minimum processor level within the iPXE binaries, akin to where the kernel has minimum level supported processor?
Not sure about that. I don’t think so as iPXE doesn’t use modern CPU features much I guess and would therefore run on plain old 386 I suppose. But not exactly sure.
-
@Luc-Novales Still waiting for you to test
01_undionly.kpxe! Please let us know. -
Hi,
I have to report some actions to explain where I am now.Using IPXE
After a lot of tries 2 weeks ago, yesterday, I decide to compile IPXE “from scratch”, using a clean clone of ipxe git repository.
Applying “486 patch”
After removing definition TIVOLI_VMM_WORKAROUND in configuration file general.h as defined in the forum of ipxe “486er hangs on boot with iPXE floppy”, I obtain an USB boot media (ipxe.usb) to launch ipxe command and test FOG menu.
Compiling FOG IPXE
Compiling IPXE using IPXE part of the WIKI and applying “486 patch” (above) allow to obtain an undionly.kpxe usable with this panel PC.
Loading FOG menu
Configuring DHCP server to load new undionly.kpxe doesn’t load menu but allow to chain it manually.
Select “CLient System Information (Compatibiliy)” load effectively bzImage32 and stop with the message “This kernel requires an i686 CPU but only detected an i586 CPU”.Using adapted linux kernel to i586
Trying to compile custom kernel, I opened another thread and George send me a bzImage file adapted to i486 (see FAQ page in WIKI should be updated).
Boot from FOG menu
Chain manually boot.php with MAC address parameter boot and the result is here
Fog menu for this host is hereTODO
- Determine why undionly.kpxe doesn’t load menu
- Determine why kernel loop on RCU grace-period stack dump.
-
@Luc-Novales Don’t want to sound rude but how many of those panel PCs do you have? If it’s just a handful of them you might be way faster installing/cloning them manually using other means of deployment instead of trying to get FOS Linux to rnu on this kind of mul-functioning hardware.
Search the forums for “rcu_sched detected stalls on CPUs/tasks”…
-
@Sebastian-Roth said in Black screen and blinking cursor after vesamenu:
@Luc-Novales Don’t want to sound rude but how many of those panel PCs do you have? If it’s just a handful of them you might be way faster installing/cloning them manually using other means of deployment instead of trying to get FOS Linux to rnu on this kind of mul-functioning hardware.
Today It’s the only reason to maintain an old server this an old version of clonezilla. All other stuff of our equipment in our learning rooms are managed on newer server with FOG. It should be better to integrate these panel PC too
Search the forums for “rcu_sched detected stalls on CPUs/tasks”…
I will…In your signature :
…way more we need people to test things, update documentation…
Solving this problem, learning to compile new kernel… is perhaps the only way I have to update documentation and contribute to FOG
-
Ok update on this thread so we can put it to bed.
I built 2 custom FOS Linux kernels the fist was targeted to a 486 and the second was targeted to the Geode processor. Bot would throw the issue with an unstable clocksouce. We could only see this error when we change the linux kernel logging level to 7. After some google fu and attempting a few kernel parameters that dealt with the clocksouce I found a references to
apci=off. That was the actual parameter that solved the kernel boot errors. The OP was then able to run a deployment in debug mode to completion.So while the actual problem isn’t in line with the thread subject. The issues were this.
-
The standard FOS Linux kernel has a minimum supported level of processor of i586. I had to build a custom kernel with a minimum processor level of i486 to get the kernel to boot.
-
Because of the hardware we had to specifically turn off acpi in the kernel using the kernel parameter of
apci=off
-
