another init.xz issue



  • I’m having an issue that’s likely closely related to this one: https://forums.fogproject.org/topic/6105/init-xz-issue

    History:

    • fog 1.20 on Ubuntu 12.04 (which served us well for a couple of years now)
    • a “special” computer arrived this week that we need to image: a Thor VM3 (https://www.honeywellaidc.com/en-US/Pages/Product.aspx?category=vehicle-mount-computers&cat=HSM&pid=thorvm3)
    • Since this uses uefi, it doesn’t work with fog 1.20. So I upgraded to the trunk version, hoping this would fix all my issues
    • it boots to the fog menu, but when I choose the quick registration task, the machine hangs on “init.xz … ok” (no reboot, it just hangs there).
    • memtest doesn’t work either: it says “memdisk… ok” followed by “Could not select: Exec format error” and “Could not boot: Exec format error”
    • I read in this topic that installing fog on a fresh Centos 6.7 helped for @bjmarowitz. I tried that today, but it behaves the exact same way in our situation here :-(

    Our dhcp options are correct I think. We use pfsense, and I have the following settings:

    • next-server: ip address of fog server
    • default bios filename: undionly.kpxe
    • UEFI 32bit filename: i386-efi/ipxe.efi
    • UEFI 64bit filename: ipxe.efi

    PS: Last attempt was with trunk version 8099 (or is it the SVN revision 5678 that is important? I’m confused :-) )

    Any help is very welcome! Thanks!


  • Developer

    @bmaster001 said:

    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!

    I don’t think we are able to push this anywhere without having the hardware around or someone like you who are willing to test things out.



  • 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!!


  • Developer

    @bmaster001 said:

    Would it be possible that it uses a different nic with uefi disabled?

    Can’t imagine that being the case. Well on the other hand I’ve never seen a driver generating a random MAC for a real hardware NIC… :-D So what do I know!

    lol, just found this. Seems like the driver used to generate a new random MAC even on ifup/ifdown. Along that I found something interesting in the kernel code. See here (line 771):

    /* maybe the boot loader passed the MAC address in devicetree */

    Here you find a description of what that of_get_mac_address function does. I wasn’t able to find out if you can actually set this via iPXE or as a kernel parameter. Anyone an idea?



  • @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 :-)


  • Developer

    @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.


  • Moderator

    @bmaster001 said in another init.xz issue:

    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!

    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.


  • Moderator

    @bmaster001 hey that’s cool (not).

    Lets confirm that your grub.cfg has this line.

    menuentry "1. FOG Image Deploy/Capture" {
     echo loading the kernel
     linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4 isdebug=yes
     echo loading the virtual hard drive
     initrd $myinits
     echo booting kernel...
    }
    

    Note the kerenel parameter web=$myfogip/fog/

    [edit] note web will only be there when you are in capture/deploy menu mode not in the debug mode from the menu entry.



  • 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
    

  • Moderator

    @bmaster001 When you enter in debug mode none of the fog scripts have run. So the $web won’t be set until . /usr/share/fog/lib/funcs.sh has been called. I know it is confusing, but I ran into the same issue when developing the code snippet you posted.

    $web should point to your fog server when its set. Actually <fog_server_ip>/fog (this comes from the kernel parameter in the GRUB config file). The funcs.sh script extracts the kernel parameters and then sets the bash variables to match the kernel parameters. Then my code calls the fog server to pick up the other dynamic kernel parameters than can’t be supplied by the static grub.cfg file. That is where the hostinfo.php comes in. The type variable is set by the hostinfo.php script, fwiw.



  • 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…


  • Moderator

    @bmaster001 Gotcha on the drive. I did not read it line for line. (that is a silly feature)

    As for your hack around this. If you look in grub for the debug entry, there is a kernel parameter isdebug=yes If you copy and paste that onto the end of the capture / deploy line. Your capture deploy entry will be in debug mode. Do that boot, and then try your trick of updating the mac address in fog, schedule a capture/deploy. Then on the FOS console key in fog. That might just work.



  • @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…


  • Moderator

    @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.

    I think we need to get the kernel developers to look at this issue. They may need to check to see if the current kernel supports this specific nic or one that is close. The device (hex) ID you provided below will help. I think I’m at the end of my ability to debug this @Developers ??



  • 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


  • Senior Developer

    @george1421 has_usb_nic=1


  • Moderator

    @bmaster001 It would be intersting to note, if the dmsg changed on each boot. More precisely the MAC address of the smsc controller.

    Since that is a usb nic (in the dock) there is a kernel parameter that you could add to the grub menu to tell the kernel there is a usb nic involved. I can’t remember if that was posted here. I’m going to look back at the thread and see if its here.

    Yes it was posted below has_usb_nic=1 Make sure that is on the line for debug and capture / deploy. Not sure if that will help or not. We may have to get one of the developers to look at this thread now that we know what ethernet adapter is in play.



  • 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


  • Moderator

    @bmaster001 Interesting, I don’t see the ethernet adapter only wireless.

    Wait, are you using a usb ethernet adapter? That may explain why lspci (look for built in hardware) is not showing the ethernet adapter. But that still doesn’t explain why it is creating a random mac address.


Log in to reply
 

393
Online

38729
Users

10555
Topics

99942
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.