HP Stream 11 pro

[Wayne Workman]

@drc0nc I’m not asking you to update. it’s fine to leave it as is. I was asking you try with a different HP to see whether or not it’s an issue with that specific HP or some larger issue.

[drc0nc]

@Wayne-Workman lol i didn’t mean it like that.
I’ve just tried 2 other HP’s and different adapters. Same deal… If i do RAW then it’ll work to capture and deploy. Otherwise it’ll give me the The protective MBR's 0xEE partition is oversized! Auto-repairing. then proceed to reboot.

[Wayne Workman]

@drc0nc What are you using for DHCP in that building you’re in?

[drc0nc]

@Wayne-Workman a windows server 2012 r2. options 66 and 67 are set to the appropriate ip and option 67 is ipxe.efi on global and scope options.

[Sebastian Roth]

@drc0nc Please boot into debug mode on this client and run fogpartinfo --list-parts /dev/sda

This is what FOG did (in the older versions, Tom changed that in the last week) to get the partitions. I guess this will fail. Please let us know which error you see.

[drc0nc]

@Sebastian-Roth the output was

/dev/mmcblk0      179:0
/dev/mmcblk0boot0 179:8
/dev/mmcblk0boot1 179:16
/dev/mmcblk0p1    179:1
/dev/mmcblk0p2    179:2
/dev/mmcblk0p3    179:3
/dev/mmcblk0p4    179:4
/dev/mmcblk0rpmb  179:24

[Sebastian Roth]

@drc0nc Sorry, updated my last post as I remembered that Tom changed this not long ago. Please try fogpartinfo --list-parts /dev/sda and see if you get any errors.

[drc0nc]

@Sebastian-Roth fogpartinfo isn’t a valid command

[Wayne Workman]

@drc0nc I was going to suggest creating a DHCP Reservation for one of the adapters, and point it’s option 066 (for the reservation only) to the FOG server in the other building that is running FOG Trunk.

See what luck you have…

That’ll cause it to use that fog server.

[drc0nc]

@Wayne-Workman I’ll be heading over to one of the other schools today. I’ll bring a couple HP’s and try it from there and see if an updated trunk will let me boot. I’m just curious as to why I can’t image using anything other than RAW when it was letting me before. (on the HP’s)

[Wayne Workman]

@drc0nc Well if you’re using 1.2.0 stable - it’s not changed. Something else must have changed.

[drc0nc]

@Wayne-Workman I’m running version 5293 currently

[Wayne Workman]

@drc0nc said:

BTW I want to upgrade trunk but i’m afraid that I’ll lose functionality for the HP’s.

Oh. I interpreted that line as if you were on 1.2.0.

[drc0nc]

@Wayne-Workman lol no sorry. I meant update the revision. I know that 5293 was a working release with the streams so I only installed that one again

[Sebastian Roth]

@drc0nc Hey man, sorry again. I am getting a little confused here. Clearly you are using a newer kernel (bzImage/init.xz) than rev5293 as fogpartinfo is not included anymore. This is not a problem! Just means that the output of lsblk is relavant.

@Tom-Elliott Changing from fogpartinfo to lsblk - have you tried special things like mmcblk yet? Fram what I can see in the code the major ID 179 is not being taken care of. Could you update the script?

[drc0nc]

@Sebastian-Roth I guess, sorry. I know my bzImage and bzImage32 file versions are 4.2.3 (that’s what allowed me to get these babies going.)

[drc0nc]

@Wayne-Workman @Sebastian-Roth @Tom-Elliott So today I figured I would update the trunk (5686) and the bzImage. Today’s 4.3.0 was still forcing me to pull an image using the RAW format. The other options will give me the oversize error. Also, the ipxe boot is asking me to manually input the fog server IP while using ipxe.efi after updating. All in all I can still image, just only doing it RAW (pun intended)

[Sebastian Roth]

@drc0nc Thanks a lot for all the testing and the information you gave. We are working on this. Although it’s not easy when we don’t have the devices handy to test. mmcblk0 devices are not as easy to handle as other block devices are. And I just stumbled upon another thing that might cause issues when deploying an image to a new client. Could you please run another debug session on one of your devices and check if writing to the MMC boot partitions is disabled by default (as described here: https://www.kernel.org/doc/Documentation/mmc/mmc-dev-parts.txt)

cat /sys/block/mmcblk0boot0/force_ro
...
cat /sys/block/mmcblk0boot1/force_ro
...

[Sebastian Roth]

@drc0nc Here we go. I found some time to look into this more closely!
Download init.xz/init_32.xz test files from https://drive.google.com/folderview?id=0B-bOeHjoUmyMazJLZDhGaEl5VTQ&usp=sharing and put into place in /var/www/fog/service/ipxe/ or /var/www/html/fog/service/ipxe/ (probably a good idea to rename the original files instead of just overwriting them!)

Please test and report back if capturing/deploy is working (Image type: Multiple Partition - Single Disk, Host Primary Disk: /dev/mmcblk0).

We might still run into issues if mmcblk0boot0 is read only by default. So please check my last post as well and let us know.

[drc0nc]

@Sebastian-Roth Ok, sorry I was out of office for a few days.
I got the image to pull just fine using your test files. Ran into the read only problem on the boot0 and boot1

I just used the

echo 0 > /sys/block/mmcblk0boot0/force_ro
echo 0 > /sys/block/mmcblk0boot1/force_ro

and it let me push an image on it. I’m just pretty happy the partitions weren’t locked permanently. What are the next steps moving forward on this?

Also, I appreciate the help and hope that other people with these MMC devices can start imaging.