Lenovo Yoga 12 Issues

[TBCS]

When On UEFI, fog will be unable to mount the file system if a task is created.

When on BIOS, if a task is created, it hangs on init.xz.

[TBCS]

To add a little bit more detail, we’ve imaged hundreds of machines and have only had this error on these.

I guess they’re technically Thinkpad Yoga 12s. We have to use an official lenovo ethernet adapter to image them.

[george1421]

@TBCS Are you running FOG v1.5.6 too? I have seen this “unable to mount images folder” in several posts lately. Its strange that its only happening on these Yoga 12s.

If you schedule unicast imaging does it work correctly?

[TBCS]

@george1421 No we are running 1.5.5. Unicast images fail most of the time, on some yogas it seems like it works sometimes but in general they fail all in the same way.

[george1421]

@TBCS Interesting. Let me do a little research. I’m wondering if a slow response from the FOG server is causing the target to throw this error. The slow response could be coming from the target computer too. Let me see what generates that error message first.

[george1421]

@TBCS

For reference this is the section of code responsible for throwing that error message

case $type in
    up)
        mount -o nolock,proto=tcp,rsize=32768,wsize=32768,intr,noatime "$storage" /images >/tmp/mount-output 2>&1
        ;;
    down)
        mount -o nolock,proto=tcp,rsize=32768,intr,noatime "$storage" /images >/tmp/mount-output 2>&1
        ;;
esac
case $? in
    0)
        echo "Done"
        debugPause
        ;;
    *)
        echo "Failed"
        debugPause
        handleError "Could not mount images folder ($0)\n   Args Passed: $*\n    Reason: $(cat /tmp/mount-output | tr -d \\0)"
        ;;
esac

So here is what I want you to do. It will help to debug if you have a computer that is consistently failing to image. If its not broken, its hard to fix the issue.

1. Schedule a unicast deployment to that computer, but before you hit the schedule button tick the debug checkbox.
2. PXE boot the computer.
3. After a few enter key presses you will be dropped to the FOS Linux command prompt.
4. At the FOS Linux command prompt key in these commands.

mkdir /testfs
mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs

That should hopefully mount the FOG server’s /images to FOS’ testfs directory. You can confirm it works by keying in ls -la /testfs If it returns files and directories then its working.

ref: https://www.tldp.org/LDP/nag2/x-087-2-nfs.mountd.html

timeo=n

    This sets the time (in tenths of a second) the NFS client will wait for a request to complete. The default value is 7 (0.7 seconds). What happens after a timeout depends on whether you use the hard or soft option.

[Sebastian Roth]

@TBCS Are all the Yogas in a specific part of your network (one switch/room/subnet)? It’s kind of unlikely this is caused by the Yogas being UEFI systems. What could be the case is that the network driver for the NIC used (probably an external adapter, right?) is kind of buggy and not allowing for a proper NFS connection. But as we check network connection on bootup it’s also very unlikely.

I guess George is on the right track here. Your network seems to not handle the default 0.7 second timeout well and therefore you see random failures. Try manual mounting as George suggested a couple of times in a row to see how often it fails.

mkdir /testfs
mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs
umount /testfs
mount -o nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs
umount /testfs
...

Then add the timeout option as well and see if it’s doing any better.

mount -o timeo=10,nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs
umount /testfs
mount -o timeo=20,nolock,proto=tcp,rsize=32768,intr,noatime 10.10.1.93:/images /testfs
umount /testfs
...