@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.
Checking our script code again and again I found out what’s causing this!! Lately we re-worked the code on enumerating the partitions on disk(s). In earlier revisions a self written tool called fogpartinfo was used. This has caused some trouble (for example on brand new empty hard disks). So we decided to get rid of it and use well known linux commands to get the partition information. This is a lot more flexible but we are still in the process of getting it fail proof in all cases. But turns out that we haven’t been aware of “Multiple Partition Image - All Disks” being a bit more tricky.
Please download init.xz/init_32.xz from here https://drive.google.com/folderview?id=0B-bOeHjoUmyMazJLZDhGaEl5VTQ&usp=sharing and put into place in /var/www/fog/service/ipxe/ or /var/www/html/fog/service/ipxe/ (probably a good idea to rename the original files instead of just overwriting them!)
Please test and report back if capturing is working properly again.
@Wayne-Workman said:
When would the upload process choose RAW when the image type is not set as RAW?
The scripts collect filesystem information to be able to run the correct partclone command which corresponds/is aware of the filesystem on each particular partition. sdb has no filesystem and is cloned RAW because of that.
@foglalt said in Disappearing hosts from host list:
task was deploying and DURING that task the host data was updated with new mac address (i am aware that it is not best usage
it was not me)
This is probably the key here, right?!
@sgennadi said:
undionly.kkpxe or ipxe.efi don’t work
realtek.kpxe work
This is strange! Do you really see this when using undionly.kkpxe (BIOS/legacy) and ipxe.efi (EFI enabled)?? And with realtek.kpxe you get the FOG menu?
I really wonder why loading default.ipxe via TFTP would work but getting boot.php via HTTP does not! Please try to access http://192.114.111.1/fog/service/ipxe/boot.php from a browser and see what you get! Maybe this is a firewall thing?
@robertkwild Check out our wiki, there we have an article called password central…
@Toby777 Could you please run a debug session on this device (WebGUI -> Host -> Basic tasks -> Debug) and run lsblk. What do you get?
Are you sure it said /dev/nvme0n1 when trying single disk resizable?? Asking because this would be the whole disk instead of the first partition. In RAW mode nvme0n1 is fine.
@Qweeqweg Just to add to what has been said already, this account should not be used to login and work on your machine. It’s used by FOG itself and should be left alone!
Sounds like you’ve done a good job migrating to the new server. So to figure out what’s wrong we best should have a picture of the error message you see!
@Wayne-Workman Sorry this has been without attention for a long time! Not only this topic but all the others:
https://forums.fogproject.org/topic/11868/how-to-change-colors-on-bandwidth-graph
https://forums.fogproject.org/topic/11999/bandwidth-line-colours
https://forums.fogproject.org/topic/6912/can-i-change-the-colors-of-the-tx-rx-graph
I played with the things mentioned in the other topics and figured that it seems to pick colors just by itself if we don’t force it to use our colors. When I remove the color scheme as described I get the following picture:
Please vote if you find this appropriate. Sure the more nodes you have the less obvious distinct colors there are. But from it’s still better than using a successive shade of whatever color you start from.
I’ve tested this in three different browsers on a Linux machine. I would imagine this working nicely on Windows and Mac OS browsers as well. What do you think @Tom-Elliott?
To find out what version a particular kernel image is you don’t need to boot it up. Just use the file command:
file /var/www/fog/service/ipxe/bzImage
Linux kernel x86 boot executable bzImage, version 4.3.2 (root@debian64) #1 SMP Sun Dec 13 17:56:05 EST 2015, RO-rootFS, swap_dev 0x6, Normal VGA
And yes you are right. By putting the kernel/init files into the right place (as in Tom’s post) those will be active and clients will load those when booting up.
@arnaudrigole As I already explained things usually should go like this: PC boots, NIC sends PXE DHCP discovery and gets back PXE information (next-server and filename). Then it loads the file via TFTP and executes it. FOG uses iPXE as a second stage. So far so good. From what I can see in the PCAP file this is perfectly happening for you. Cannot see any issues there. But then I see four DHCP requests from iPXE (which was loaded and executed as a first stage). But there is NO response from the DHCP server.
Either the DHCP server does not like the DHCP request (maybe some DHCP option that iPXE is sending) but I kind of doubt this as others seam to be able to use windows DHCP server without a problem.
Or it could be because of spanning tree (STP). The NIC is reset a couple of times while this PXE process is going on. If your switch has STP enabled but port fast is not used this might cause exactly the issue you see: https://wiki.fogproject.org/wiki/index.php/STP/Portfast/RSTP/FMSTP
@Jurgen-Goedbloed said in Improve documentation:
If you agree, then let me assemble the first pages. The wiki provides lots of information that is very usable, so that’s just copy/paste and reformat.
Sounds great to me!
From a practical point of view I will organize for you to have write/push access to the fog-docs repo - and everyone else who is keen to work on this (please send me a PM). Sure there is another way by forking that repo to your own account and sending in pull requests but that adds extra work for you and us and I don’t think that’s apropriate.
@sarge_212 Well then, could you please add has_usb_nic=1 to the host’s kernel parameter and try PXE booting with the dock again?
@JJ-Fullmer Probably you’ll find a fair amount of those kind of topics in the wiki. I’d hope this is a good chance to get rid of some dated stuff as well. The one you mentioned about samba is 10 years old, talking about Ubuntu 10.04 (!) and I am not sure if people really have those kind of setups. Anyone an idea?
@Eldorado Try using this as embedded script:
#!ipxe
dhcp
chain tftp://ip.of.fog.server/default.ipxe
By the way, you don’t need to burn CD/DVDs every time you change iPXE. You can generate iPXE image to write onto USB key…
@Bristow-0 This wiki article definitely needs some re-work. Thanks for letting us know. Thanks to @JJ-Fullmer and @Jurgen-Goedbloed we started to improve documentation and I think this article is being part of it.
From what I see in the current wiki article I would think the command mv /images/dev/* /images did not take into account that dev/ subdirectory would exist on the old server already… Maybe @Wayne-Workman can remember more of the details.
@Scott-Adams said:
not sure what is different as I have not changed anything, but at least it works now. Thanks!
I really hope that this will not hit back again in a unsuitable moment. Keep us posted if you see this again.
@Deimos Ubuntu 16.04 is end of life and we don’t care to make FOG work with it anymore. The other way round, FOG 1.5.5 is years old as well and we can’t support such an older version to be installed.
Just go with Ubuntu 20.04 and FOG 1.5.9 and you should be fine.
Just found an interesting filter I didn’t know about yet: tcpdump -ee "ether[0:4] == 0x000f234c" (the bytes you are “grepping” for must be of length 1, 2 or 4 - so you can do “ether[0:1]” and “ether[2:2]” but you can’t do “ether[0:3]”)
Having a closer look at the MAC addresses I noticed the last byte being “00” on one of them. Then I remembered that every port usually has its own MAC on Cisco switches. “00” being the switch itself, “01” the first port and so on. You don’t usually see the switch MACs in IP communications as there will only be the MACs of source and destination in those packets (switches are transparent in that respect). But switches do send out traffic as well, like BPDU for spanning tree and stuff like that.
Using similar filters (eth.addr[0:4] contains 00:22:56:01) on that wireshark dump I found that 00:22:56:01:4e:44 has a “partner” with MAC 00:22:56:01:4e:02 (notice the change in the last byte) which sends out spanning tree messages (BPDUs) on a regular basis. Looking at those BPDUs I see “Bridge Identifier: 00:22:56:01:4e:00”. Does your network team know about this MAC/switch (“Root bridge: 00:0d:65:51:80:80” - if that’s of any help for them)???
http://www.ciscozine.com/how-to-trace-mac-address/ seams interesting in case they wanna trace the MAC.