Dell Venue 8 Pro imaging/eMMC

[AsGF2MX]

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

[Wayne Workman]

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

[AsGF2MX]

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

[d4rk3]

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

[d4rk3]

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

[d4rk3]

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

[d4rk3]

@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

[AsGF2MX]

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

[Sebastian Roth]

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

[Tom Elliott]

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

[d4rk3]

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

[Wayne Workman]

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

[Tom Elliott]

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

[d4rk3]

@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

[d4rk3]

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

[d4rk3]

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

[AsGF2MX]

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

[Wayne Workman]

@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