Dell Venue 8 Pro imaging/eMMC

[Tom Elliott]

I’ve, once again, updated the kernels. I followed the information from the patch. I just basically made a replica.

Please try them when you can and keep us informed.

[AsGF2MX]

@Jbob Thank you but honestly I have all of you to thank - especially Tom with my obscure and off beat recompile requests! Haven’t had a dev box (VM or otherwise) since 2008 so I’m a bit rusty but I’m glad I can contribute back to the project in some way.

@Tom-Elliott I have not had a chance to test your kernel yet or finish up on @Uncle-Frank 's request as I had to step out for a few moments and I had triggered a download before I read the message. The good news is the upload succeeded!

Will check to see the OS made it back in a sane state and if it’s good, I will test your kernel right after.

[AsGF2MX]

@Tom-Elliott The upload and download on my compiled kernel worked - not so much as a hint of something being wrong. Everything works! Currently testing the kernel that you just uploaded and promising so far on upload. I think the unit has just enough battery to go through a download before it shuts off.

One point of note I should mention (in case someone comes across this post while looking for Venues and PXE booting) is that I am using Level One’s USB-301 Fast Ethernet adapter. I have both the AXIS (died after the first post!) and Realtek variants but all screenshots I’ve posted in this thread are using the Realtek variant.

[Wayne Workman]

@AsGF2MX

What’s the exact model of the adapter? And what boot file are you using?

[AsGF2MX]

@Wayne-Workman Adapter is Level 1 USB-0301 v4 http://global.level1.com/Network-Card/USB-0301/p-3285.htm which uses a Realtek chip. The v3 used the AXIS chip which Dell puts in its docks.

I’m using the 32-bit ipxe and bzImage32 as well.

@Tom-Elliott Your kernel worked flawlessly. Downloaded and uploaded perfectly and managed to check everything just before the battery hit 0%.

@Uncle-Frank It will be a little while before I can test the changes you requested.

[Sebastian Roth]

@AsGF2MX said:

@Uncle-Frank It will be a little while before I can test the changes you requested.

Not sure if we really need any of those if everything seams to work for you now! Awesome…

The only thing still in question (as far as I can remember) is the kernel patch (https://dev-nell.com/rpmb-emmc-errors-under-linux.html). Might be all good without this… Unfortunatelly I can’t test this. All up to you. But I don’t see a need to test this if things seam to work for you!

[Tom Elliott]

@Uncle-Frank He was running my kernels too, and I did have that patch in there just for this reasoning.

OP, did the 64bit kernel work for you out of the box, or only the 32 bit?

[d4rk3]

IT WORKS!!! You guys are amazing!

I did have to set Host Primary Disk to /dev/mmcblk0 but that was it

Single Disk - Resizable works!

[Wayne Workman]

So much happiness in this thread, I can’t take anymore! Stop it! lol

[Tom Elliott]

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

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