Windows 10 - Image upload - sectorsize error
GFm last edited by GFm
This is the best pic I could get, but here are some errors it’s spitting out.
*EDITSVN 4696 => I just updated to SVN4699 and it did the same thing
Single-Disk Resizable image
UEFI non secure boot
windows 10 education edition (64bit)
Yep no worries! Sorry… You fixed the initial problem. It did upload.
@GFm Don’t be worried about the back to back posts. You’re trying to help us figure out where a problem is.
I would like, if you’d be so kind, for you to start a new thread as what you’re seeing now is NOTHING related to sectorsize and weird sed inaccuracies.
Here it is after the quick-image… sorry so many posts.
I booted back to my win10 flash drive and saw this…
So it must have deleted everything? I then went and quick-imaged it with the image I just uploaded and it went back through, but when it started to boot it said…
“The Boot Configuration Data for your PC is missing or contains errors.”
I just updated and it seemed to upload fine. Upon reboot, it says no bootable devices now. Any ideas?
@Quazz No clue. Maybe a picture of the first and second go arounds can help?
@Tom-Elliott Then I’m not sure what happened. How come the first time it stops the process entirely when it fails to resize the fat32 partition (claiming the mbr partition is too large and needs to be resized), but then when I reboot and try again it works fine?
It’s no big deal since it works the second time around, just want to know what’s going on. ;)
@Quazz I don’t think that’s the case at all.
fat32 has no support for resizing in the init’s.
The way we perform resizing is per partition, so what you see as fail on one, and success on another is only from the next partition. If you had 4 fat32 partitions on the disk, you’d likely see the failure on all four partitions.
I had this same issue and after updating it seems to work for me. I was busy switching all my images to single disk resizable, so this is great timing for me ;)
Although I do have to try it twice, it fails on resizing the first partition (fat32 UEFI partition), but then on second try it always works. I’m guessing it DOES succeed on resizing the partition, but doesn’t realize it for some reason!
I will update and try on Monday. Thanks for the info!
@GFm I finally got my own system to test this. (VM with GPT layout) and i can say, with reasonable certainty, this should now operate too.
Apparently, upload resize of GPT structures was broken. This same methodology (only reversed) was also used for download. The escaping wasn’t pretty either, but that appears to be good now too. I don’t know how viable this will be for non-resizable images, but with any luck this doesn’t require as much “thought” to go in.
When you have free time, please test again and let me know.
Thank you very much for at least reporting and getting us to look at the source. It was a fun time.
Wayne Workman last edited by
@Developers This output looks strikingly similar to errors I have here using UEFI, resizable disks:
I think these two threads have a common problem.
@GFm One thing I see missing from your post is what hardware are you trying to upload from? Make and model, please.
I have not encountered these issues before :(
However, I do know where they’re coming from.
Our issue is apparently the checks for sgdisk need a TON more refinement, which I hope you don’t mind me working on getting from you, maybe next week?
I hope so…