Found and fixed a bug, just hoping it can get committed to future releases. I’m writing some post download scripts and the product key wasn’t decoding properly. So I just copied over this line from route.class.php, and all is well now.
Line 172 of hostinfo.php should be:
if (mb_detect_encoding($test_base64, 'utf-8', true)) {
Rather than:
if (mb_detect_encoding($test_base64)) {
@george1421
Do you think I’d be better of running with the RC of 5.5? Or with my tweaked version of 5.4, with the 3.6.0 e1000e driver injected in?
@george1421
Here’s the result of the requested command:
Ok, my kernel modification ended up working. Here’s a rundown of the steps I took to get it working…
cd /usr/src
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.12.tar.xz
tar -xf linux-5.4.12.tar.xz
cd linux-5.4.12
wget -O .config https://github.com/FOGProject/fos/raw/master/configs/kernelx64.config
git clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
make oldconfig
cd /usr/src
#The following line may need to be modified, if Intel ever changes the location of this driver
wget https://downloadmirror.intel.com/15817/eng/e1000e-3.6.0.tar.gz
tar -xf ./e1000e-3.6.0.tar.gz
cd e1000e-3.6.0/src
The driver source code needs to be modified to account for a change that was made in the kernel source code. Modify line 2799 of kcompat.h.
Change: #include <linux/pci-aspm.h>
to: #include <linux/pci.h>
Now to inject the 3.6.0 driver, and compile
cd /usr/src
rm -rf linux-5.4.12/drivers/net/ethernet/intel/e1000e
cp -rf e1000e-3.6.0/src linux-5.4.12/drivers/net/ethernet/intel/e1000e
cd linux-5.4.12
make -j4 bzImage
cp arch/x86/boot/bzImage /var/www/html/fog/service/ipxe/bzImage
I’m sure this is only going to be a temporary fix. I suspect the native linux kernel will be updated soon to include a more recent version of this driver. But until then, this seems to work.
Thanks for the speedy reply!
Based on this post, I’m currently operating off of the theory that version 3.2.6 of the e1000e driver is currently included with the 5.4.12 kernel, which may not be compatible with the controller built into the NUC. I’ve downloaded version 3.6.0 of the e1000e source code from Intel, and am trying to see if I can build a kernel with that version baked in. I don’t often drill into compiling my own kernels, so I’m not sure how much success, if any, I’ll have with this method.
Wanted to see if anyone had any luck getting a NUC10 to boot to FOG. I’ve tried a variety of the most recent kernels to no avail. I also followed the documented procedure for compiling my own 5.4.12 kernel, with no luck. The NUC has a I219 controller in it, and I’ve seen some similar posts in various forums with people having issues getting the controller to work properly in Linux, but none of the fixes I’ve found seem to do anything.
Any help would be much appreciated!
Found and fixed a bug, just hoping it can get committed to future releases. I’m writing some post download scripts and the product key wasn’t decoding properly. So I just copied over this line from route.class.php, and all is well now.
Line 172 of hostinfo.php should be:
if (mb_detect_encoding($test_base64, 'utf-8', true)) {
Rather than:
if (mb_detect_encoding($test_base64)) {
I had a hell of a time trying to figure out how to get System Rescue CD to boot with iPXE. The previous post by george1421 seems to only work if you’re trying to use System Rescue CD to boot an existing failing Linux OS.
These parameters work for booting the whole distro, and automatically running ‘startx’
:sysres
cpuid --ext 29 && set arch 64 || set arch 32
set path /netboot/systemrescuecd
set nfs_path /var/www/netboot/systemrescuecd
kernel http://${fog-ip}${path}/isolinux/rescue${arch} docache setkmap=us
initrd http://${fog-ip}${path}/isolinux/initram.igz
imgargs rescue${arch} initrd=initram.igz netboot=http://${fog-ip}${path}/sysrcd.dat setkmap=us dostartx
boot || goto start
I also wanted to replace DBAN with something that ran on UEFI, so this:
:dban
cpuid --ext 29 && set arch 64 || set arch 32
set path /netboot/systemrescuecd
set nfs_path /var/www/netboot/systemrescuecd
kernel http://${fog-ip}${path}/isolinux/rescue${arch} docache setkmap=us
initrd http://${fog-ip}${path}/isolinux/initram.igz
imgargs rescue${arch} initrd=initram.igz netboot=http://${fog-ip}${path}/sysrcd.dat setkmap=us ar_source=nfs://${fog-ip}:${nfs_path}/scripts
boot || goto start
Coupled with this autorun0 startup script:
#!/bin/bash
exec >& $(tty)
/usr/bin/nwipe
Makes SystemRescueCD operate like a more modern version of DBAN.
Hope this helps someone!
[MOD Note] Added code blocks for readability- George1421
I’m having the same trouble with 18.04. Was curious if you found a work around. Booting the ISO itself works fine, but PXE booting doesn’t work. My guess is that the network, obviously, has to start sooner in order to pull over the files via NFS, and this is somehow mucking up the traditional order of operations.
I only dug into the source a little bit, but I’ve noticed a couple problems with the way the LDAP plugin works. Initially I was trying to test removal of my account from the “Admin Group” but since I had logged in successfully while I was still a member of the group, I was still granted access to the dashboard. The error log reported that I should not have been allowed access, but I was still able to log in.
Additionally, after changing my password in Active Directory, I was still able to log in with my old password.
In either of these cases, removing access for a user who has previously logged in, would require manually removing their account from the database.