On 16 Sep 2016, at 07:51, Takashi Iwai
wrote: On Fri, 16 Sep 2016 00:25:42 +0200, Alexander Graf wrote:
[...] How many "customers" does Leap 42.1 aarch64 have? I thought it's a tech preview, experiment, unsupported port, whatever? [...]
If someone opts for a stable release then I'd think that choice is made on the reasonable assumption or "promise" that they can upgrade to the next stable release either when the new one gets released or before the old one goes out of updates. That has exactly nothing to do with whether it's a main architecture or a port.
Also note that there were aarch64 13.1 and 13.2 before 42.1 already.
We could have a patch like the one below in the kernel pre-install script, preventing people from breaking their systems, add notes on the wiki, maybe ask SoftIron to send emails to people who bought systems with Tumbleweed/42.1 preinstalled and then close that horrible chapter forever.
Note that your patch does not address the 42.2 installer, whose kernel and initrd to not get installed by rpm.
It does, because the 42.2 installer wouldn’t be able to mount the btrfs volume.
That's not addressing anything, that's the status quo. If we decide that
Yes, but at least that means that even without any effort or code changes, users won’t break their systems by upgrading via the iso path, so it’s not as bad as could be.
btrfs upgrade will be unsupported (as opposed to just not taking any decision as before) then the installer would need to detect the mismatch and inform the user in a meaningful way why it's not possible and what they should do instead - cancel the installation, reboot into the previous system, back up the data and do a clean installation. Not just leave the user silently without an upgrade option.
I agree that that would be the better option, but we would need to write the code for that and push it into the installer ;). Or we just document it on the wiki, be vocal about it and hope that not too many people run into it.
Another option would be to provide a driver update disk (DUD) containing btrfs-64k-kmp or create a new ISO containing the KMP. Besides that, you'd have to install btrfs kmp as well in the updated system, and this means that we still need some other changes in the installer side, too (or maybe hacking in kiso?)
However, the biggest concern is the quality and the maintenance of btrfs-64k-kmp. We'd have to maintain it as long as 42.2 is alive, and this is a significant burden. So, I don't think it's a good way to go. I suggested just as a discussion material.
Yes, the more people actually look at the patches the more I get the feeling that it’s not a supportable path ;).
Any other userspace packages that may require a rebuild if changed?
Nope.
Is that an assumption or did you really check? :) In particular does this affect the installed headers (glibc-linux-devel?), or just anything that requires kernel-source directly?
All user space applications *should* work unchanged. If they don’t, it’s a clear bug - but I am not aware of any atm. The kernel headers are all page size agnostic.
Well, at least there is one bug in Qt5 QML where it crashes with 48bit VA (boo#989341). But the fix patches are floating around upstream, so we may give it a try.
Not going 48 bits again diverges from the parent code base, so I don’t think it’s a smart move. Worst case, it would bite us again in package hub. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org