HP Stream 11 pro
-
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.
-
@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?!
-
The mmcblk#boot# are the disks, while the mmcblk#boot#p# are the partitions of those disks.
The problem occurs in that these boot volumes are incredibly tiny. However, the mbr that get’s written is not always appropriate for the volume. (Maybe somebody else can take that approach on?)
I ask because the boot partitions on these are not designed to be the same methods as you foresee on a typical volume layout. Perhaps there’s a reason they’re started in Read only to begin with? I’m guessing something along the lines of nand or something in a a similar fashion.
-
Ohh, now I see. Have been sitting on my eye balls I suppose. You are right mmcblk#boot# are disks, not partitions. Started a new discussion on device enumeration here: https://forums.fogproject.org/topic/6372/enumerating-disks-and-partitions
-
@tom-elliott
I’ve updated fog to 5844 (still using Toms’ inits.) the image is setup as windows 8.1 and using option 2 for type (multiple part single disk) and when I created a simple upload task on a new image it’ll pull an image like this:mmcblk0 will pull a full RAW rip (~39GB)
then it’ll continue using partclone for each “partition” ex: mmcblk0p1
each one being its respective sizes.I feel that the first step of pulling a raw image is unnecessary. or is there a way i can skip it? I’ll update this as soon as it’s finished pulling the image and I deploy it.
-
@drc0nc I have found and fixed this issue on my server. It was related that the getPartitions function was only checking if the device passed ended in a number. While this works for older style disks (/dev/{h,s}d[a-z]), it doesn’t work for disks ending with a number itself. This should now be corrected for.
Please test, if you can, and let me know?
Thank you
-
@Tom-Elliott Ok! I’ll test today and update.
EDIT: It worked, the init skipped the main block and went to the partitions and pulls images just fine. -
@Sebastian-Roth @tom-elliott New issues with enabling write cache. I can pull images fine still. Just not deploy.
-
@Wayne-Workman @Tom-Elliott @Sebastian-Roth
I’m not sure why but I cant get the debug deploy or capture to load up…
also, still having issues with deploying. I can capture just fine (not debug capture though)
-
@drc0nc I’ve marked this thread as solved as we were able to getting his working again. I had some relatively minor things that needed to be corrected and through teamviewer and a little time I figured out what the problem was. Hopefully this means the systems are bootable but I do know the system was taking the image and we already knew the system was able to upload.
-
Sort of a side note but advanced task debug download/upload should also now work properly.