So last update from me. The device dump did get displayed now, nicely halting at EFI. Hope this gives a good insight into the problem. As i’m leaving my current job i’m handing this issue over to my boss. I explained the efi testing steps and he’s been following it for some time so he is up to date.
Thanks for all the help and support, its great to see dedication to an open project like this. I’ll be around on the forum still as i’ll keep using fog from now on personally.
@sebastian-roth Loaded up the image and took some pictures. i saw some devices being initalised so snapped that and the last line pushed to the screen. i don’t know if these where devices you where referencing too in the first lines of your post.
Now about the network trafic. Reading over your reasoning i agree and am afraid that the reality is very close to worse. Taking a quick look at the dump it is filled with retransmissions because of the “Frame check sequence” being incorrect (packet checksums don’t match). It seems that all the incorrect packets have a FCS of 0xd3600000 . I’m guessing its dropping the packets as from time to time the loading dump freezes for a decent amount of time.
I also spotted this at the end of a first partial dump i did. Could however not find the same again in the full capture. Probably the result from packet errors:
7zXZ Destination address too large XZ-compressed data is corrupt Bug in the XZ decompressor Destination physical address inappropriately aligned Destination virtual address inappropriately aligned XZ decompressor ran out of memory Input is not in the XZ format (wrong magic bytes) Input was encoded with settings that are not supported by this XZ decoder Kernel is not a valid ELF file Failed to allocate space for phdrs Avoiding potentially unsafe overlapping memcpy()!
-- System halted EL64 EL32 Failed to handle fs_proto
Failed to open volume
initrd= Failed to alloc mem for rom
Failed to read rom->vendor
Failed to read rom->devid
Failed to alloc mem for gdt
efi_main() failed!
exit_boot() failed!
Failed to get handle for LOADED_IMAGE_PROTOCOL
Failed to alloc lowmem for boot params
Trying to load files to higher address
Failed to alloc mem for pci_handle
Failed to alloc mem for gdt structure
efi_relocate_kernel() failed!
efi= nochunk Failed to open file: Failed to get file info size
Failed to get initrd info
EFI stub: ERROR: Failed to alloc mem for file handle list
Failed to alloc mem for file info
EFI stub: ERROR: Failed to alloc highmem for files
EFI stub: ERROR: We've run out of free low memory
EFI stub: ERROR: Failed to read file
EFI stub: ERROR: Failed to allocate usable memory for kernel.
EFI stub: UEFI Secure Boot is enabled.
EFI stub: ERROR: Could not determine UEFI Secure Boot status.
@sebastian-roth Running 06_ipxe did not produce a different output to number 5 at first glance.
However 07_ipxe did trow out something else. It hung this time on removing devices. I’m guessing this is because of bad handover from the bootloader to the kernel ?
Not ugly imho, pretty cool to see the packets flow by
@sebastian-roth I loaded up the image and let it run for a bit (it took a while as it had to dump all the tcp handshakes). I let the laptop stay on for a while after this but nothing further happened.
@sebastian-roth Ah yes, this is because i was using an already in place thunderbolt-dock, but had to fetch a new one as it was needed. The machine is still the same however.
So now this is the last message i get
@sebastian-roth So update ! The new bootloader shows some more info and boots nicely to the menu. Problem right now is that the debug info goes a little quick. I got some footage with a camera but the 30fps limit doesn’t help, so i winged it with some burst mode pictures. Tomorrow i’ll capture the HDMI output straight to get more acurate info. Is there any way to make it dump the output to the file system its running on ?
Also i totally understand the iteration issue. I’ll be here to test !
This is as much info as i could get out of the footage.
This after selecting “Client System Information” as a test
Also on a side note i did not realise that pictures could be uploaded and inserted this way. I’ve replaced the ones in the previous posts
@sebastian-roth Yep they do have a nice onboard NIC but as you also correctly noted they need a special adapter to break out the connector to be actually usable (100% crap imho). But as we got a bunch of the lenovo hubs for this device we would love to be able to use that one so no extra desk diving and replugging needs to happen.
Anyway this is the result after booting the new bootloader,
@sebastian-roth So, i followed the suggested steps and here are my results.
Booting with the EFI fog stick with debug enabled gave some more information, though i’m sure it will say more for you then me.
I pulled verbose lists of both the usb and pci devices and attached them below.
As far as i see the hub is under the 0x17ef vendor-id.
http://www.mediafire.com/file/dh153eh6ar3o391/lsusb.txt
http://www.mediafire.com/file/n7s11lvpz7v27cc/lspci.txt
Apologies for my late reply on the problem.
@Sebastian-Roth we are 100% focused on organizing a conference atm so i have not had time for this issue. Begining to end of August however i will have full dedication to this.
@george1421 I tried out your guide and got the yoga to boot fog from the usb stick under efi but the result is still the same once it loads the actual task (the pxe menu itself works fine). Any futher steps i can take to enable more debugging ?