DELL 5060

[tice.stan]

Hello,
I have a problem with DELL 5060.
They have 1 ssd SK hynix SC311 SATA 128GB for system and 1 HDD barracuda st500dm009 for DATA
I use:
FOG v1.5.9
Kernel v5.10.34
Multiple Partition Image - All Disks (Not Resizable)
Registration and Capture work but deployment returns an error “no disk passed”.
If I put back the kernel v4.19.145 it works normaly
For the moment I have no problem with the kernel v4.19.145 but it can be interesting to find out where the problem comes from.
Thank you

[tice.stan]

@sebastian-roth

Good news everyone.
Problem seems to be resolved, image is deployed normally.
Thank you for your investment and your speed.

[Sebastian Roth]

@tice-stan Good news. I am fairly sure I found and fixed the issue!

This is neither related to the specific hardware (as title and category of this post might suggest) nor is it related to the kernel used! It’s a bug in the init files! I can imagine you switch back and forth kernel AND init versions on your server at the same time and therefore thought this is caused by the 5.10.34 kernel, but it’s not.

Please do me a favor and run the following test:

• Switch to the 5.10.34 kernel (and 20210606 init with it)
• Download the fixed init and put in /var/www/html/fog/service/ipxe/ on your FOG server.
• Rename init.xz to init.xz.orig and init_mpa-fixed.xz to init.xz in that same directory on your server.
• Use the current image you have. No need to re-capture the image.
• Deploy and when you see the ASCII style FOG logo pay attention to the “Init version” printed. Should be 20210711!

Let us know if it works.

[Sebastian Roth]

@tice-stan said:

4.19.145 kernel is the one that is installed at the same time as fog 1.5.9

Obviously I wrote my last comment on the kernel version in a rush and didn’t remember this was the default kernel for FOG 1.5.9. So forget what I wrote about this.

Now back to the issue. Looking through the code again and again I can seem to find where this fails. Possibly at the start of putDataBack but still doesn’t make sense to me this is working with the 4.19.145 kernel but not using 5.10.34! I guess I will need to do some testing on my own.

[george1421]

@tice-stan For the 5060 to work that 4.19.x kernel needs to be updated to 5.10.x. This can be done in the FOG web ui -> FOG Configuration -> Kernel update. Download both the x64 and x86 kernels. The network adapter in the 5060 was first added to the 5.5.x linux kernel. 4.19.x doesn’t have the needed driver.

FWIW: FOG 1.5.10 (when its released) will come with 5.10.<what ever is current> version of the linux kernel and not 4.19.x any more.

[tice.stan]

@sebastian-roth
4.19.145 kernel is the one that is installed at the same time as fog 1.5.9

[Deimos]

No, it is not a DELL. I will update Fog 1.5.5 to 1.5.9 today and make another test.

[Sebastian Roth]

@Deimos Are you absolutely sure this is the same issue you run into? Do you have Dell 5060 machines as well? Does it fail with the exact same message afer “Restoring Partition Tables (GPT)” step?

Good you mention the 4.19.145 kernel. When I read that at first I did not check the version number. Not sure where this kernel is from. It’s not available on our official kernel download site. @tice-stan Where did you get that kernel from or is there a typo in the version number?

[Deimos]

Are there any solutions or hints? I am facing the same problem actually.

Capture was no problem, but deploy runs into the same error.
I need the kernel v4.19.145, I cannot find any download source

[tice.stan]

@sebastian-roth
I don’t know if this question is for me ^^, but HDD is empty.

[Sebastian Roth]

@george1421 @tice-stan This is really strange a switch of the Linux Kernel seems to be causing this error. From what I see in the code it’s this call to runPartprobe failing: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh#L2132

But I have no idea why $disk variable might be empty at this stage because it’s definitely being used a little bit further up in the same function (restorePartitionTablesAndBootLoaders) to restore the partition layout. If $disk would really be empty that would error out as well!?!

[george1421]

@tice-stan Well I see it but don’t believe it. The only difference is between the kernels. So the next question is what is the FOG imaging program doing at the time it throws the error.

Let me dig into the code.

[tice.stan]

@george1421
4.19.145

5.10.34

[george1421]

@tice-stan So does both 4.19 and 5.10 give you the same lsblk output. The error is inconsistent what we have been presented so far. Not saying you did anything wrong, only we have to be missing something.

Get a screen shot of this on both kernels
uname -a
lsblk

[tice.stan]

@george1421 I removed sbd5 from the computer (I don’t know why there were two recovery volumes).
I recaptured the image with the 5.10.34 kernel.
I tried to deploye image and I have the same error.

I put back kernel 4.19.145 and i trie to deploye… and it works

[george1421]

@tice-stan One of the pictures missed was what version of the kernel you were running when the error occurred.

Its strange why lsblk and the system would see different values based on the kernel change only. There is something amiss here.

[tice.stan]

@george1421 What is strange is that with an older kernel this works.
Do you think recapturing the image with the new kernel might help?

[george1421]

@tice-stan Every thing look good from a hardware standpoint. I think we will need to dig into the source image file to see how it was captured. I can say the way its setup it will probably put the OS disk as the HDD and make the sata 128GB as the d drive. That might be the issue where the drives might be switched in the configuration.

[tice.stan]

@george1421

All step return “Done” except the last one

[tice.stan]

@sebastian-roth