UEFI Boot - Kernel panic: Unable to mount root fs on /dev/ram0
-
I’m facing an issue when PXE booting on PCs with UEFI. The boot fails with the following error:
Kernel panic - not syncing: VFS: Unable to mount root fs on "/dev/ram0" or unknown-block(1,0) Kernel Offset: disabled ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on "/dev/ram0" or unknown-block(1,0) This issue only happens on UEFI clients — legacy BIOS boots work fine.
What I’ve tried:
Tested different DHCP boot file options:ipxe.efi
andsnponly.efi
— same result
Tried both latest and older versions ofbzImage
andinit.xz
— no changeThe DHCP server runs on the same FOG Project server.
My topology is: ESXi Host → Cisco Switch → Client.
Other PCs with BIOS boot normally - but UEFI clients always fail with the error above.Any ideas what might be causing this or how to fix it?
Thanks in advance!
-
@mbghost This error message baffles me. If its happening where I think its happening its not a pxe boot issue. This error happens after you pick an iPXE menu item or if you tell a computer to image.
So you can probably rule out ipxe.efi/snp.efi here.
This error message is generated with FOS linux is booting. The kernel has booted and when it goes to connect to init.xz the format of init.xz is corrupt for some reason.
What version of FOG are you running
What version of “the kernel” are you running?
What version of init.xz are you running (get this from a bios computer that boots. the version of the init will be under the fog logo)What computer is this happening on (make and model)?
Is it all uefi systems or only from one manufacture?
How much ram does this computer have?
Are you seeing both bzImage and init.xz get transferred completely to the target machine. This will be visible just after you pick an item on the FOG iPXE menu.To me this error is telling me something is wrong with init.xz or for some reason bzImage is not the right kernel for init.xz
-
@george1421 Yep, this happens after the PXE boot menu, when I select “Quick Registration”.
I’m running the latest stable version of FOG 1.5.10.1667
bzImage: 6.12.25
Init: 20250429The affected machines are Toshiba all-in-ones that support only UEFI, 8Gb RAM, and NMVe from Western Digital
The problem is that it works at first, but then it suddenly stops. In most cases, it works fine right after a fresh FOG installation with the default kernel, and default configuration.
I’ve already tried setting up new FOG servers multiple times when changing kernel (bzImage and Init.xz) didn’t help. Then I install a fresh server again, and it works — but after a day, the issue comes back.I tried almost already everything on internet
I’ve done this about 10 times — it doesn’t work at all. Then on the 11th try it suddenly works, but again only for a day before failing with the same error. Still I didn’t change anyting on server or client. Server I tried use Fedora 38 and Ubuntu 12.8.0.
So it’s really inconsistent and only happens on UEFI clients. BIOS clients most time work fine.
Maybe something wrong with Cisco Switch, cuz couple years ago it works without problem on this Toshiba all-in-ones with Mikrotik Switch, and use use portfast on Cisco Switch port.
-
@mbghost I’m still leaning towards init.xz corruption. Its very strange that on a fresh fog sever it works on day one and then the next its no good.
Just for clarification its all and every Toshiba all in ones but other models work just fine? Its only this specific model.
What I’m thinking at the moment is that bzImage transfers fine and its around 8MB in size. The kernel also boots fine because its getting to the point where it attempts to connect to the root file system.
init.xz is a zstd compressed image. Its compressed size is around 350MB. Both images are very small in size. Something is happening to the init.xz image to where bzImage is not able to mount it and the kernel panics.
This image persists across multiple deployments and multiple installs of FOG server. It also crosses different init.xz and bzImage kernels.
FOS linux does boot 1 out of 12 attempts.
So where could the problem hide?
- The FOG server hardware if that was a consistent deployment throughout the server rebuilds. (test try building fog server on a desktop/laptop computer to rule out fog server infrastructure)
- Something with the network between the fog server and the target computer. (move target computer as physically close to fog server as possible and test deployments eliminating all of the existing networking between fog server and target computer)
- Something with the target computer. (if you have been testing with the same computer throughout these tests use a different computer. Its possible there is a ram issue with this computer)
Right now there isn’t a clear picture on the cause. I can say this IS unique and I’ve haven’t seen this before with FOG.
Something else you might do is in the fog settings, set the log level to 7. I think the default is 4. 7 is verbose and the kernel might spit out more information to why its not happy with the init.xz file. Like decompression failed.
-
@george1421 Got it, Thanks. Next week I’ll try using a different switch — maybe that will help. Right now, there’s only one Cisco switch between server and client, so I’ll try changing the model to see if it makes any difference.
All the Toshiba All-in-One devices are the same model, and I’ve tried several of them. As I mentioned earlier, everything works fine on a different All-in-One model that only supports BIOS - it’s some unbranded device from China.