HP Stream 11 pro

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

[Sebastian Roth]

@drc0nc That’s great news. Thanks! Tom has worked on the init files/fog scripts lately. Refactoring and improving the code a lot. Please be patient for a few more days. The newly released init files will have all the changes included. Would be great if you could test those then as well. I will let you know.

@Tom-Elliott see this special thing about mmcblk0bootX devices being readonly by default. I’ll have a look on how to check and automaticly enable write access in fog.download.

[Tom Elliott]

@Sebastian-Roth said:

al thing about mmcblk0bootX devices being readonly by default. I’ll have a look on how to check and automaticly enable write access in fog.download.

I’m re-refactoring the fog.download to follow similar methodology as the fog.upload script does.

I can add in the checks if you want.

That said, I’m kind of scared to enforce write access to this partitions.

https://www.kernel.org/doc/Documentation/mmc/mmc-dev-parts.txt

[drc0nc]

@Tom-Elliott @Sebastian-Roth I thank both of you guys! I can wait, no problem. Also, you need me to test any of it, I’m more than willing.

[Sebastian Roth]

@Tom-Elliott said:

I can add in the checks if you want.

That said, I’m kind of scared to enforce write access to this partitions.

While you are at it… See if you can add this as well. I felt kind of the same when first reading about the read only boot partitions. But on the other hand this is kind of like writing the MBR or partition layout. If we do something wrong there things can really go wrong. But we still do because we need to. Same with those boot partitions on mmcblk devices I reckon. We just won’t get around writing to those if we want to properly deploy to those kind of devices.

[Tom Elliott]

fog.download has been rewritten.

I’ve made quite a few adjustments and calculations for this and have tested the resizable download capability.

With this, i believe i fixed upload and download with multipart types (non resize) as well.

This should be the most non-assumptive init yet.

While I’m sure I could post this to the masses, I’d rather those of you with these “weird” hard drives test this and verify if the findings are correct and things are working correctly.

I have performed some decent testing, but I’d rather rely on information straight from those of you who have this issue.

[Tom Elliott]

Probably needed information.

The init’s are currently at:

http://mastacontrola.com/init.xz (64 bit)
http://mastacontrola.com/init_32.xz (32 bit)

You can use these commands:

wget -O /var/www/fog/service/ipxe/init.xz http://mastacontrola.com/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz http://mastacontrola.com/init_32.xz

I hope for the best of news, but I’m not holding my breath.

While I’m quite impressed with the fog.upload, I still worry how fog.download turned out a little bit.

[Wayne Workman]

@Tom-Elliott So they are not added into trunk yet?

[Tom Elliott]

@Wayne-Workman the scripts are. the inits are not updated with these changes yet.

[drc0nc]

@Tom-Elliott @Wayne-Workman @Sebastian-Roth Here is just a snapshot of a debug capture task. http://i.imgur.com/m2l2Nfo.jpg (sorry but chrome was giving me problems uploading into the forum.)
I will post info once the capture is done and I’m deploying an image.
It’s working so far with the inits I got from Tom.

[Tom Elliott]

@drc0nc Is this good or bad?

[drc0nc]

@Tom-Elliott It pulled an image just fine. When I go to deploy this is what happens http://i.imgur.com/Hbw7LL3.jpg

If i use the

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

and run a debug deploy this is what happens
http://i.imgur.com/YlxKwGY.jpg

It can capture just fine, deploying is having a problem (looks like a syntax issue?)

[Tom Elliott]

Teamviewer?

[drc0nc]

@Tom-Elliott sure thing

[Tom Elliott]

Remoted in and found a few more deploy bugs, but I think we finally got them worked out.

It appears that the mmcblk#boot# parts are not parts, but disks in their own right.

Because of this, I have removed the read/write code (commented really) and am not iterating through these disks in any manner.

I suppose if you wanted to, you could down the road but I would highly recommend against it.

[Sebastian Roth]

@Tom-Elliott said:

It appears that the mmcblk#boot# parts are not parts, but disks in their own right.

Because of this, I have removed the read/write code (commented really) and am not iterating through these disks in any manner.

Sounds interesting but I don’t really get what you mean by that Tom. Would you mind explaining this a bit more? From what I saw in earlier posts it seamed like mmcblk#boot# partitions where no problem if read only was disabled. But maybe I am wrong?!