the curl download failed with a connection reset after 17 minutes and 20gb!
so I tell curl to resume it, and... the server starts over from the beginning.
MICROSOFT'S STUPID SERVER DOESN'T SUPPORT THE RANGE HEADER
the curl download failed with a connection reset after 17 minutes and 20gb!
so I tell curl to resume it, and... the server starts over from the beginning.
MICROSOFT'S STUPID SERVER DOESN'T SUPPORT THE RANGE HEADER
anger canceled, I was just misreading curl. it did resume.
so again, why doesn't microsoft's official tool do this?
currently on attempt #8
#7 made it to 17gb (of 22gb)!
bad idea: I already MITM'd this once.
I download the file with curl and stick it on a local fast server. Then I set up mitmproxy to silently rewrite requests to their shitty server to my local one, which will be an actual server that works and doesn't randomly drop connections once out of EVERY FUCKING TIME
annoyingly I already deleted the file I downloaded earlier.
(I'm juggling laserdisc archival files right now, so my laptop has a VERY full hard drive, and I thought I was done with that file when it failed verification)
my first attempt and curling it stalled at 16mb.
not gigabytes, megabytes.
hey microsoft could I mail you some blank floppies and you just return 'em with the file on it? that might be easier at this point
I have downloaded the file and I'm now copying it onto my local server.
why didn't I just download it on my local server in the first place, so I wouldn't have to copy it across my house's network?
good question.
okay the files all moved locally so I can just make mitmproxy point it at the different URL. but I think I have been screaming at this problem enough for one day, so I'm going to stop for tonight.
the surface hub has not defeated me yet, I fight on
I lied. mitmproxy is now redirected to my local server, and Surface IT Tool is downloading from it.
annoyingly slowly, actually. Only 51Mbps? this is 22gb!
(it's probably because mitmproxy is handling all the bytes instead of letting nginx do it)
okay I have made a recovery disk by using the MITM download hack
how much do you want to bet this thing won't even boot?
it boots! it's now recovering
this may finally get us incrementally closer to a version of windows that actually works
So instead you've got these instructions, which do not work:
https://learn.microsoft.com/en-us/surface-hub/surface-hub-2s-migrate-os
because the way it suggests to make a recovery image doesn't create a recovery image this locked-down fucker will boot.
Only the Surface IT Tools recovery images will boot, and Surface IT Tools can't download files worth shit, so good fucking luck getting that 22gb image
also the Surface IT Tool verifies _something_ (I wasn't able to confirm what) with the microsoft servers before it'll write you an image, even if you have the image already downloaded.
So I highly suspect this method will break in the future
I know I'm way out of date on this - the last time I installed Linux on a Windows machine was probably 2001 or so - but there were Windows programs you could fire up to start the installation of some major distros from within Windows. I don't remember what they were called, but I think they were either official tools of those distros, or at least officially blessed.
IIRC, they fiddled the MBR and did other stuff. I'm wondering, does anything like this still exist, and does it maybe do things like installing keys in the UEFI partition or other magic to deal with secure boot?
@cazabon yeah, Wubi from Ubuntu used to do that. I used it for a while back in the day. It's not going to bypass Secure Boot, though (which it seems Foone's Surface doesn't allow disabling) – and it had zero support for UEFI style boot in general – Wubi would just install grub4dos and configure it to be chain-loaded specifically from WinXP's NTLDR.
(I don't think it touched the MBR? nor the VBR? I don't remember for sure, but I *think* it was ntldr->grub4dos specifically to reduce the chance of failure. Traditional dualboot would go rearranging things to do grub->ntldr instead, but Wubi was for a very non-technical audience.)
These days as far as I know Windows's BOOTMGR refuses to boot anything that isn't digitally signed as a Windows component (unlike NTLDR in WinXP where you could still add arbitrary entries), so you can no longer chain bootmgr->grub, have to boot directly into grub from the beginning.
imo, installing GRUB "from the outside" has become *kinda easier* in EFI world; the equivalent of "fiddling the MBR" on UEFI systems would be "fondling the EFI boot variables", which Windows has an API for (and you can do it through bcdedit, etc) – the bootloader lives on a FAT partition, drop grub.efi in there, add a new boot entry that points to grub.efi – but of course that grub.efi isn't "Microsoft-signed" so it still won't boot no matter what.
as I understand the Surface won't boot even the MS-signed "Shim" because the hardware deliberately lacks the "third-party" UEFI certificates... although mjg59 said elsewhere in the thread that allegedly those are now possible to install thanks to the 2023 cert rollover, which actually sounds like it would work (as soon as there's a version of Shim out there that's signed using the 2023 "third-party" cert, and not the 2011 one)