@AlexPDX said in Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify:
…can someone please help me with the correct steps to update fron 1.5.9 to 1.5.10 ?
Sorry for the late reply. From the logs it looks like it just bailed out when trying to create a symlink to the log files. I have never seen this happen before. Please issue the command rm -rf /var/log/fog (as root) and then re-run the installer.
@brakcounty said in ipxe boot slow after changing to HTTPS:
Assuming you’re booting legacy pxe instead of UEFI, since UEFI PXE boot on Vbox requires the Paravirtualized Network Adapter (virtio) adapter
Yes, legacy. Because I never got UEFI PXE booting to work in vbox on Linux.
@Flyer The read error is misleading. The FOS scripts spin up a FIFO to uncompress the image data on the fly for partclone to write on disk. So a read error means the FIFO died. Mostly this is caused due to a corrupted image (not in your case as it deploys well to another machine) or faulty hardware - usually RAM - in the client machine.
@brakcounty I still have not found enough time to do a test setup…
Out of curiosity, what NICs do you typically run ipxe on?
The default on Linux virtualbox: Intel PRO/1000 MT Desktop (82540EM)
@george1421 said in using deploy image via pxe with more than two nics:
specifically around this line https://github.com/FOGProject/fos/blob/e3e7e93cc249a92b512862f308481f1ee055740d/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L63 mode needs to be quickimage for “image deploy”
I guess you found a old bug thas has been in the code for a very long time. There really is no script called fog.quickimage in the FOS inits. Should be in /bin/ but there is non. So to me it seems like when the quickimage case is called it’s just ignored and fog.sysinfo is called.
The name was even updated in the schema at some point: https://github.com/FOGProject/fogproject/blob/65fe719e58f89398a1e3f45412d7305993eb282e/packages/web/commons/schema.php#L3315
@JJ-Fullmer said:
I tested this in a VM and recreated the problem. It didn’t matter if 1 or all adapters were connected, if 3+ exist on an unregistered host it behaves as @mosi describes.
What kind of virtualization do you use? I was not able to reproduce this on virtualbox yet. Seems like I am doing something wrong because when I get to an iPXE shell and let ifstat list the network interfaces I only see net0.
EDIT: Ok, got me. When using the default iPXE binary undionly.kkpxe this is not happening because it seems to only detect one network interface. Switching to ipxe.pxe brings up the same issue for me. What I noticed is that when you are asked to enter username and passwort to authenticate before the image deploy you submit with ENTER but get back to the same password dialog again with the information entered already. So hitting ENTER once again finally gets you past the authentication screen?!?!
EDIT2: Same problem when trying to join a multicast session on a VM with three NICs. Two NICs does not cause the trouble for deploy or multicast. Moving this to bug reports.
@Kleber I guess the spacing of the information printed is not working as intended when the status bar is just started. I played with the stuff a bit and came up with an easy solution that would expand the text information to the whole width but restrict the green status bar to the lower part:
Would that be a feasible option? If not then some else with more status bar skill needs to look into this.
@AlexPDX @george1421 @Tom-Elliott Great we got this figured out. Please let us discuss the details on github: https://github.com/FOGProject/fos/issues/72
@AlexPDX said in Host Hardware Inventory - Hard Disk Model - M.2 Nvme not identify:
HDIO_GET_IDENTITY failed: Inappropriate ioctl for device
Yes, surely we need to use a different command to get that information, e.g. nvme id-ctrl /dev/nvme0n1 | grep mn or smartctl --info /dev/nvme0n1 | grep Model (https://sleeplessbeastie.eu/2022/03/21/how-to-display-information-about-nvme-storage-device/)
@ricardomartins Does this happen with all your client machines or just particular ones?
What is serving DHCP in your network?
@plegrand Good you are asking. Going forward is always supported. So in your particular case coming from commit ddb9904a7 (version 1.5.9.111) you can safely switch to the master branch and then follow the known update commands:
cd /path/to/fogproject
git checkout master
git pull
# Make sure this succeeds as it can fail when you have made changes to the repo files,
# e.g. compiled ipxe binaries. If this fails, then you can drop all modifications using "git reset --hard HEAD"
cd bin
./installfog.sh
@Tom-Elliott said:
dmidecode (which I believe is what pulls all the inventory data) might just not know how to detect the specific information from that NVME either because the manufacture didn’t fill out the items that dmidecode is looking for, or is using a different language that can’t be utf decoded.
Pretty sure Tom is right here. Just had a quick look at the scripts and turns out we use hdparm (code ref) which might not be able to grab the information from NVMe disks per se.
@george1421 said:
the nbdX devices have me confused.
You are right. I am wondering if we added this kernel feature when updating to a newer LTS line at some point. I don’t think we need it. Though it’s always good to make sure. So here is the github commit that introduced those features years ago when we moved from 4.5.x to kernel 4.7.x: https://github.com/FOGProject/fos/commit/b56b8d9f6356f6e702e6ff580b2c4500f27ac41f#diff-15f9b0e5270fc1caac75f8b936c3df11534ceeb08de376b7a72b38c75ff2ad1aL1122
@Tom-Elliott Do you remember if this was added for a reason? Not saying this is an issue at all. Just wondering if we might think about removing it to further slim down the kernel binaries?
@jmcnamee Please let us know if you need futher help with this.
@Romain-0 Please let us know if you need further help on this topic.
Veuillez nous faire savoir si vous avez besoin d’aide supplémentaire sur ce sujet.
@Jim-Holcomb Please share more details.
@RTOadmin Do you still need further assistance on this topic?
@dugi007 Did you get this solved? Do you still need further help on this?
@Chris-Whiteley This is known and fixed in the latest version - really latest dev-branch as well as the latest official release 1.5.10 that came out a few days ago.
@mosi said in using deploy image via pxe with more than two nics:
I’ve got a Server with 3 NIC’s
Can you explain why you setup FOG this way in the first place? It’s not an officially supported setup.
@AlexPDX Please wait before you update. Maybe I got this the wrong way. It’s just the inventory information missing in the FOG web UI??