Dell Venue 8 Pro imaging/eMMC



  • I’ve been a long time user of FOG and although I got EFI and etc to work nicely, I have now run into a bit of a brick wall on imaging devices with eMMC instead of SSD.

    I just received a lot of Venue 8 Pros and I cannot get FOG to recognize the storage in them because it uses eMMC. I am using kernel 4.1.6 from TomElliot and the Venue 8 Pro can PXE boot just fine up to the point where you try to get it to image and it will say no disk found OR run diagnostics and it says there is no disk.

    Running diagnostics, I see a lot of /dev/ram0-14 but don’t see anything starting with mmc. Is there some modification needed to the kernel itself or to initrd or similar?

    Unfortunately in this instance, I have no handle on the purchase or choice of this particular set of devices.


  • Moderator

    @AsGF2MX said:

    I actually didn’t have to use the has usb nic parameter for any unit. I used the USB-0301 as mentioned earlier and it didn’t complain on any of the units I had imaged with FOG.

    Wow… who would have thought? Wonder why it worked?

    I’ll be adding your isc-dhcp configuration to our WiKi sometime today, to the BIOS & UEFI coexistence article here: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence



  • @Uncle-Frank Apologies for going AWOL…cleaned up the deployment and held back one unit for testing purposes and took a brief break to recover.

    The efi files and ipxe files are straight from the SVN with no modifications. I only took the stock isc dhcpd.conf file and modified the items right after max-lease time as below:

        default-lease-time 21600;
        max-lease-time 43200;
        #       option domain-name-servers      x.x.x.x;
        #       option routers      x.x.x.x;
    
        class "UEFI-32-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006";
        filename "i386-efi/ipxe.efi";
        }
    
        class "UEFI-32-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002";
         filename "i386-efi/ipxe.efi";
        }
    
        class "UEFI-64-1" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007";
         filename "ipxe.efi";
        }
    
        class "UEFI-64-2" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008";
        filename "ipxe.efi";
        }
    
        class "UEFI-64-3" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009";
         filename "ipxe.efi";
        }
    
        class "Legacy" {
        match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
        filename "undionly.kkpxe";
        }
    
        } <<< This one is the wrapping brace for the subnet x.x.x. netmask .x.x.x.x { at the beginning
    

    @Wayne-Workman

    Host Kernel: 4.2 x32 Sept 17 straight from FOG no mods
    Host Primary disk: /dev/mmcblk0
    Image type: Multi partition single disk (only one that works for me so far as I can’t build my own image due to the vendor’s preload)
    bzImage32 - SVN 4586
    init_32.xz: SVN 4586

    In my fog configuration options (this is on a test box):

    • I have specified bzImage file name as bzImage32
    • I have also specified init.xz as init_32.xz

    So far I’m using 32-bit for the Venue 8 and also other hardware I have and it works for me - we use mostly Dell gear with a dash of Lenovo in the mix.

    I actually didn’t have to use the has usb nic parameter for any unit. I used the USB-0301 as mentioned earlier and it didn’t complain on any of the units I had imaged with FOG.



  • Good news, Single Disk (Resizable) uploads and deploys normally.

    The problem was with my automated .xml I use with WDS. I had to manually set the partition types/sizes in the .xml and apparently FOG didn’t like something I had set.

    Anyway, I turned off the automated setting, re-deployed to my image station, wiped out all partitions and let Windows automatically create the partitions. Once that was done I re-uploaded without issue. Then I deployed without issue :)

    After this deploys I’m gonna try the newer init_32.xz, I have a feeling it will be fine now :)



  • @Tom-Elliott Will do…I was shocked that I was able to upload the image but had issues deploying it. When the init_32.xz from SVN 3504 worked I was even more baffled.

    Now all we need is a Secure Boot signed set of iPXE .efi bootfiles!



  • @Wayne-Workman

    Host:

    Host Kernel: 4.2.0-x32

    Host Primary Disk: /dev/mmcblk0

    Image:

    Image Type: Your choice :)

    Links (for anyone who wants them):

    bzImage32: 4.2.0 (x86) https://mega.nz/#!sQZFTCaY!aw23zMF9uY2g4Ep0W5kJP2sdrknshlGfrNR7mDCvgoY
    Init_32.xz: SVN 3504 https://mega.nz/#!JEgWgCxa!KbTTSswOX4havJ4nb6b3UX25REZ3TWZg9BXL3_Q67Vw


  • Senior Developer

    @d4rk3 If you figure anything out with whats wrong, please let me know. I do want to make sure the current init works in the same way the old client worked, or at least as close to it as possible.


  • Moderator

    @AsGF2MX @d4rk3 @Tom-Elliott @Uncle-Frank

    I’ve added the Venu 8 to the working hardware list. https://wiki.fogproject.org/wiki/index.php/WorkingDevices

    However - I need to know exactly what kernel you were using and exactly what boot file. I need to know the original /path/name, not the names you changed them to.

    Also, again, great work on this. I’m just trying to consolidate the important information here into our working hardware list so that others can just refer to that for what to do… instead of reading this gigantic thread lol.

    and also, the “has usb nic” parameter was used obviously?



  • @AsGF2MX Ok, I uploaded my image as Single Disk - Multiple Partitions and it still wouldn’t deploy. I then tried my oldest init_32.xz (SVN 3504) and it works.

    Nope, I still use the 64-bit .efi files for these larger Asus EFI tablets we have.

    On Monday I’m gonna experiment some more…I’m confident that with the right init_32.xz Single Disk - Resizable can work.


  • Senior Developer

    @AsGF2MX I already build 32 bit ipxe Efi files in case you all need them.


  • Developer

    @AsGF2MX said:

    Also I modified the DHCP (DHCPd) to just hand out different ipxe files (no modification) with a priority for 32bit followed by 64 bit then undi. So far most clients will just run fine with 32bit .

    Would you mind telling me how you do this? Is it done with isc-dhcpd? Maybe send a personal message to me to not flood this thread even further.



  • @d4rk3 One suggestion. Could you try to apply the ram disk patch and see if it works for you? I have had no luck pulling the image in resizable form with this.

    Having said that I never seem to be able to get the rom o matic site to let me download anything after all the options are ticked. Tried IE and FF and off various links including direct to Internet public IP.

    Also I modified the DHCP (DHCPd) to just hand out different ipxe files (no modification) with a priority for 32bit followed by 64 bit then undi. So far most clients will just run fine with 32bit .

    Does your modification end up rendering the 64bit ipxe unused as well?



  • @AsGF2MX Ok, so I spoke too soon. I can’t deploy my resizable image, it seems to be a mount issue on the client.

    I’m re-deploying my WDS image, then I’ll upload it as Single Disk - Multiple Partitions and see if that helps.

    My init_32.xz is dated 09/18/2015 (SVN 4700).

    Also, there’s a much easier way to handle these 32-bit EFI devices…

    Go to: https://rom-o-matic.eu

    Choose Advanced, for experienced users

    Choose EFI PXE bootstrap 32-bit (.efi)

    Check these boxes:

    CPUID_SETTINGS
    IMAGE_PNG
    PARAM_CMD
    CONSOLE_CMD

    Lastly, paste this in the embedded script box at the bottom:

    #!ipxe

    dhcp
    cpuid --ext 29 && set arch i386
    params
    param mac0 ${net0/mac}
    param arch ${arch}
    param product ${product}
    param manufacturer ${product}
    param ipxever ${version}
    param filename ${filename}
    isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
    isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
    :bootme
    chain http://FOG-IP-or-Hostname/fog/service/ipxe/boot.php##params

    (obviously replacing FOG-IP-or-Hostname with your FOG server’s IP or hostname)

    Click Proceed and save that EFI file, I usually call mine ipxe-x32.efi.

    Copy it to /tftpboot and set your DHCP server to use ipxe-x32.efi for 32-bit EFI clients and you won’t have to mess with them ever again!

    I’d recommend keeping a few copies of that 32-bit .efi bootfile you made so you don’t have to re-make it in the future.

    Also, if you regularly update to the latest SVN/Git…in the root of either SVN/Git directory, copy the 32-bit .efi bootfile into /packages/tftp and the file will always end up in the new /tftpboot directory whenever you update :)



  • @Wayne-Workman And yes, you are correct regarding the fixed size with a resizable image.

    This is just nice because I can stay with Single Disk - Resizable exclusively for all of my images.



  • @AsGF2MX I didn’t have much time yesterday to tinker but I simply uploaded all four image types, starting with raw and working my way up. Once I saw the upload working I forced the tablet off and tried the next image type until I finished with Single Disk - Resizable.

    I’m actually gonna deploy my WDS image I’ve been using for these onto my image tablet and upload it to FOG before the OOBE can commence. I’ll report any findings…



  • @Tom-Elliott No need to apologize brother! Thanks again to you and everyone who helped get these working :)



  • @Wayne-Workman On the same lot of equipment, most definitely no reason. But from time to time things break and sometimes we get newer items with smaller storage or the same item with larger storage so I normally do use resizable.

    At the moment, I’ve ended up with a few golden images that we can deploy to a variety of hardware.


  • Moderator

    @AsGF2MX A better question is why would you use resizeable on a device that has a fixed amount of storage.



  • @Tom-Elliott 64-bit didn’t work for me at all before - I will retest the latest build once more and see if there is a difference. I am currently running FOG with both the bzImage and init set to point to the 32-bit variant in FOG Configuration. I will hold back one unit from this lot for “testing” purposes so if you need me to test anything to fine tune things, I can help.

    Also @d4rk3 how did you get single disk - resizable to work? I am still seeing errors. With the little patch on the ramdisk I applied, I can get further but not to the point I can image.

    My init_32.xz is dated Aug 31 12:01 what is the date on yours?

    @Uncle-Frank I think the patches have made Tom’s build a bit smoother than mine without the patches. Less chatter in front when it loads up. However I can confirm without any patches it works as well. I’m happy to help test any variants if you wish.


  • Senior Developer

    @d4rk3 I’m sorry it has taken sooooo long man. I know we have been trying for a while. Thank you all in this thread.


Log in to reply
 

405
Online

39.3k
Users

11.0k
Topics

104.6k
Posts

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