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

[Sebastian Roth]

@tice-stan Please help us debug this. Set the v5.10.34 kernel and schedule a debug deploy task. PXE boot the machine and hit ENTER twice to get to a command shell. Run the following commands, take a picture of the output and post that here:

lspci -nn
lsblk

[tice.stan]

@sebastian-roth I hope that will help you.

[Sebastian Roth]

@tice-stan said in DELL 5060:

but deployment returns an error “no disk passed”.

Well from the picture of lsblk you posted we see that FOS can see the disks. So I guess the error on deployment is a different one! Please take a picture of the error you see when deployment fails and post that here.

[george1421]

@tice-stan In addition to getting a clear image of the error as Sebastian recommended, I also think setting up a debug capture/deploy might give us a better understanding of what is going wrong.

After you capture the image Sebastian asks for then schedule another capture/deploy debug session. Preferably the same process you used to capture the previously mentioned error message. At the FOS Linux prompt I want you to key in the following commands and then take a clear picture like you did for the previous lsblk command.

1. cat /proc/cmdline
2. uname -a
3. lsblk
4. Get a picture of that
5. Start imaging in single step mode. Single step mode will require you to press enter between each break-point. Start imaging by keying in fog.
6. Now watch for any errors, maybe an error is displayed just before the error in your screen shot. Take a picture and post it of any new or hidden error.

This might not give us the answer we need, but this process will tell use where we don’t need to look for the problem.

[tice.stan]

@sebastian-roth

[tice.stan]

@george1421

All step return “Done” except the last one

[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 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 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 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 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
4.19.145

5.10.34

[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.

[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!?!

[tice.stan]

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

[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

[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]

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

[tice.stan]

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