Am 15.09.2016 um 16:55 schrieb Alexander Graf:
On 15 Sep 2016, at 15:49, Andreas Färber
wrote: Am 15.09.2016 um 13:47 schrieb Alexander Graf:
[...] because we have people who have Leap 42.1 and current Tumbleweed installed, we can’t just switch from 64k to 4k PAGE_SIZE, because our friend btrfs embeds the page size into its on-disk format and can only read it when they’re identical. So switching would break existing btrfs installations.
There hasn’t been any well working solution to make btrfs more compatible, we don’t really want 42.2 to diverge from its origins and 4k gets us running on smaller systems which are starting to pop up more and more in the 64bit world. Given all that, is anyone seriously opposed to switching everything to 4k? [...] I already expressed deep concerns about 42.2 despite not affected myself: In particular I find it very troubling that some people including Ludwig himself are now in hindsight degrading our stable 42.1 release to some experimental thing that supposedly no one has installed or cares about - then we don't need a 42.2 release either and could focus our efforts on Tumbleweed instead!
I don’t think anyone in this group degraded the stability of 42.1. [...]
I was referring to the release manager in Bugzilla:
[...] 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 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.
For Tumbleweed I think it's reasonable to expect people to do a zypper dup instead of .iso upgrade.
(No, there are not JeOS images for every platform, and even if there were, not everyone wants to loose all their data and the currently well working upgrade path.)
Again, the iso upgrade path doesn’t work because the installations system would be 4k based.
Yes, exactly. Once again I am simply reminding you that not everyone wants to overwrite their whole disk with a new JeOS image all the time like you personally seem to do on your devboards - most users do have data on their devices and care about upgrade paths. For example, I switched to EFI boot without taking your new Raspberry Pi images, implemented first the /boot/vc and not the %post copy support, manually repartitioned on some other devices, left boot.scr on others.
How does GRUB2 deal with btrfs page size? Does it need to get reinstalled after switching kernel page size or does it use a "better" driver implementation than the kernel?
IIUC it just works - we’re using it with both 4k and 64k systems today.
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? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org