@spidajon How is the EFS AWS mounted? I think George is right in that you are trying to export a location that is mounted from elsewhere already, which is not possible as far as I know.

If so, you should follow his advice on how to handle the situation, if that is possible.

@aephk Try updating to FOG 1.5.7 and try again

What FOG version are you running?

If a file doesn’t exist, it won’t get a hash, I believe, so verify that the snapin files still exist.

After you update /etc/exports, you have to make sure they’re loaded.

exportfs -ra

I’m unfamiliar with AWS EFS, though.

@george1421 After reading up a bit more, it seems the conclusion is that it’s not so much about the disks themselves, but rather that the assignment is arbitrary if they’re connected to different controllers, which in the case of NVME will always be the case and in the case of SATA (on most modern consumer grade hardware at least) will not be the case.

@george1421 Created an issue over at github

https://github.com/FOGProject/fos/issues/27

This one will need some consideration I think, not really straightforward

@george1421 As far as I understand, in a normal Linux install they simply use UUID of the disk to determine the order (though predictability is still low since if any device isn’t working properly, any following devices will take up preceding values)

eg

3 disks
/dev/sda
/dev/sdb
/dev/sdc

disk /dev/sdb fails to load properly.

/dev/sda
/dev/sdb (was /dev/sdc previously!)

Since no such data is ever stored on FOS, it’s basically a race between the devices and whoever wins is the one on top.

Interesting.

Reading up more on this subject, I suspect this issue isn’t actually specific to NVME drives, but rather to any multi drive system where one drive is larger than the other since they can initialize in ‘random’ order.

Of course, with traditional drives they tend to be slow enough that they initialize in a more predictable pattern I guess.

@tlehrian I don’t believe there’s a solution currently, just some thoughts on how to potentionally address it, but without access to relevant hardware there is no way to confirm which direction we have to take.

Related thread: https://forums.fogproject.org/topic/13163/laptop-with-2-nvme-drives-randomly-selected-so-selecting-one-drive-to-capture-not-working

@tlehrian I believe this is a known problem that can occur when you have multiple NVME drives on a UEFI system as the numeration can change on reboot afaik.

@george1421 I agree for vital packages that waiting on Buildroot where possible is preferable, but something like Testdisk (which doesn’t come from Buildroot) could surely use a bump since that doesn’t break anything

You installed buildroot 2019.02.1

2019.02.4 actually, which doesn’t fundamentally changes any packages, just a bunch of bugfixes!

Sometimes you have to use a different pxe file. So try ipxe.pxe instead of undionly.kpxe at your DHCP server (don’t know if that’s your FOG server or not) as a boot option

I’m also wondering if we should look into updating other packages that FOG either overrides or provides manually. (eg testdisk is on 6.14 as opposed to 7.1 and even pigz is at 2.3.4 instead of 2.4 (although pigz seems to have introduced potentially backwards incompatible changes))

Removing the -B128 option seems to allow it to capture, finally!

64 bit init.xz Buildroot 2019.02.4 + ZSTD 1.4.2 + Partclone 0.3.12 (with APFS support)

32 bit init.xz Buildroot 2019.02.4 + ZSTD 1.4.2 + Partclone 0.3.12 (with APFS support)

Give it a whirl if you’re interested.

Current status:

• Specifying the -B128 option gives issues in certain scenarios (special partitions/raw/very small ones???), so we can’t reliably use that.

• In order to use --rsyncable, zstd had to be updated to a minimum of 1.3.8 (chosen the latest version of 1.4.2 to include performance improvements and bug fixes)

• Minor Buildroot update means config doesn’t have to be updated, it’s just bugfixes

• Added APFS support so that we can offer some better support for newer Macs (if they decide to PXE boot that is) (potentially gptfdisk package should be updated to 1.0.4 (adds typecodes for APFS and others), haven’t tested anything in this direction!)

Currently it fails to capture msftres partitions, throwing exit code 139 (presumably zstd’s error code). msftres is captured with partclone.imager

It’s difficult to see what’s going on because the screen breaks up, but it seems to not recognize any size on this type of partition on partclone 3.12 which is a regression compared to 2.89

edit: Adding a strategic debugPause tells me there is a segmentation fault on line 2041 in funcs.sh

Even stranger is that it is talking about line 2053, yet for some reason mentions line 2041???

Though not sure why this occurs…

edit2: Seems to be down to the fact that it writes to /tmp/pigz1

Direct writing to /images works fine

edit3: Welp, it seems to come and go as it pleases, not sure what the actual cause is!

edit4: My suspicion lies on B128 option being the culprit (initial test is promising), recompiling, will test tomorrow.

@Derek-Newbold Good to know that php-fpm is installed and running! (Speaking of running processes, what does CPU and RAM usage look like (for processes such as apache, mysql, php-fpm, etc) when you try to do something that takes a long time for you?)

Odd that you’re experiencing performance issues despite this. Though number of clients could contribute to this.

If you have a bunch of hosts/clients, it’s also possible your database has grown quite a bit over time which can slow things down a bit.

@george1421 I decided to go for 1.4.2 since it includes a couple of performance improvements and bug fixes.

Took a while longer because I forgot to include the hash file.

It’s finally compiling successfully, time for some more tests.

@Derek-Newbold What kind of virtualization software do you use?

One thing that I recall happened sometimes on ubuntu (not sure if it was specific to ubuntu) was the switch to php-fpm not actually happening properly so people would be running the new interface without php-fpm which would be quite slow when you have a lot of clients and such.

If you check running programs you can verify whether there’s php or php-fpm processes running, which should give use a better idea of your current situation.

Ubuntu in general has been somewhat problematic for FOG with dodgy updates on their end in relation to PHP and mysql and such.

nfs addresses have to be written like 192.168.1.2:/nfs (notice the :)