Just added the parameter for 1.5.x too. Way easier to do it via the boot menu code than adding it within FOS using sysctl.
Will finally mark this solved! Thanks to everyone.
@Duncan Many thanks to you too!! Great work on the testing you’ve done here, awesome. I think this has given us a great set of recipes we can give people in case they run into that issue. We might even think about sending the kernel parameter
nvme_core.default_ps_max_latency_us=0 as default. @Tom-Elliott @Quazz @george1421 Do you see any issue with that?
nvme_core.default_ps_max_latency_us=0 - not a valid identifier
As George already said, this is not an issue but more a warning. I was hoping to find some time and fix that at some point. Will do so now.
@gusto I am not sure I can follow your questions.
According to this instructions we need to enable it
Options --> Feature --> Nestig - ON
Where did you read about “Nesting”? Can see anything about this in the linked wiki article. Did you follow the instructions mentioned in the wiki about Apparmor?
Do I need also to install NFS on a host (proxmox)?
I have done a LXC installations a couple of years ago but can’t remember this part anymore. If it’s not in the wiki I don’t think it’s needed.
That means I have to change pxelinux.0 to undionly.kpxe?
undionly.kpxe for legacy BIOS machines and
ipxe.efi for UEFI machines. Also see https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence and my post here: https://forums.fogproject.org/post/130612
I have tentatively installed NFS in LXC (centos 7). Then I wanted to destroy the LXC, but I couldn’t destroy the LXC because filesystem in use.
Not sure how to solve this. Not great but rebooting the whole server should definitely fix it.
@WalterT Good to hear you could fix this issue on your own. Too bad that we don’t have any information from you about how the password was, when ich caused an issue! How can we improve this if we don’t have any informaiton on what exactly went wrong?!
@Tom-Elliott Possibly it’s the
\ but I am not sure. We already changed the password generation method in
dev-branchand therefore this won’t be an issue from the next release on.
@george1421 Yes, good points:
nvme set-feature -f 0x0c -v=0 /dev/nvme0right? @Duncan @Quazz - Would you like to help testing as well, @oleg-knysh?
nvme_core.default_ps_max_latency_usparameter as well. Not sure if that sort of doing the same thing?! Probably a bit different but might have the same outcome?! The parameter is mentioned in that ARCH Linux wiki I posted below already. @Duncan Would you please test this kernel parameter for us on that problematic laptop? Go to the host’s settings in the web UI and set
nvme_core.default_ps_max_latency_us=0as Kernel Parameter but using the default kernel (4.15.x). See what speed you get. As well try
nvme_core.default_ps_max_latency_us=5500(as described in the wiki) also using default kernel. Thanks!
dhcp-range = <10.20.11.201> Proxy
@ty900000 I don’t think anyone has tried this before but I am sure it can be done. It’s not as straight forward as one might think because it’s not just the web UI accessed by the browser but also PXE booting clients and the fog-client sending requests to the webserver.
If you are keen to give it a try we can support you to make it work.
I’ll try to give you more details on how to generate the certificates on you FOG server tomorrow.
Kernel 4.9.51 … Deployed the image and away it went. Full speed. building about 8gb/min
Is this all the way through or just top speed? Maybe it’s better you note down the full deploy time to compare the different situations more appropriately?!
latest kernel with APST disabled… Its now building at 2.7gb/min.
Does this really mean it’s that much slower than using the 4.9.51 kernel or is it more just a top speed thing? As I said, better we compare the time it takes to deploy the full drive.
@brehuffm Here we see the important part of the log file:
12/5/2019 7:05 AM Middleware::Authentication ERROR: Could not authenticate 12/5/2019 7:05 AM Middleware::Authentication ERROR: Value cannot be null. Parameter name: authority
Some Linux distros use mono version that is causing the problem. We have fixed the client library but haven’t been able to push out a new release yet. Find details about this here: https://forums.fogproject.org/topic/13070/client-not-authenticating and https://forums.fogproject.org/topic/13374/fog-client-under-ubuntu-18-04-authentication-error-could-not-authenticate
In short: Download Zazzles_fixed_Linux.dll, stop FOGService (
systemctl stop FOGService), rename /opt/fog-service/Zazzles.dll and put the new Zazzles.dll in place. Then start the FOGService again and watch the log.
@Duncan Can’t believe it but if it’s the way you saying (and showing in the pictures) - what can I say… :-)
@Quazz gave me a good hint on kernel 4.10 or 4.11 introducing APST. We kind of expect this to be causing the problem. See some information on this here: https://wiki.archlinux.org/index.php/Solid_state_drive/NVMe#Power_Saving_APST
He also just added the
nvme cli tools to the FOS initrds so we could try to work on debugging more of this with more recent kernel versions.
It’s all up to you. If you are happy with the old
4.9.51 kernel we can just leave it like that. Though I don’t think it’s a great solution.
j’ai fais la commande sur / images car c’est un point de montage qui pointe vers / volumes1 / images2
Translated: “I made the command on / images because it is a mount point that points to / volumes1 / images2”
What do you mean by that?!
From what I see you have a huge mess with the FOG service account. Follow this guide and make it use
fogproject in every place: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password
As well run
chown -R fogproject:fogproject /images /volumes1/images2!