On 15 Sep 2016, at 15:49, Andreas Färber wrote:

Hi Alex,

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 am opposed for Tumbleweed.

And 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. But if I get the chance of breaking a small user base and instead have the overall product work again and be consistent, I can’t shake off the feeling that breaking is the better option.

...

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.

I would be okay for Tumbleweed iff instead of that horrible blocker patch we could get a patch for, e.g., dracut to convert the volume from 64k to 4k on boot if necessary, keeping zypper dup working that way. Is there no FUSE implementation or some btrfs(8) subcommand to change the blocksize without having to mount it in the kernel?

Unfortunately it’s not easy to pull off :(.

Also, didn't you suggest using a KMP with patched btrfs module, to abstract the page size? I thought that was your designated solution for at least Tumbleweed.

Yes, and nobody wants to actively support it, pushing us into an even worse corner where we’d end up with lots of ARM special cases that nobody else wants to look at. It means more work on our shoulders that we can’t cope with.

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.

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. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 15 Sep 2016, at 17:41, Andreas Färber wrote:

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

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.

...

...

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.

Yup. However, most devboards will not be using btrfs on aarch64 - mostly because we don’t officially support any devboards there atm ;). But even if you had assembled a system by hand, chances are very low you did that on btrfs, so you’re safe.

...

...

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?

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. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 16.09.16 17:35, Dirk Müller wrote:

Hi Alex,

2016-09-15 13:47 GMT+02:00 Alexander Graf :

...

However, 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.

It is not only btrfs, but also swap. But the latter problem can be solved easier. In addition, switching to 4k also enables 48bit VA, which opens another can of worms.

Yes, but it's a can of worms that we have to open anyway unfortunately. Systems are growing and I doubt 42 bits are going to get us very far.

...

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?

Are we talking about 42.2 or tumbleweed ? I'm sort of okay with doing that for 42.2 when we document it properly and mayb ealso fix the swap issue. Because I seriously hope not that many people are using btrfs.

You mean if you're on an ext4 rootfs and upgrade to 42.2, swap should stay working? Any constructive ideas?

For tumbleweed, I would only want to switch when we have sorted out the remaining issues. And only because I am going to be hit by this badly.

What are "the remaining issues"? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 19.09.16 13:21, Dirk Müller wrote:

Hi Alex,

2016-09-19 10:32 GMT+02:00 Alexander Graf :

...

Yes, but it's a can of worms that we have to open anyway unfortunately. Systems are growing and I doubt 42 bits are going to get us very far.

sure, I still prefer to have tests, and even tests that are passing over just enablign something and then not fixing it.

So can we install with btrfs and 64k yet?

...

...

Are we talking about 42.2 or tumbleweed ? I'm sort of okay with doing that for 42.2 when we document it properly and mayb ealso fix the swap issue. Because I seriously hope not that many people are using btrfs. You mean if you're on an ext4 rootfs and upgrade to 42.2, swap should stay working? Any constructive ideas?

Well, the problem is that boot completely fails since systemd considers a non-mountable swap a fatal error condition, and you can not easily recover from that if you don't have serial console. swapon --fixpgsize is to the rescue though. Alternatively we could try

So I crawled through systemd and util-linux sources a bit. Systemd does not know anything about a "-f" option to swapon. The only thing it can do is pass -o parameters from fstab to swapon. Swapon on the other hand has -o mappings for a good chunk of its parameters, but not for fixpgsize. So the parameter is not reachable with -o. That means we can a) Patch systemd to pass -f on aarch64 b) Patch util-linux to allow passing -f in -o and modify fstab (how?) Preferences?

to convince it to not fail to boot just because swap isn't there.

There is a -o option called "nofail". But reading the source I don't think it actually doesn't fail. It only doesn't fail if the target path doesn't exist, not if it's unusable.

...

...

For tumbleweed, I would only want to switch when we have sorted out the remaining issues. And only because I am going to be hit by this badly What are "the remaining issues"?

48 bit,

What is missing apart from qt5 which has a patch available?

yast2-bootloader seems broken again.

What exactly?

I fixed ovmf over the weekend finally.

Cool. What did you do? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org