Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Kernel Offset: disabled
- FOG Version: 1.4.4
- OS: Ubuntu 17.04 (virtualbox vm on Windows 10, bridged adapter)
new install on virtualbox vm with dynamic virtual disk. using dnsmasq. the windows server dhcp servers within the organization do not have options 66 or 67 set and I must use dnsmasq (or alternative) instead of the organization’s dhcp servers.
I can successfully PXE boot to the FOG boot options menu (register, image, memtest, etc) - but when selecting any options on the menu, the above kernel panic appears.
contents of ltsp.conf:
Don’t function as a DNS server:
Log lots of extra information about DHCP transactions.
Set the root directory for files available via FTP.
Disable re-use of the DHCP servername and filename fields as extra
option space. That’s to avoid confusing some old or broken DHCP clients.
The boot filename, Server name, Server Ip Address
PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds.
pxe-prompt=“Booting FOG Client”, 3
The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
Intel_Lean_Client, IA32_EFI, ARM_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, “Boot BIOS PXE”, undionly.kpxe
pxe-service=BC_EFI, “Boot UEFI PXE-BC”, ipxe.efi
pxe-service=X86-64_EFI, “Boot UEFI PXE-64”, ipxe.efi
DHCP filtered PCAP attached. [0_1503502858629_output.pcap](Uploading 100%)
clients and server/host are on same subnet. firewall disabled on Ubuntu VM and Windows host.
could this have anything to do with the VM and a dynamically allocated virtual disk perhaps?
also unsure about the malformed dhcp packets seen in the dump output. strange issue.
should I also capture all traffic (unfiltered) in a tcpdump?
Thanks in advance.
Please close/resolve this thread. I foudn the answer on this post: https://forums.fogproject.org/topic/9604/kernel-offset-disabled-end-kernel-panic-not-syncing-vfs-unable-to-mount-root-fs/4 turns out my org must still somehow be pushing out pxelinux.0 even though admins said not. So I renamed a copy of undionly to pxelinux and its working.