Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Kernel Offset: disabled

[Tom Elliott]

@b.nelson Is there a windows machine somewhere on the vlan handing out DHCP addresses then?

[b.nelson]

@Tom-Elliott In the VLAN there is no DHCP the server is with static IP.

The windows that we want to clone are in another VLAN with DHCP.

[Tom Elliott]

@b.nelson and the “remote” systems are on the “other” vlan when you’re attempting to capture?

[Tom Elliott]

Essentially, the thing Giving out DHCP is also giving the bootfile and where to boot from.

This “other” vlan is where you need to look at the bootfile it’s handing out.

[george1421]

@b.nelson said in Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Kernel Offset: disabled:

@george1421 There is a VLAN dedicated to the servers which is handled by static IP.

No, we did not have fog in the past.

So then for your pxe booting clients are they on the same vlan as your fog server?

[b.nelson]

@george1421 si

[george1421]

@b.nelson said in Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Kernel Offset: disabled:

The windows that we want to clone are in another VLAN with DHCP.

On this vlan you are using a router for dhcp?

[george1421]

@b.nelson said in Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Kernel Offset: disabled:

@george1421 si

Just to be sure fog server is on the same subnet as your pxe booting clients? If that is the case we can use the FOG server to tell us what is going on.

What you have is very strange and should not be working this way.

[b.nelson]

@Tom-Elliott yes

[george1421]

@george1421 I make a tutorial a while ago that might help here. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

We will use tcpdump to capture a client pxe booting to the FOG menu. Once at FOG menu stop tcpdump and post the pcap file to the forum. This will tell us all the questions we will ask.

[callcenter]

Dear All,
New user/taken over 1.3.8 project from coworker.
I am having the same issue after upgrading to 1.4.0 today. Not sure where to change pxelinux.0 reference. Using windows as DHCP with options set. Any help would be great!!

[george1421]

@callcenter If I remember correctly the target computer was getting pxelinux.0 from some unknown place.

If the target computer (that you are pxe booting) and fog server is on the same subnet then we can use the fog server to help diagnose what is really going on. In my last post I provided a link to a tutorial on how to setup a packet capture of the pxe booting process. That pcap file will tell us what is going on.

[callcenter]

It was the windows DHCP scopes having the old 67 option in them instead of the new undionly.kpxe program. updated all my scopes and tested-ok not using the main server options since my wifi and telco devices do not need PXE. I saw others make mention of doing that instead of every scope having the references. In my environment it just doesn’t make sense.

thanks for the help.

[george1421]

@callcenter So are we good to solve this issue?

[b.nelson]

@george1421 This appears to me

root@FOG:/home/user# tcpdump -w output.pcap port 67 or port 69 or port 4011
tcpdump: listening on enp0s7, link-type EN10MB (Ethernet), capture size 262144 bytes
^C0 packets captured
1 packet received by filter
0 packets dropped by kernel
root@FOG:/home/user#

[b.nelson]

@george1421 ```
tcpdump: listening on enp0s7, link-type EN10MB (Ethernet), capture size 262144 bytes
^C6 packets captured
7 packets received by filter
0 packets dropped by kernel
root@FOG:/home/user#

[george1421]

@b.nelson What I was asking for was for you to attach the output.pcap file to a forum post. I’ll take a look at it to see what is going down your wire.

[callcenter]

@callcenter good, thanks!