I’m not necessarily looking for help, as I suspect there isn’t any to be had in my case. Just a warning to others: a “zypper dup” today completely removed Windows 11 from my laptop.
The first sign of trouble was that the GRUB boot menu option for Windows said “device not found.” I booted into Leap 16.0 and ran os-prober, which gave an error message. I started multipathd and tried again. os-prober successfully returned empty results. I then looking at the disk formatting via Yast – the Windows 11 partition is simply gone. All of the others are still there.
I tried running testdisk. It does a lot of scanning and does not locate Windows, though it does find all of the other partitions (including a DOS partition I was using to transfer data between the two). I can see a gap in the cylinder numbers where Windows should be, so I tried adding (with no format of course) a partition back in for it. No dice. Nothing recognizes it.
I assume I’m now just up the creek. I hate Windows with a passion, so the loss is probably not insurmountable. The one thing I needed it for was to run the lousy Jeppesen Download Manager to update the databases in my plane. I’ll need to locate an alternative now.
Just a warning to others: updating Leap 16.0 on a dual-boot system may arbitrarily destroy Windows on an EFI partition without warning. So maybe don’t do that. Keep Windows on another disk, another computer, or use a VM.
We choose to avoid “duel” booting. Personally, we have a laptop that only has Windows on it, for doing “Windows stuff”. All other machines are openSUSE (Leap).
Have you tried this: do a reboot and tap F12 (or whatever keyboard sequence is used) to go into the machine’s BIOS and navigate to the “Boot options”. Does it offer to boot into Windows??
There have been rare instances where that works … even though when booted in another OS, does not show the existence of an installed Windows.
Forgot to mention that. Among the many different things I tried to do to fix it was to use F12 to get the boot menu. No joy there – the only options left are EFI boot into Linux. The Windows option is gone from there as well. It’s really just plain old gone.
Agreed that “duel” booting is mostly bad news. The only upside here is that I haven’t lost much other than the time installing JDM and making it marginally useful. (Not that Windows is ever actually in any sense “useful.”)
I’ve filed a bug for this as requested. I guess my main point of surprise here was that I certainly was not expecting to have “zypper dup” or any component of packaging mess with the disk partitioning. Sure, I can see how it’d regenerate GRUB2 and do all sorts of other system-level tweaking, but this one was a bit of a shocker. No idea which wayward package did this (and I’m just guessing that it’s a packaging script gone wild), but it certainly shouldn’t happen.
There has been an issue with the Leap 16 release pipeline since April 9th, but unfortunately, no one has communicated about it.
No updates have been released in OSS since April 9th, and some users are experiencing problems due to unmet dependencies.
According to Marcus Meissner, the issue was resolved on Wednesday 15th, but on Friday, the pipeline was still blocked. This was still the case on Sunday evening.
In the meantime, I think it is safer not to carry out any updates or upgrades, as this may disrupt the system.
That seems like a good idea to me as well. The more I think about it, the more I’m puzzled by a zypper dup doing anything with partitions; I’ve never seen or heard of it messing with partition layouts at all.
Great. This is already the third time this error has occurred since the release of 16.0. And the third time we’ve received no information about it.
It can happen once. Maybe even a second time. But not a third time. And never any information.
In my opinion, this is a security vulnerability, because updates addressing such a vulnerability logically won’t get through either.
I’ve updated the bugzilla report. I no longer trust the hardware itself. I’m now getting I/O errors out of that NVME drive, and after swapping with a spare drive, I can’t reproduce anything like this. I can’t say with any certainty now that this wasn’t just due to bad hardware – it may well be happenstance that I was upgrading Leap when the problem happened.
I agree completely that there ought to be no way at all that any packaging script should be able to touch partitions. Of course, they “could” – it’s just a series of scripts that run with privileges – but I can’t show that anything like this actually happened.
I’m going to put the drive in another machine and see if I can find out what went wrong with it. It’s possible that it’s just plain dead, as NVMEs seem to have hard-to-manage failure behaviors.