Considering that you were seeing unpredictable behavior in the boot selector, with it randomly freezing, I would assume a hardware component (RAM?) kicked the bucket. If it were firmware corruption, it would consistently fail to present the menu, or wouldn't boot at all.
Microsoft's code quality might not be at its peak right now, but blaming them for what's most likely a hardware fault isn't very productive IMO.
Or something hit max program-erase cycle counts and are returning corrupt/old data. Flash ROMs tend to become "sticky" with previous states as you write more to them. I think it's possible that ROMs used for early SoC boot firmware or peripherals firmware still don't have wear leveling that they could become unusable after just a hundred or so of writes.
It could very well be something poorly configured in the boot chain leading to random failures. There are plenty of hardware things configured in software which can lead to plenty of different kinds of random failures.
Maybe! I could certainly see something like the firmware switches on something way heavier that pulls down an already marginal supply.
Remember the very early Raspberry Pis that had the polyfuses that dropped a little too much voltage from the "5V" supply, so a combination of shitty phone charger, shitty charging cable, and everything just being a little too warm/cold/wrong kind of moonlight would just make them not boot at all?
They were losing usb once in a while if ran 24/7. Had to make them self reboot every couple hours. Fortunately it didn't matter for what we were doing with them.
That's plausible, but I'd expect the UEFI patches to come from a vendor, not Microsoft. So if one came from Qualcomm, and they didn't properly specify the devices it should be installed on, that wouldn't make it Microsoft's fault.
So the "hardware failure" happening exactly at the same time the Windows update installation failed are not related? That sounds like a one in a billion kind of coincident.
An upgrade process involves heavy CPU use, disk read/writes, and at least a few power cycles in short time period. Depending what OP was doing on it otherwise, it could've been the highest temperature the device had ever seen. It's not so crazy.
My guess would've been SSD failure, which would make sense to seem to appear after lots of writes. In the olden days I used to cross my fingers when rebooting spinning disk servers with very long uptimes because it was known there was a chance they wouldn't come back up even though they were running fine.
Not for a server, but many years ago my brother had his work desktop fail after he let it cold boot for the first time in a very long time.
Normally he would leave his work machine turned on but locked when leaving the office.
Office was having electrical work done and asked that all employees unplug their machines over the weekend just in case of a surge or something.
On the Monday my brother plugged in machine and it wouldn’t turn on. Initially the IT guy remarked that my brother didn’t follow the instructions to unplug it.
He later retracted the comment after it was determined the power supply capacitors had gone bad a while back, but the issue with them was not apparent until they had a chance to cool down.
> In the olden days I used to cross my fingers when rebooting spinning disk servers with very long uptimes because it was known there was a chance they wouldn't come back up even though they were running fine.
HA! Not just me then!
I still have an uneasy feeling in my guts doing reboots, especially on AM5 where the initial memory timing can take 30s or so.
I think most of my "huh, its broken now?" experiences as a youth were probably the actual install getting wonky though, rather than the few rare "it exploded" hardware failures after reboot, though that definitely happened.
I'd like to add my reasoning for a similar failure of an HP Proliant server I encountered.
Sometimes hardware can fail during long uptime and not become a problem until the next reboot. Consider a piece of hardware with 100 features. During typical use, the hardware may only use 50 of those features. Imagine one of the unused features has failed. This would not cause a catastrophic failure during typical use, but on startup (which rarely occurs) that feature is necessary and the system will not boot without it. If it could, it could still perform it's task... because the damaged feature is not needed. But it can't get past the boot phase, where the feature is required.
Tl;dr the system actually failed months ago and the user didn't notice because the missing feature was not needed again until the next reboot.
Is there a good reason why upgrades need to stress-test the whole system? Can't they go slowly, throttling resource usage to background levels?
They involve heavy CPU use, stress the whole system completely unnecessary, the system easily sees the highest temperature the device had ever seen during these stress tests. If during that strain something fails or gets corrupted, it's a system-level corruption...
Incidentally, Linux kernel upgrades are not better. During DKMS updates the CPU load skyrockets and then a reboot is always sketchy. There's no guarantee that something would not go wrong, a secure boot issue after a kernel upgrade in particular could be a nightmare.
To answer your question; it helps to explain what the upgrade process entails.
In the case of Linux DKMS updates: DKMS is re-compiling your installed kernel modules to match the new kernel. Sometimes a kernel update will also update the system compiler. In that instance it can be beneficial for performance or stability to have all your existing modules recompiled with the new version of the compiler. The new kernel comes with a new build environment, which DKMS uses to recompile existing kernel modules to ensure stability and consistency with that new kernel and build system.
Also, kernel modules and drivers may have many code paths that should only be run on specific kernel versions. This is called 'conditional compilation' and it is a technique programmers use to develop cross platform software. Think of this as one set of source code files that generates wildly different binaries depending on the machine that compiled it. By recompiling the source code after the new kernel is installed, the resulting binary may be drastically different than the one compiled by the previous kernel. Source code compiled on a 10 year old kernel might contain different code paths and routines than the same source code that was compiled on the latest kernel.
Compiling source code is incredibly taxing on the CPU and takes significantly longer when CPU usage is throttled. Compiling large modules on extremely slow systems could take hours. Managing hardware health and temperatures is mostly a hardware level decision controlled by firmware on the hardware itself. That is usually abstracted away from software developers who need to be able to be certain that the machine running their code is functional and stable enough to run it. This is why we have "minimum hardware requirements."
Imagine if every piece of software contained code to monitor and manage CPU cooling. You would have software fighting each other over hardware priorities. You would have different systems for control, with some more effective and secure than others. Instead the hardware is designed to do this job intrinsically, and developers are free to focus on the output of their code on a healthy, stable system. If a particular system is not stable, that falls on the administrator of that system. By separating the responsibility between software, hardware, and implementation we have clear boundaries between who cares about what, and a cohesive operating environment.
That was absolutely slamming the hardware. (source: worked on Android, and GPs comments re: this are 100% correct. I’d need a bit more, well anything, to even come around to the idea the opposite is even plausible. Best steelman is naïvete, like “aren’t updates are just a few mvs and a reboot?”)
Over my 35 years of computer use, most hardware failures (very, very rare) happen during a reboot or power-on. And most of my reboots happen when installing updates. It actually seems like a very high probability in my limited experience.
Of course, it’s possible that the windows update was a factor, when combined with other conditions.
There's also the case where the hardware has failed but the system is already up so it just keeps running. It's when you finally go to reboot that everything falls apart in a visible manner.
This is one of the reasons I am not a fan of uptime worship. It's not a stable system until it's able to cold boot.
Say you have a system that has been online for 5 years continuously until a power outage knocks it out. When power is restored, the system doesn't boot to a working system. How far back do you have to go to in your backups to find a known good system? And this isn't just about hardware failure, it's an issue of configuration changes, too.
I also notice that people with lots of experience with computers will automatically reboot when they encounter minor issues (have you tried turning it off and on again?).
When it then completely falls apart on reboot, they spend several hours trying to fix it and completely forget the "early warning signs" that motivated them to reboot in the first place.
I've think the same applies to updates. I know the time I'm most likely to think about installing updates is when my computer is playing up.
I try to do the opposite, and reboot only as a last resort.
If I reboot it and it starts working again, then I haven't fixed it at all.
Whatever the initial problem was is likely to still present after reboot -- and it will tend will pop up again later even if things temporarily seem to be working OK.
> Whatever the initial problem was is likely to still present after reboot
You only know this after the reboot. Reboot to fix the issue and if it comes back then you know you have to dig deeper. Why sink hours of effort into fixing a random bit flip? I'll take the opposite position and say that especially for consumer devices most issues are caused by some random event resulting in a soft error. They're very common and if they happen you don't "troubleshoot" that.
For all we know, this thing was on its last legs (these machines do run very hot!) and the update process might have been the final nail in the coffin. That doesn't mean Microsoft set out to kill OP's machine... Same thing could have happened if OP ran make -j8 -- we wouldn't blame GNU make.
I had a friend's dad's computer's HDD fail while I was installing Linux on it to show him it. That was terrifying. I still remember the error, and I just left with it (and Windows) unable to boot. Later my friend told me that the drive was toast.
Come to think of it, maybe it was me. I might have trashed the MBR? I remember the error, though, "Non system disk or disk error".
Yeah, I think so. It's been ~25 years, and only while typing out that comment did I remember the error message and realize that's probably what I had done.
If I recall correctly, he ended up scrapping the drive.
I've fixed thousands of PCs and Macs over my career. Coincidences like this happen all the time. I mean, have you seen the frequency of updates these days? There are always some kind of updates happening. So the chances of your system breaking during an update is not actually that slim.
> That sounds like a one in a billion kind of coincident
Hardware is more likely to fail under load than at idle.
Blaming the last thing that was happening before hardware failed isn't a good conclusion, especially when the failure mode manifests as random startup failures instead of a predictable stop at some software stage.
windows update just doing a normal write causing the active chunk of flash memory being used to hold something in the boot loader to a different failed/failing section
A software update can absolutely trigger or unmask a hardware bug. It’s not an either/or thing, it’s usually (if a hardware issue is actually present) both in tandem:
I'm not so sure, I've had a similar-ish issue on a W10 PC. I vaguely suspect a race condition on one of the drivers; I've specifically got my eye on the esp32 flashing drivers.
Sometimes it boots fine, sometimes the spinning dial disappears and it gets hung on the black screen, sometimes it hangs during the spinning dial and freezes, and very occasionally blue screens with a DPC watchdog violation. Oddly, it can happen during Safe Mode boots as well.
I would think hardware, but RAM has been replaced and all is well once it boots up. I can redline the CPU and GPU at the same time with no issues.
when something works flawlessly and starts to fail after an update (so no user actions there) this could mean that update made the hardware fail. For example overuse of flash in ssd (it's been already reported https://community.spiceworks.com/t/anyone-else-have-their-ss...) or reflashing a component too many times (simple error in scripts)
I would test the CPU cooler since the fans ran so hard. Temps ramp up around the login screen, then stay hot and reboots get unpredictable.
I recently had a water cooler pump die during a Windows update. The pump was going out, but the unthrottled update getting stuck on a monster CPU finished it off.
With the original Arduino Due there was some fun undocumented behavior with the MCU (an Atmel Cortex-M3) where it would do random things at boot unless you installed a 10k resistor. From booting off of flash or ROM at random to clocks not coming up correctly.
I swear I was doing just fine with it booting reliably until I decided to try flashing it over the SWD interface. But wouldn't you know it, soldering a resistor fixed it. Mostly.
These devices are nightmares. I'm sure things will pay off at some point but this feels like all those years where everyone was cursing Nvidia on Linux and praising AMD's dedication to open source but my computer would constantly lock up regardless until I switched to Nvidia. There was this massive disconnect between my experience and what everyone told me was best supported.
Similarly, I'm constantly hearing about Qualcomm's renewed interest in Linux and this and that and how the X2 Elite will be fully supported but I have never known them to be like this. A decade or so ago we were trying to work for a school project on one of their dev kits and the documentation was so sparse.
Then I see that the Snapdragon X Elite comes in this Ideacentre stuff but looking online no one has gotten Linux anywhere close to as good as Linux is on a Mac M2. That, for me, is the marker. If a Mac can run Linux better than whatever chipset you've released, it's just not hardware worth buying. If you're not Apple, you have to support Linux. Otherwise, to borrow Internet lingo, you're "deeply unserious".
Almost certainly a soft hardware failure, likely the SSD.
I've run into a similar situation - except the culprit was Linux not Windows. Tossed the machine in a closet for a few months, when it miraculously started working again. Until it broke again a day and a half later. It's disk or RAM corruption.
Give it up dude, it's the hardware, but let not an opportunity to smash Microsoft go unfulfilled.
> I opened the system and reseated everything, including the SSD. No change. I even tested the SSD in another machine to rule it out, and it’s fine too.
But that doesn't mean it's not bad RAM, a bad SSD controller, who knows what... there are only a few of these boxes in the wild regardless, so it's unlikely it can be debugged :(
Considering the number of x86 machines I've come across in fleet deployments that were put into various states of brickdom from Windows Update, I would not be at all surprised if it was a bad update-rollback sequence.
Laptops seem particularly susceptible to whatever (anti) magic Microsoft utilise for their update rollback process, but it happens to every device class seemingly at random. Besides the run of the mill "corrupt files at random in System32", which is common and simple enough to fix with a clean install, I've had a few cases where it appears an attempt at rolling back a BIOS update has been interrupted by the rollback manager and left those machines hard bricked. They could only be recovered by flashing a clean BIOS image with an external programmer and clip (or hand soldering leads), after which they ran without issue.
As much as it's valid to question the unconditional anti-Microsoft mentality, they are still far from infallible and from my experience they are getting notably more unreliable in recent years.
That Snapdragon Kit you have was immediately recalled due to known issues. I read somewhere only a couple hundred ever shipped. I am one of the lucky ones to get one as well. If I were you I would get one of the Lenovo arm64 desktops and save what you have as a relic.
Jetson is such a confusing product and it's difficult to tell exactly what they're supporting. Looking at the image download page it seems to be only Orin and newer?
Sounds like this could potentially be some defective RAM. Memtest86 can boot from UEFI directly, so it should hopefully show up in BDS. A run should tell you what regions of RAM are bad, if any.
Not that you are at fault here, but I'd be very hesitant to install any system updates so shortly after they brick my computer, especially when Microsoft is involved.
Or for an experimental device that has reached its EOL with no support for either software or hardware.
I would just completely disable Windows Update, act as if the computer is already compromised, and only do work where security is not an issue. That's the most "reliable" way to keep it working.
I recall one of the issues leading up to their abrupt cancellation was fulfillment, so I can't help but suspect there's some potential (long-term) issue they couldn't work out for this dev kit's chipset. Maybe some part of the chain was held together with glue and "this shouldn't fail but continue anyway" and whatever hardware issue eventually hit something critical. (And they intended to fix this some time after shipping, and gave up halfway through fulfillment)
Only adding to this because it's likely a hardware failure, and I had a challenging time debugging a similar issue in an aftermarket engine ECU years ago. Thought it might make a fun anecdote.
The car would run fine once started, but the car just wouldn't start sometimes (quite modified so I knew the systems well). The started would turn as that was a simple relay, but all ECU controlled devices wouldn't trigger. Plugging into the ECU, no error codes and all looked normal.
Eventually we tracked the issue to some corruption in the ROM that was only getting read in certain circumstances, since the ECU stores maps for engine parameters based on things like pressure and temperature you might only hit the corrupted bits of a table in very specific circumstances.
Reflashed the ROM and all was good afterwards. The suspected cause of corruption was intermittent power supply that had been fixed a while earlier.
After decades of experience, my normal practice is to make regular multi-generational backups of the entire disk (usually compressed). When something like this goes wrong, I can revert to the last known-good image and go from there. It saves a lot of time and trouble.
Hopefully this serves as a reminder to decision makers with Web backgrounds to NOT push random non-critical _firmware_ updates without clear merit, or random updates in general.
Security is not fluids. It doesn't naturally evaporate. So don't try to add like they're washer fluids.
Those low-level software and associated hardware don't take software overwrites very well, even today. They might have total cumulative max overwrites, or manufacturer supplied update codes can still be dubious. It's (not)okay if you are meaning it to be a tool for your planned obsolescence strategy, otherwise, just don't touch it for the sake of doing it.
change the SSD and retry (the same ssd in another machine may not trigger the same error btw, this is not unilateral process of elimination) - those windows updates do a lot of disk writes and a small miss there can screw up an entire install since it shuffles things around in preboot environment (moving them on disk) and that can corrupt things and prevent a new install in the same way.
You can also try to live boot into Ubuntu 25.04 arm64 since that iso has experimental snapdragon elite support and has some built-in drivers for storage and network - you can extract firmware from the windows drivers with qcom-firmware-extract - they recommend doing this from a windows partition which you should have (albeit possibly corrupted).
If that still fails - you have a ram issue as others have pointed out. I've had the exact same symptoms (hardware instability after windows update) and it was nvme ssd (an early samsung one) and ram, in both instances.
Not saying the windows update didn't also come with some junk firmware that got loaded into some of your devices, but that would be a distant diagnosis from ssd/ram (and many others would have seen the exact same thing during their update if it was that).
Nobody has the time or energy to chase companies up for this stuff, and you know somewhere in the T&C they inserted a legal clause which is expensive to contest or un-contestable to liability.
But, that said, it saddens me we've normalised "oh well" when it comes to kit. even dev kit. If MS can't manage release engineering to keep dev/test things alive, then it's not helpful to the belief they can do it for production things either.
I inherited an IBM PC/RT back in the 90s. It was well outside what most people would consider its support lifetime. IBM could not have been more helpful working out how to keep it alive. I suspect this influences why when I later had some financial authority I was happier to buy thinkpad, than any other hardware we had available: I knew from experience they stood behind their maintenance guarantees. The device was configured to run BSD, not the IBM supported OS of the day, made no difference. It was end of life product line, made no difference.
This was before Lenovo of course. But the point stands: people with positive support stories, keep that vendor in their top-set
Not sure how much it could help, but is there a possibility you connect the SSD to another machine with the same architecture, run Windows install in it, then once Windows is installed and running, shut down, move the SSD back to the Snapdragon kit and attempt to boot? Just an idea...
If it's a proper devkit it should have accessible and documented test points for all voltage rails and should have come with a complete schematic. It should be possible to go through them with a voltmeter or oscilloscope and see if everything looks ok.
Given the symptoms (random crashes not right away at boot), and given that qcom is anal about secure boot, my guess is that it's unlikely that it's a firmware (in SPI-NOR or wherever) corruption that initially caused this. Firmware is checked each boot.
Might be as simple as degraded capacitor, or something similar.
And I can imagine that it's not hard to destroy this kind of HW physically with a SW update. PMICs can often produce voltages way higher than Vmax of connected components. But it's unlikely that if bug like that happened, that it would only affect one devkit out there, and not a whole range of devices.
are you able to stop at uefi stage and system is stable in bootloader stage? if yes than it may not be software issue. Others have covered checking ram and ssd. I suspect it could also be thermal or voltage issue.
Soo.. Qualcomm can use a Windows drive to receive calibration data and other configurations. If you have a virus or something, you might brick a board, if its connected. We used 3-4 days in the factory to figure out why our boards were bricked. The PCs on the production line were all infected.
Seems like the typical Microsoft experience nowadays.
My ROG Ally ran fine on Windows 11 at the beginning, but a year later always randomly crashed, even when idle, on a fresh OS install. After switching to SteamOS it runs stable again.
Snapdragon is already canceled so I guess, they just don't care about this device.
It's Microsoft on ARM. Sad to say, but don't expect full support or quality update on this.
The Snapdragon Dev Kit is canceled. Snapdragon as a whole sure as hell isn't canceled, and Windows on Snapdragon isn't, either. There's loads of Windows laptops using Snapdragon with more continuing to release.
It's just the "dev kit". Snapdragon for the laptop form factor is alive and well. You don't need a devkit for a laptop running Windows and QCOM easily figured that out.
I wanted to order one of these and then Qualcomm cancelled it.
Then I knew Windows ARM probably wasn't going to make it. Why any technical person would want a PC( not including Macs)that explicitly can't run Linux I'll never know.
Technical person that knows UNIX since being introduced to it via Xenix in 1993, and has used plenty of UNIX flavours since then.
Some of us like the experience of Visual Studio, being able to do graphics development with modern graphics APIs that don't require a bazillion of code lines, with debuggers, not having to spend weekends trying to understand why yet again YouTube videos are not being hardware accelerated, scout for hardware that is supposed to work and then fails because the new firmaware update is no longer compatible,....
Your comment appears to address the question "why use Windows" (even though the answer doesn't really make sense to me), but that's not the question asked in GP. The question was "Why buy a Windows on ARM device"
PCs aren't vertically integrated from a single vendor, and thus it isn't as if Microsoft alone can drag a whole ecosystem into ARM, even if the emulation would work out great.
Windows NT was also multi-architecture, and eventually all variants died, because x86 was good enough, and when Itanium came to be, AMD got a workaround to keep x86 going forward.
Even gaming doesn't work that great on Windows ARM.
They have the Surface line and own tons of game studios.
Where are the Gamepass games with Arm ?
Microsoft if they wanted to fund it right could get popular 3rd party software ported.
In retrospect it was hopelessly naive, but I even emailed Qualcomm asking if I could have a dev kit in exchange for porting one of my hobbyist games. They basically said thank you for asking but we don't have a program for this.
Now hypothetically let's say there was a Qualcomm Snapdragon Linux laptop. I could just port the code myself for most applications I actually need
These devkits are old and have already been released to consumer laptops over a year ago. So if you want to you can pick up pretty much any CoPilot+ PC. I'm not sure what your problem here is though.
Tuxedo is a german company relabling Clevo Laptops so far, which work out-of-the-box pretty good (I might say perfect in some cases) on Linux. They have done ZILCH, NADA, absolute nothing for Linux, besides promoting it as a brand. So now they took a snapdragon laptop, installed linux and are disappointed by the performance....Great test, tremendous work! Asahi Linux showed if you put in the work you can have awesome performance.
Yes but having to reverse engineer an entire platform from scratch is a big ask, and even with asahi it's taken many years and isn't up to snuff. Not to say anything of the team, they're truly miracle workers considering what they've been given to work with.
But it's been the same story with ARM on windows now for at least a decade. The manufacturers just... do not give a single fuck. ARM is not comparable to x86 and will never be if ARM manufacturers continue to sabotage their own platform. It's not just Linux, either, these things are barely supported on Windows, run a fraction of the software, and don't run for very long. Ask anyone burned by ARM on windows attempts 1-100.
> if you put in the work you can have awesome performance.
Then why would I pay money for a Qualcomm device just for more suffering? Unless I personally like tinkering or I am contributing to an open source project specifically for this, there is no way I would purchase a Qualcomm PC.
The original comment was "explicitly can't run Linux" which is explicitly not true. Not "it's not fully baked" or "it's not good", but a categorically unambiguously false claim of "explicitly can't run Linux" as if it was somehow firmware banned from doing so.
If someone wants to provide a link to a Linux iso that works with the Snapdragon Plus laptops( these are cheaper, but the experimental Ubuntu ISO is only for the elites) I'll go buy a Snapdragon Plus laptop next month. This would be awesome if the support was there.
Considering that you were seeing unpredictable behavior in the boot selector, with it randomly freezing, I would assume a hardware component (RAM?) kicked the bucket. If it were firmware corruption, it would consistently fail to present the menu, or wouldn't boot at all.
Microsoft's code quality might not be at its peak right now, but blaming them for what's most likely a hardware fault isn't very productive IMO.
Yeah, I agree. This just feels like an appeal to anti-Microsoft clicks
From the article:
> It won’t get past the Snapdragon boot logo before rebooting or powering off… again, seemingly at random.
Random freezing at different points of the boot process suggests a hardware failure, not something broken in the software boot chain.
Or something hit max program-erase cycle counts and are returning corrupt/old data. Flash ROMs tend to become "sticky" with previous states as you write more to them. I think it's possible that ROMs used for early SoC boot firmware or peripherals firmware still don't have wear leveling that they could become unusable after just a hundred or so of writes.
It could very well be something poorly configured in the boot chain leading to random failures. There are plenty of hardware things configured in software which can lead to plenty of different kinds of random failures.
> Random freezing at different points of the boot process suggests a hardware failure, not something broken in the software boot chain.
Power issues all day long. It'll be fine until the SoC enables enough peripherals for one of the rails to sag down.
That being said, it's a hell of a coincidence that it failed exactly when a software update failed.
Firmware update changed the order in which power is enabled to peripherals?
Maybe! I could certainly see something like the firmware switches on something way heavier that pulls down an already marginal supply.
Remember the very early Raspberry Pis that had the polyfuses that dropped a little too much voltage from the "5V" supply, so a combination of shitty phone charger, shitty charging cable, and everything just being a little too warm/cold/wrong kind of moonlight would just make them not boot at all?
First Raspberries I worked with were 3s :)
They were losing usb once in a while if ran 24/7. Had to make them self reboot every couple hours. Fortunately it didn't matter for what we were doing with them.
> This just feels like an appeal to anti-Microsoft clicks
Exactly. Did you notice the one comment on his blog? It's a Linux zealot saying "Linux".
You're trying to take too much from that single comment sample point.
How do you know they are a zealot?
I guess he's being a bit cheeky ;)
Deductive reasoning based on a sample size of one, HN comments are beyond the reach of parody.
The update listed in the article contains two UEFI patches, intended for "handheld devices".
It would be entirely unsurprising to me if this trashed UEFI for this particular ARM device, from firmware corruption.
That's plausible, but I'd expect the UEFI patches to come from a vendor, not Microsoft. So if one came from Qualcomm, and they didn't properly specify the devices it should be installed on, that wouldn't make it Microsoft's fault.
So the "hardware failure" happening exactly at the same time the Windows update installation failed are not related? That sounds like a one in a billion kind of coincident.
An upgrade process involves heavy CPU use, disk read/writes, and at least a few power cycles in short time period. Depending what OP was doing on it otherwise, it could've been the highest temperature the device had ever seen. It's not so crazy.
My guess would've been SSD failure, which would make sense to seem to appear after lots of writes. In the olden days I used to cross my fingers when rebooting spinning disk servers with very long uptimes because it was known there was a chance they wouldn't come back up even though they were running fine.
Not for a server, but many years ago my brother had his work desktop fail after he let it cold boot for the first time in a very long time.
Normally he would leave his work machine turned on but locked when leaving the office.
Office was having electrical work done and asked that all employees unplug their machines over the weekend just in case of a surge or something.
On the Monday my brother plugged in machine and it wouldn’t turn on. Initially the IT guy remarked that my brother didn’t follow the instructions to unplug it.
He later retracted the comment after it was determined the power supply capacitors had gone bad a while back, but the issue with them was not apparent until they had a chance to cool down.
> In the olden days I used to cross my fingers when rebooting spinning disk servers with very long uptimes because it was known there was a chance they wouldn't come back up even though they were running fine.
HA! Not just me then!
I still have an uneasy feeling in my guts doing reboots, especially on AM5 where the initial memory timing can take 30s or so.
I think most of my "huh, its broken now?" experiences as a youth were probably the actual install getting wonky though, rather than the few rare "it exploded" hardware failures after reboot, though that definitely happened.
This, 100%.
I'd like to add my reasoning for a similar failure of an HP Proliant server I encountered.
Sometimes hardware can fail during long uptime and not become a problem until the next reboot. Consider a piece of hardware with 100 features. During typical use, the hardware may only use 50 of those features. Imagine one of the unused features has failed. This would not cause a catastrophic failure during typical use, but on startup (which rarely occurs) that feature is necessary and the system will not boot without it. If it could, it could still perform it's task... because the damaged feature is not needed. But it can't get past the boot phase, where the feature is required.
Tl;dr the system actually failed months ago and the user didn't notice because the missing feature was not needed again until the next reboot.
Is there a good reason why upgrades need to stress-test the whole system? Can't they go slowly, throttling resource usage to background levels?
They involve heavy CPU use, stress the whole system completely unnecessary, the system easily sees the highest temperature the device had ever seen during these stress tests. If during that strain something fails or gets corrupted, it's a system-level corruption...
Incidentally, Linux kernel upgrades are not better. During DKMS updates the CPU load skyrockets and then a reboot is always sketchy. There's no guarantee that something would not go wrong, a secure boot issue after a kernel upgrade in particular could be a nightmare.
To answer your question; it helps to explain what the upgrade process entails.
In the case of Linux DKMS updates: DKMS is re-compiling your installed kernel modules to match the new kernel. Sometimes a kernel update will also update the system compiler. In that instance it can be beneficial for performance or stability to have all your existing modules recompiled with the new version of the compiler. The new kernel comes with a new build environment, which DKMS uses to recompile existing kernel modules to ensure stability and consistency with that new kernel and build system.
Also, kernel modules and drivers may have many code paths that should only be run on specific kernel versions. This is called 'conditional compilation' and it is a technique programmers use to develop cross platform software. Think of this as one set of source code files that generates wildly different binaries depending on the machine that compiled it. By recompiling the source code after the new kernel is installed, the resulting binary may be drastically different than the one compiled by the previous kernel. Source code compiled on a 10 year old kernel might contain different code paths and routines than the same source code that was compiled on the latest kernel.
Compiling source code is incredibly taxing on the CPU and takes significantly longer when CPU usage is throttled. Compiling large modules on extremely slow systems could take hours. Managing hardware health and temperatures is mostly a hardware level decision controlled by firmware on the hardware itself. That is usually abstracted away from software developers who need to be able to be certain that the machine running their code is functional and stable enough to run it. This is why we have "minimum hardware requirements."
Imagine if every piece of software contained code to monitor and manage CPU cooling. You would have software fighting each other over hardware priorities. You would have different systems for control, with some more effective and secure than others. Instead the hardware is designed to do this job intrinsically, and developers are free to focus on the output of their code on a healthy, stable system. If a particular system is not stable, that falls on the administrator of that system. By separating the responsibility between software, hardware, and implementation we have clear boundaries between who cares about what, and a cohesive operating environment.
> Depending what OP was doing on it otherwise, it could've been the highest temperature the device had ever seen. It's not so crazy.
Kind of big doubt. This was probably not slamming the hardware.
That was absolutely slamming the hardware. (source: worked on Android, and GPs comments re: this are 100% correct. I’d need a bit more, well anything, to even come around to the idea the opposite is even plausible. Best steelman is naïvete, like “aren’t updates are just a few mvs and a reboot?”)
Over my 35 years of computer use, most hardware failures (very, very rare) happen during a reboot or power-on. And most of my reboots happen when installing updates. It actually seems like a very high probability in my limited experience.
Of course, it’s possible that the windows update was a factor, when combined with other conditions.
There's also the case where the hardware has failed but the system is already up so it just keeps running. It's when you finally go to reboot that everything falls apart in a visible manner.
This is one of the reasons I am not a fan of uptime worship. It's not a stable system until it's able to cold boot.
Say you have a system that has been online for 5 years continuously until a power outage knocks it out. When power is restored, the system doesn't boot to a working system. How far back do you have to go to in your backups to find a known good system? And this isn't just about hardware failure, it's an issue of configuration changes, too.
I also notice that people with lots of experience with computers will automatically reboot when they encounter minor issues (have you tried turning it off and on again?).
When it then completely falls apart on reboot, they spend several hours trying to fix it and completely forget the "early warning signs" that motivated them to reboot in the first place.
I've think the same applies to updates. I know the time I'm most likely to think about installing updates is when my computer is playing up.
I try to do the opposite, and reboot only as a last resort.
If I reboot it and it starts working again, then I haven't fixed it at all.
Whatever the initial problem was is likely to still present after reboot -- and it will tend will pop up again later even if things temporarily seem to be working OK.
How do you avoid sinking time into chasing illusory bugs?
> Whatever the initial problem was is likely to still present after reboot
You only know this after the reboot. Reboot to fix the issue and if it comes back then you know you have to dig deeper. Why sink hours of effort into fixing a random bit flip? I'll take the opposite position and say that especially for consumer devices most issues are caused by some random event resulting in a soft error. They're very common and if they happen you don't "troubleshoot" that.
With any system: When I can find and correct the problem out of the gate, then it remains corrected the issue does not recur.
For all we know, this thing was on its last legs (these machines do run very hot!) and the update process might have been the final nail in the coffin. That doesn't mean Microsoft set out to kill OP's machine... Same thing could have happened if OP ran make -j8 -- we wouldn't blame GNU make.
This reminds me of the 3090 hardware problems being exposed by Amazons New World [1]. Everyone really wanted to blame the software.
https://www.pcgamer.com/amazon-new-world-killing-rtx-3090-gp...
I had a friend's dad's computer's HDD fail while I was installing Linux on it to show him it. That was terrifying. I still remember the error, and I just left with it (and Windows) unable to boot. Later my friend told me that the drive was toast.
Come to think of it, maybe it was me. I might have trashed the MBR? I remember the error, though, "Non system disk or disk error".
Yeah, sounds like the drive was still physically detected but that the expected boot loader wasn't present any more.
IIRC, that error text comes from the mbr. You may have trashed the partition table?
Yeah, I think so. It's been ~25 years, and only while typing out that comment did I remember the error message and realize that's probably what I had done.
If I recall correctly, he ended up scrapping the drive.
If had happened any other time, there wouldn't be a blog post about it and we wouldn't be reading about it.
I've fixed thousands of PCs and Macs over my career. Coincidences like this happen all the time. I mean, have you seen the frequency of updates these days? There are always some kind of updates happening. So the chances of your system breaking during an update is not actually that slim.
I think it's fair to say they're related, yes. But causality can well be the other way around — that Windows upgrade failed because of flaky hardware.
> That sounds like a one in a billion kind of coincident
Hardware is more likely to fail under load than at idle.
Blaming the last thing that was happening before hardware failed isn't a good conclusion, especially when the failure mode manifests as random startup failures instead of a predictable stop at some software stage.
windows update just doing a normal write causing the active chunk of flash memory being used to hold something in the boot loader to a different failed/failing section
This happens all the time, people always doubt it - but the patterns are always consistent: large updates kill hardware that's in progress of failing
Two bugs occurring at the same time is definitely not one in a billion, and with billions of computers in the world, weird shit is going to happen.
A software update can absolutely trigger or unmask a hardware bug. It’s not an either/or thing, it’s usually (if a hardware issue is actually present) both in tandem:
Like winning the lottery?
Happens quite often
"Hardware failure" => "WinUpdate failure" => "Corrupted system" conforms the Occam's razor.
I'm not so sure, I've had a similar-ish issue on a W10 PC. I vaguely suspect a race condition on one of the drivers; I've specifically got my eye on the esp32 flashing drivers.
Sometimes it boots fine, sometimes the spinning dial disappears and it gets hung on the black screen, sometimes it hangs during the spinning dial and freezes, and very occasionally blue screens with a DPC watchdog violation. Oddly, it can happen during Safe Mode boots as well.
I would think hardware, but RAM has been replaced and all is well once it boots up. I can redline the CPU and GPU at the same time with no issues.
when something works flawlessly and starts to fail after an update (so no user actions there) this could mean that update made the hardware fail. For example overuse of flash in ssd (it's been already reported https://community.spiceworks.com/t/anyone-else-have-their-ss...) or reflashing a component too many times (simple error in scripts)
Or it might not be related at all. Correlation and causality might be in charge here.
Doesn't Ockham's Razor tell us to check the more obvious things first?
I would test the CPU cooler since the fans ran so hard. Temps ramp up around the login screen, then stay hot and reboots get unpredictable.
I recently had a water cooler pump die during a Windows update. The pump was going out, but the unthrottled update getting stuck on a monster CPU finished it off.
With the original Arduino Due there was some fun undocumented behavior with the MCU (an Atmel Cortex-M3) where it would do random things at boot unless you installed a 10k resistor. From booting off of flash or ROM at random to clocks not coming up correctly.
I swear I was doing just fine with it booting reliably until I decided to try flashing it over the SWD interface. But wouldn't you know it, soldering a resistor fixed it. Mostly.
These devices are nightmares. I'm sure things will pay off at some point but this feels like all those years where everyone was cursing Nvidia on Linux and praising AMD's dedication to open source but my computer would constantly lock up regardless until I switched to Nvidia. There was this massive disconnect between my experience and what everyone told me was best supported.
Similarly, I'm constantly hearing about Qualcomm's renewed interest in Linux and this and that and how the X2 Elite will be fully supported but I have never known them to be like this. A decade or so ago we were trying to work for a school project on one of their dev kits and the documentation was so sparse.
Then I see that the Snapdragon X Elite comes in this Ideacentre stuff but looking online no one has gotten Linux anywhere close to as good as Linux is on a Mac M2. That, for me, is the marker. If a Mac can run Linux better than whatever chipset you've released, it's just not hardware worth buying. If you're not Apple, you have to support Linux. Otherwise, to borrow Internet lingo, you're "deeply unserious".
Yeah they (probably) did not.
Almost certainly a soft hardware failure, likely the SSD.
I've run into a similar situation - except the culprit was Linux not Windows. Tossed the machine in a closet for a few months, when it miraculously started working again. Until it broke again a day and a half later. It's disk or RAM corruption.
Give it up dude, it's the hardware, but let not an opportunity to smash Microsoft go unfulfilled.
From the article:
> I opened the system and reseated everything, including the SSD. No change. I even tested the SSD in another machine to rule it out, and it’s fine too.
But that doesn't mean it's not bad RAM, a bad SSD controller, who knows what... there are only a few of these boxes in the wild regardless, so it's unlikely it can be debugged :(
Hi, Jeff! Didn't realize the SSD was removable. Murphy's Law dictates the problem will always be in a soldered-down component whenever this happens.
Or in the connections in case the part is not soldered in place.
Considering the number of x86 machines I've come across in fleet deployments that were put into various states of brickdom from Windows Update, I would not be at all surprised if it was a bad update-rollback sequence.
Laptops seem particularly susceptible to whatever (anti) magic Microsoft utilise for their update rollback process, but it happens to every device class seemingly at random. Besides the run of the mill "corrupt files at random in System32", which is common and simple enough to fix with a clean install, I've had a few cases where it appears an attempt at rolling back a BIOS update has been interrupted by the rollback manager and left those machines hard bricked. They could only be recovered by flashing a clean BIOS image with an external programmer and clip (or hand soldering leads), after which they ran without issue.
As much as it's valid to question the unconditional anti-Microsoft mentality, they are still far from infallible and from my experience they are getting notably more unreliable in recent years.
>Almost certainly a soft hardware failure, likely the SSD.
If you actually read the article, you'd know it wasn't. Besides, Windows updates can and do deliver firmware/bios updates.
Considering that when the problems started, many people online were having a similar issue I think it's unlikely it was a hardware failure.
Or Microsoft deliberately bought shoddy RAM/SSDs, intending to force the bathtub curve down onto devkits they wanted dead ASAP.
The machine in question was not a Microsoft product, so they would not have been making decisions about component selection.
That Snapdragon Kit you have was immediately recalled due to known issues. I read somewhere only a couple hundred ever shipped. I am one of the lucky ones to get one as well. If I were you I would get one of the Lenovo arm64 desktops and save what you have as a relic.
I was pleased to discover recently that Ubuntu is supporting my NVidia Jetson going forward after NVidias official support period ends:
https://canonical.com/blog/ubuntu-now-officially-supports-nv...
So there is at least one ARM devkit with long term Linux support.
Jetson is such a confusing product and it's difficult to tell exactly what they're supporting. Looking at the image download page it seems to be only Orin and newer?
https://ubuntu.com/download/nvidia-jetson
Sounds like this could potentially be some defective RAM. Memtest86 can boot from UEFI directly, so it should hopefully show up in BDS. A run should tell you what regions of RAM are bad, if any.
Not that you are at fault here, but I'd be very hesitant to install any system updates so shortly after they brick my computer, especially when Microsoft is involved.
Or for an experimental device that has reached its EOL with no support for either software or hardware.
I would just completely disable Windows Update, act as if the computer is already compromised, and only do work where security is not an issue. That's the most "reliable" way to keep it working.
Of course, hindsight something something...
having windows update running is already a compromise in some respects
I haven't run windows update in like 20 years
I doubt this is a Windows issue.
I would replace your ram sticks. I had a similar mysterious issue on an old Intel nuc. Got some new sticks off Amazon and never had the problem again
Sadly it's one of the Arm Qualcomm Snapdragon boxes; none that I've seen offer replaceable RAM sticks.
I recall one of the issues leading up to their abrupt cancellation was fulfillment, so I can't help but suspect there's some potential (long-term) issue they couldn't work out for this dev kit's chipset. Maybe some part of the chain was held together with glue and "this shouldn't fail but continue anyway" and whatever hardware issue eventually hit something critical. (And they intended to fix this some time after shipping, and gave up halfway through fulfillment)
Only adding to this because it's likely a hardware failure, and I had a challenging time debugging a similar issue in an aftermarket engine ECU years ago. Thought it might make a fun anecdote.
The car would run fine once started, but the car just wouldn't start sometimes (quite modified so I knew the systems well). The started would turn as that was a simple relay, but all ECU controlled devices wouldn't trigger. Plugging into the ECU, no error codes and all looked normal.
Eventually we tracked the issue to some corruption in the ROM that was only getting read in certain circumstances, since the ECU stores maps for engine parameters based on things like pressure and temperature you might only hit the corrupted bits of a table in very specific circumstances.
Reflashed the ROM and all was good afterwards. The suspected cause of corruption was intermittent power supply that had been fixed a while earlier.
After decades of experience, my normal practice is to make regular multi-generational backups of the entire disk (usually compressed). When something like this goes wrong, I can revert to the last known-good image and go from there. It saves a lot of time and trouble.
Hopefully this serves as a reminder to decision makers with Web backgrounds to NOT push random non-critical _firmware_ updates without clear merit, or random updates in general.
Security is not fluids. It doesn't naturally evaporate. So don't try to add like they're washer fluids.
Those low-level software and associated hardware don't take software overwrites very well, even today. They might have total cumulative max overwrites, or manufacturer supplied update codes can still be dubious. It's (not)okay if you are meaning it to be a tool for your planned obsolescence strategy, otherwise, just don't touch it for the sake of doing it.
If it updated the UEFI it could be that somehow the UEFI now starts the hardware wrong (RAM setup maybe?) that causes it to be unstable.
change the SSD and retry (the same ssd in another machine may not trigger the same error btw, this is not unilateral process of elimination) - those windows updates do a lot of disk writes and a small miss there can screw up an entire install since it shuffles things around in preboot environment (moving them on disk) and that can corrupt things and prevent a new install in the same way.
You can also try to live boot into Ubuntu 25.04 arm64 since that iso has experimental snapdragon elite support and has some built-in drivers for storage and network - you can extract firmware from the windows drivers with qcom-firmware-extract - they recommend doing this from a windows partition which you should have (albeit possibly corrupted).
If that still fails - you have a ram issue as others have pointed out. I've had the exact same symptoms (hardware instability after windows update) and it was nvme ssd (an early samsung one) and ram, in both instances.
Not saying the windows update didn't also come with some junk firmware that got loaded into some of your devices, but that would be a distant diagnosis from ssd/ram (and many others would have seen the exact same thing during their update if it was that).
The holy trinity of modern hardware: update servers, firmware locks, and abandoned devkits
Nobody has the time or energy to chase companies up for this stuff, and you know somewhere in the T&C they inserted a legal clause which is expensive to contest or un-contestable to liability.
But, that said, it saddens me we've normalised "oh well" when it comes to kit. even dev kit. If MS can't manage release engineering to keep dev/test things alive, then it's not helpful to the belief they can do it for production things either.
I inherited an IBM PC/RT back in the 90s. It was well outside what most people would consider its support lifetime. IBM could not have been more helpful working out how to keep it alive. I suspect this influences why when I later had some financial authority I was happier to buy thinkpad, than any other hardware we had available: I knew from experience they stood behind their maintenance guarantees. The device was configured to run BSD, not the IBM supported OS of the day, made no difference. It was end of life product line, made no difference.
This was before Lenovo of course. But the point stands: people with positive support stories, keep that vendor in their top-set
Not sure how much it could help, but is there a possibility you connect the SSD to another machine with the same architecture, run Windows install in it, then once Windows is installed and running, shut down, move the SSD back to the Snapdragon kit and attempt to boot? Just an idea...
We just bought a Snapdragon Windows device.
I trust Microsoft 0% to keep developing Windows for it.
Man, it looks like a memory issue. Is the memory user replaceable on this machine?
If it's a proper devkit it should have accessible and documented test points for all voltage rails and should have come with a complete schematic. It should be possible to go through them with a voltmeter or oscilloscope and see if everything looks ok.
Given the symptoms (random crashes not right away at boot), and given that qcom is anal about secure boot, my guess is that it's unlikely that it's a firmware (in SPI-NOR or wherever) corruption that initially caused this. Firmware is checked each boot.
Might be as simple as degraded capacitor, or something similar.
And I can imagine that it's not hard to destroy this kind of HW physically with a SW update. PMICs can often produce voltages way higher than Vmax of connected components. But it's unlikely that if bug like that happened, that it would only affect one devkit out there, and not a whole range of devices.
As a data point, my Windows Dev Kit 2023 (also a Snapdragon) has been working great so far.
are you able to stop at uefi stage and system is stable in bootloader stage? if yes than it may not be software issue. Others have covered checking ram and ssd. I suspect it could also be thermal or voltage issue.
Cool. Running development for fork Ruby on Rails /src/ crates to match kit for enterprise-level software firmware recovery paths.
Soo.. Qualcomm can use a Windows drive to receive calibration data and other configurations. If you have a virus or something, you might brick a board, if its connected. We used 3-4 days in the factory to figure out why our boards were bricked. The PCs on the production line were all infected.
Seems like the typical Microsoft experience nowadays.
My ROG Ally ran fine on Windows 11 at the beginning, but a year later always randomly crashed, even when idle, on a fresh OS install. After switching to SteamOS it runs stable again.
THere's a chance that there was a hardware failure and _that's_ why the update was failing. And not a failed update that caused the hardware failure.
Either way, may the memroy of your Snapdragon Dev Kit be a blessing.
Completely off topic: the font on that site is quite readable and easy on the eyes and brain, the way the dyslexia font on the Kindle is.
It's Overlock https://fonts.google.com/specimen/Overlock
Snapdragon is already canceled so I guess, they just don't care about this device. It's Microsoft on ARM. Sad to say, but don't expect full support or quality update on this.
Ref:
- https://www.youtube.com/watch?v=XrA2Xe9f7e8 - https://www.jeffgeerling.com/blog/2024/qualcomm-snapdragon-d...
The Snapdragon Dev Kit is canceled. Snapdragon as a whole sure as hell isn't canceled, and Windows on Snapdragon isn't, either. There's loads of Windows laptops using Snapdragon with more continuing to release.
No, the dev kit was cancelled.
There are ARM laptops out there from multiple manufacturers, and there is a SnapDragon 2 on the horizon.
It's just the "dev kit". Snapdragon for the laptop form factor is alive and well. You don't need a devkit for a laptop running Windows and QCOM easily figured that out.
you mean like the new generation they just announced? https://www.qualcomm.com/laptops/products/snapdragon-x2-elit...
I wanted to order one of these and then Qualcomm cancelled it.
Then I knew Windows ARM probably wasn't going to make it. Why any technical person would want a PC( not including Macs)that explicitly can't run Linux I'll never know.
Technical person that knows UNIX since being introduced to it via Xenix in 1993, and has used plenty of UNIX flavours since then.
Some of us like the experience of Visual Studio, being able to do graphics development with modern graphics APIs that don't require a bazillion of code lines, with debuggers, not having to spend weekends trying to understand why yet again YouTube videos are not being hardware accelerated, scout for hardware that is supposed to work and then fails because the new firmaware update is no longer compatible,....
Your comment appears to address the question "why use Windows" (even though the answer doesn't really make sense to me), but that's not the question asked in GP. The question was "Why buy a Windows on ARM device"
Ah, ok, that I really don't see the point.
PCs aren't vertically integrated from a single vendor, and thus it isn't as if Microsoft alone can drag a whole ecosystem into ARM, even if the emulation would work out great.
Windows NT was also multi-architecture, and eventually all variants died, because x86 was good enough, and when Itanium came to be, AMD got a workaround to keep x86 going forward.
Even gaming doesn't work that great on Windows ARM.
Microsoft isn't even putting in a fair effort.
They have the Surface line and own tons of game studios.
Where are the Gamepass games with Arm ?
Microsoft if they wanted to fund it right could get popular 3rd party software ported.
In retrospect it was hopelessly naive, but I even emailed Qualcomm asking if I could have a dev kit in exchange for porting one of my hobbyist games. They basically said thank you for asking but we don't have a program for this.
Now hypothetically let's say there was a Qualcomm Snapdragon Linux laptop. I could just port the code myself for most applications I actually need
While I agree Microsoft's strategy with Windows ARM could be better, it isn't as if GNU/Linux on ARM is flourishing for consumers, outside Android.
>Where are the Gamepass games with Arm ?
https://www.theverge.com/news/758828/microsoft-windows-on-ar...
>Microsoft if they wanted to fund it right could get popular 3rd party software ported.
https://www.windowscentral.com/microsoft/windows-11/your-win...
These devkits are old and have already been released to consumer laptops over a year ago. So if you want to you can pick up pretty much any CoPilot+ PC. I'm not sure what your problem here is though.
Ok.
But with an x86 device you can run Windows and Linux. With an Windows Arm device it's probably only going to work with Windows.
It's not clear what real advantages Arm gives you here.
That much I agree on, indeed.
> Why any technical person would want a PC that explicitly can't run Linux I'll never know.
Huh? https://www.phoronix.com/review/snapdragon-x1e-september
More recent revisit: https://www.phoronix.com/review/snapdragon-x-elite-linux-eoy...
TL;DR: It runs, but not well, and performance has regressed since the last published benchmark.
Tuxedo is a german company relabling Clevo Laptops so far, which work out-of-the-box pretty good (I might say perfect in some cases) on Linux. They have done ZILCH, NADA, absolute nothing for Linux, besides promoting it as a brand. So now they took a snapdragon laptop, installed linux and are disappointed by the performance....Great test, tremendous work! Asahi Linux showed if you put in the work you can have awesome performance.
Yes but having to reverse engineer an entire platform from scratch is a big ask, and even with asahi it's taken many years and isn't up to snuff. Not to say anything of the team, they're truly miracle workers considering what they've been given to work with.
But it's been the same story with ARM on windows now for at least a decade. The manufacturers just... do not give a single fuck. ARM is not comparable to x86 and will never be if ARM manufacturers continue to sabotage their own platform. It's not just Linux, either, these things are barely supported on Windows, run a fraction of the software, and don't run for very long. Ask anyone burned by ARM on windows attempts 1-100.
> if you put in the work you can have awesome performance.
Then why would I pay money for a Qualcomm device just for more suffering? Unless I personally like tinkering or I am contributing to an open source project specifically for this, there is no way I would purchase a Qualcomm PC.
Which is what the original comment is about.
The original comment was "explicitly can't run Linux" which is explicitly not true. Not "it's not fully baked" or "it's not good", but a categorically unambiguously false claim of "explicitly can't run Linux" as if it was somehow firmware banned from doing so.
If you want to split hairs, sure. It does not help anyone who is considering buying a laptop.
I'm open to being wrong.
If someone wants to provide a link to a Linux iso that works with the Snapdragon Plus laptops( these are cheaper, but the experimental Ubuntu ISO is only for the elites) I'll go buy a Snapdragon Plus laptop next month. This would be awesome if the support was there.