We’ve decided for now to just boot to Windows, and set the thing up so that we can test it “on the floor”. If it behaves like it should, we’re gonna buy some other ones to replace older devices currently in use. When we do that, I’ll have more time to play with capturing/deploying it so make our life easier 
So you guys have plenty of time to think about this weird piece of hardware, and I’ll get back to this thread when we have more devices to play with!
Thanks all for the help so far!!
@Sebastian-Roth said in another init.xz issue:
@bmaster001 said:
In that source you can see that the driver tries to get a MAC address from the EEPROM but if that fails, it generates a random one. I thought that it might help to know that it’s the driver who does this, and not some weird config option somewhere…
Great find! This is really unusual. Have never seen this before! Why would if not be able to read the MAC I wonder?!? Random MAC is kind of breaking the whole FOG logic of identifying hosts via MAC address.
Exactly. And I’m pretty sure there IS a mac address in the nic: when I enable uefi and let it network boot, I see always the same mac address. Would it be possible that it uses a different nic with uefi disabled?
@george1421 said in another init.xz issue:
[edit] note web will only be there when you are in capture/deploy menu mode not in the debug mode from the menu entry.
Ok, that explains why the $web variable doesn’t exist in debug-mode, and why the fog script doesn’t work then.
I understand this (linux) is a alien world to most windows folks. But you see there IS a lot of magic that goes into make FOG functional and universal.
You have the unfortunate situation of having very strange hardware (maybe one of a kind) that make imaging difficult to manage. FOG has a lot of instruments in the band, its takes a bit of cohering to get them to all play the same tune.
I do have some linux knowledge, and understanding some scripts would not cause too many problems. But it’s the (network)boot-process that I don’t know anything about. Like you say, trying to understand that, together with the fog scripts, and some weird hardware, makes the step too big. If I really want to learn how fog works, I’d better start with some normal hardware
It’s a difficult mechanism to understand. A lot of unfamiliar technologies, scripts and boot-arguments working together. It’ll take a while for me to better understand it. But it’s a very interesting subject!
The very first line in the fog script is the call to funcs.sh. when I run that on the command line, and do set, I see no web variable:
_=/usr/share/fog/lib/funcs.sh
acpi=off
boottype=usb
consoleblank=0
has_usb_nic=1
init=/sbin/init
isdebug=yes
ismajordebug=0
loglevel=7
name=has_usb_nic
oIFS='
'
ramdisk_size=127000
root=/dev/ram0
rootfstype=ext4
value=1
var=has_usb_nic=1
That seems to work! I’m now stuck on the ntfs inconsistency again 
that’s not fog’s fault… I’ll have to find a way to fix that too.
Before doing what you described, I took a loog at the contents of /bin/fog . It starts like this:
### If USB Boot device we need a way to get the kernel args properly
if [[ $boottype == usb && ! -z $web ]]; then
mac=$(getMACAddresses)
wget -q -O /tmp/hinfo.txt "http://${web}service/hostinfo.php?mac=$mac"
[[ -f /tmp/hinfo.txt ]] && . /tmp/hinfo.txt
fi $
The $web part seems to be a problem, because that variable doesn’t exist. So it skips the getMACAddresses-part…
@george1421 said in another init.xz issue:
@bmaster001 I saw the kernel driver, but not sure what you wanted to tell me. I assume the driver is built into the current FOS kernel otherwise you would not get an ip address.
In that source you can see that the driver tries to get a MAC address from the EEPROM but if that fails, it generates a random one. I thought that it might help to know that it’s the driver who does this, and not some weird config option somewhere…
Another thing that I’ve tried is to boot in debug mode, and manually add a host to the fog server with the random mac. Then schedule a capture task, and run ‘fog’ on the host. It fails with the “unknown request type :: Null” error. Maybe you know if there’s a way around that?
Thanks a lot for you help anyway, I’ve learned a lot! Let’s hope someone else with a deeper knowledge of this stuff is willing to look at this!
FYI: I’ll be on vacation from coming friday until the 3rd of july…
Whene I add that, it asks me to unplug and replug my device into the usb port and press enter. Can’t do that, so I just pressed enter
Anyway: the result is the same: another random mac address…
[Tue Jun 21 root@fogclient ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether a6:3a:48:bb:24:65 brd ff:ff:ff:ff:ff:ff
inet 10.1.14.75/16 brd 10.1.255.255 scope global eth0
valid_lft forever preferred_lft forever
Have you seen the link to some driver-source I posted above? http://lxr.free-electrons.com/source/drivers/net/usb/smsc95xx.c#L788
It’s not a usb-stick, but I think internally it’s a usb connection. Here’s the output for lsusb:
[Tue Jun 21 root@fogclient ~]# lsusb
Bus 001 Device 002: ID 8087:07e6
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 003: ID 0424:2517
Bus 001 Device 004: ID 0424:9514
Bus 001 Device 005: ID 0eef:0001
Bus 001 Device 007: ID 0c2e:0c80
Bus 001 Device 006: ID 0a12:0000
Bus 001 Device 009: ID 0572:141f
Bus 001 Device 008: ID 0424:ec00
Bus 001 Device 010: ID 058f:6387
Bus 001 Device 011: ID 046d:c31c
I went to http://www.linux-usb.org/usb.ids to lookup if it knows the devices, and the 0424:ec00 is a “SMSC9512/9514 Fast Ethernet Adapter”. Don’t know if that helps?
EDIT: dmesg also mentions this device and the mac:
smsc95xx 1-1.2.1:1.0 eth0: register 'smsc95xx' at usb-0000:00:1d.0-1.2.1, smsc95xx USB 2.0 Ethernet, ce:82:f1:bb:00:6c
EDIT2: Check out http://lxr.free-electrons.com/source/drivers/net/usb/smsc95xx.c#L788 …
oh, I thought that was a type, sorry for that. But it doesn’t help, the set command doesn’t give me anything mac-related:
[Tue Jun 21 root@fogclient ~]# set |grep mac
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor:posix
[Tue Jun 21 root@fogclient ~]#
And here is the lspci output:
[Tue Jun 21 root@fogclient ~]# lspci -m
00:00.0 "Host bridge" "Intel Corporation" "Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register" -r11 "Intel Corporation" "Device 7270"
00:02.0 "VGA compatible controller" "Intel Corporation" "Atom Processor Z36xxx/Z37xxx Series Graphics & Display" -r11 "Intel Corporation" "Device 7270"
00:13.0 "SATA controller" "Intel Corporation" "Atom Processor E3800 Series SATA AHCI Controller" -r11 -p01 "Intel Corporation" "Device 7270"
00:17.0 "SD Host controller" "Intel Corporation" "Atom Processor E3800 Series eMMC 4.5 Controller" -r11 -p01 "Intel Corporation" "Device 7270"
00:1a.0 "Encryption controller" "Intel Corporation" "Atom Processor Z36xxx/Z37xxx Series Trusted Execution Engine" -r11 "Intel Corporation" "Device 7270"
00:1b.0 "Audio device" "Intel Corporation" "Atom Processor Z36xxx/Z37xxx Series High Definition Audio Controller" -r11 "Intel Corporation" "Device 7270"
00:1c.0 "PCI bridge" "Intel Corporation" "Atom Processor E3800 Series PCI Express Root Port 1" -r11 "" ""
00:1c.1 "PCI bridge" "Intel Corporation" "Atom Processor E3800 Series PCI Express Root Port 2" -r11 "" ""
00:1c.2 "PCI bridge" "Intel Corporation" "Atom Processor E3800 Series PCI Express Root Port 3" -r11 "" ""
00:1c.3 "PCI bridge" "Intel Corporation" "Atom Processor E3800 Series PCI Express Root Port 4" -r11 "" ""
00:1d.0 "USB controller" "Intel Corporation" "Atom Processor Z36xxx/Z37xxx Series USB EHCI" -r11 -p20 "Intel Corporation" "Device 7270"
00:1f.0 "ISA bridge" "Intel Corporation" "Atom Processor Z36xxx/Z37xxx Series Power Control Unit" -r11 "Intel Corporation" "Device 7270"
00:1f.3 "SMBus" "Intel Corporation" "Atom Processor E3800 Series SMBus Controller" -r11 "Intel Corporation" "Device 7270"
02:00.0 "Network controller" "Qualcomm Atheros" "AR9580 Wireless Network Adapter" -r01 "Qualcomm Atheros" "Device 3123"
Thanks for the “secret”
First run:
[Tue Jun 21 root@fogclient ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 06:a7:78:e5:c9:ed brd ff:ff:ff:ff:ff:ff
inet 10.1.14.214/16 brd 10.1.255.255 scope global eth0
valid_lft forever preferred_lft forever
[Tue Jun 21 root@fogclient ~]# /usr/share/fog/lib/funcs.sh
[Tue Jun 21 root@fogclient ~]# set |grep mac
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor:posix
I think the funcs.sh script doesn’t output anything mac-address-related into a variable. I looked in the script, and saw that it runs /sbin/ip which returns basically the same info as ip add show or ifconfig.
Second run:
[Tue Jun 21 root@fogclient ~]# ip add show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 96:c1:60:13:b0:09 brd ff:ff:ff:ff:ff:ff
inet 10.1.14.248/16 brd 10.1.255.255 scope global eth0
valid_lft forever preferred_lft forever
Third run:
[Tue Jun 21 root@fogclient ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether ce:82:f1:bb:00:6c brd ff:ff:ff:ff:ff:ff
inet 10.1.14.190/16 brd 10.1.255.255 scope global eth0
valid_lft forever preferred_lft forever
I think this confirms what I already saw: the mac address changes on each reboot
Seems like the hardest part here was to explain what was wrong…
And fighting over who gets to fix something… that’s called motivation
See screenshots. First one is “before”, then I click on “Wake on lan” (the label, not the checkbox!), and I get the second situation (wake on lan still checked).
I’ve never used much of the more advanced fog-settings, so for me as a “new” user, this is a confusing UI.
As I understand it, the WOL-checkbox means that you want to “wake” the host by WOL, instead of having to power it up manually. Clicking on the label next to the checkbox should simply toggle the checkbox-value. That’s how it works everywhere in Windows at least (and that happens with the “schedule schutdown” and “schedule debug task” as well)
Not sure what you mean by your explanation Tom, sorry…
Don’t think so. When you check “wake on lan” by clicking on the checkbox, every other item stays the same. But when you click on the label “wake on lan”, the checkbox keeps the same state (checked/unchecked) but the other items dissapear.
In the “create capture task” or the “create deploy task”, when you click on the label next to the checkbox for “wake on lan”, a couple of the other items on the form dissapear. Same thing when checking the checkbox “schedule a task as a debug task” or clicking on that label itself.
(running trunk version 8169)
I didn’t build the img myself. But apparently the newer kernels seem to help me a lot
The inventory task didn’t work either so I had to create the host manually in the fog server, and I used the MAC address I saw during network boot for that. No idea where the other address comes from. It seems to work though, when I ping from another pc to this device, I see that same mac address in my ARP table. Very strange. EDIT: If you want me to do more tests with your image, just let me know, I have this device on my desk for a few more days
Next problem: there seems to a problem with the NTFS partition on the device, so the capture doesn’t start. I have to boot to windows and run “chkdsk /f”. Can’t do that of course, since I want to capture the image as it is
Quick registration and Full Host Registration still don’t work. After init.xz the screen goes black
memtest gives me “Exec format error”
So we’re not entirely there yet…
I already did a lookup for both addresses, and it’s the second one that’s strange because it couldn’t find a manufacturer:
00:40:fd:0a:41:a8 is the one I see when network-booting, which is LXE. That’s correct, because the manufacturer of this VM3 device was called LXE a few years ago
f6:c5:25:ec:b1:ff is the address I see when booting from the usb stick. No vendor can be found for this one… maybe it’s something virtual?
Ok, now I am very confused: