> On 16 Sep 2016, at 07:51, Takashi Iwai <[email protected]> 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: [email protected] To contact the owner, e-mail: [email protected]
