[opensuse-arm] openSUSE AArch64, 64k vs 4k PAGE_SIZE
Hello fellow openSUSE ARM developers, As you might have realized, we haven’t published openSUSE Tumbleweed in quite some time. The biggest reason for that (among minor hickups) is that we’re using btrfs on 64k PAGE_SIZE, which started to have massive disk space requirements (1GB of data doesn’t fit in an 8GB partition). We also in between benchmarked 64k vs 4k intensively and concluded that 4k PAGE_SIZE is the much better option, so we’re at 4k with the Leap 42.2 backing kernel tree. 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. 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? 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. Keep in mind that non-btrfs and 32bit installations are completely untouched by any of this. I’m sure we would lose one or two users, but I’d rather have that than spend more time not publishing images and keeping us from doing a future-looking 42.2 release which would drive us into a corner that makes us lose even more. For reference, there’s a bugzilla about this atm as well: http://bugzilla.opensuse.org/show_bug.cgi?id=998663 Alex diff --git a/rpm/pre.sh b/rpm/pre.sh index f02d9c0..347b0d4 100644 --- a/rpm/pre.sh +++ b/rpm/pre.sh @@ -19,3 +19,22 @@ if [ @BASE_PACKAGE@ = 1 -a "$YAST_IS_RUNNING" != "" ]; then fi fi fi + +# On AArch64 we switched from 64k PAGE_SIZE to 4k PAGE_SIZE. Unfortunately +# btrfs can only use file systems created with the same PAGE_SIZE. So we +# check if the user has any btrfs file systems mounted and refuse to install +# in that case. +if [ $( uname -m ) = aarch64 -a "$( zgrep CONFIG_ARM64_64K_PAGES=y /proc/config.gz )" ]; then + if cut -d ' ' -f 3 /proc/mounts | grep -q btrfs; then + echo "You are using btrfs on a 64kb PAGE_SIZE kernel. This" >&2 + echo "kernel switched to 4kb PAGE_SIZE which will prevent" >&2 + echo "it from mounting that file system." >&2 + echo >&2 + echo "Refusing from installing this kernel, to make sure you" >&2 + echo "do not end up with an unusable system. If you want to" >&2 + echo "install it, please convert the btrfs file system to a" >&2 + echo "different file system." >&2 + + exit 1 + fi +fi-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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!
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. 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? 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. 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.) 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? Any other userspace packages that may require a rebuild if changed? In general, please keep in mind that with an Open Source project like this you never have full information about your users. Not every user is subscribed to this list. Not every user subscribed will be reading questions timely, in particular given that 42.2 Beta 2 checkin is today already. Which was my main concern, after this topic already missing Beta 1. 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
On 15 Sep 2016, at 15:49, Andreas Färber <afaerber@suse.de> 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
Am 15.09.2016 um 16:55 schrieb Alexander Graf:
On 15 Sep 2016, at 15:49, Andreas Färber <afaerber@suse.de> 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
On 15 Sep 2016, at 17:41, Andreas Färber <afaerber@suse.de> wrote:
Am 15.09.2016 um 16:55 schrieb Alexander Graf:
On 15 Sep 2016, at 15:49, Andreas Färber <afaerber@suse.de> 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 Thu, Sep 15, 2016 at 03:49:33PM +0200, Andreas Färber wrote:
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.
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?
The easiest and safest way to change the blocksize is to create a new image and tar/rsync the data there. Doing this kind of change in-place would be tricky and not guaranteed to succeed anyway (eg. if there's not enough temporary space). -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 15 September 2016 at 13:47, Alexander Graf <agraf@suse.de> wrote:
Hello fellow openSUSE ARM developers,
As you might have realized, we haven’t published openSUSE Tumbleweed in quite some time. The biggest reason for that (among minor hickups) is that we’re using btrfs on 64k PAGE_SIZE, which started to have massive disk space requirements (1GB of data doesn’t fit in an 8GB partition).
We also in between benchmarked 64k vs 4k intensively and concluded that 4k PAGE_SIZE is the much better option, so we’re at 4k with the Leap 42.2 backing kernel tree.
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.
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? 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.
I am all for switching to 4k. Yes we will certainly inconvenience some users, but as long as we communicate what is happening and why I see no reason for any genuine complaints. One of the big reasons for Leap is to close the gap between openSUSE and SLE; by continuing with having a separate page size we are increasing the maintenance burden on the kernel team as well as diverging from the goals of the distro. Regardless of the complications that switching page size brings, technically 64k is the wrong choice for general purpose compute. It actually hinders things and degrades performance with zero gain. We will be doing hardware vendors that ship openSUSE a favour by switching. Regards, Andy
Keep in mind that non-btrfs and 32bit installations are completely untouched by any of this.
I’m sure we would lose one or two users, but I’d rather have that than spend more time not publishing images and keeping us from doing a future-looking 42.2 release which would drive us into a corner that makes us lose even more.
For reference, there’s a bugzilla about this atm as well: http://bugzilla.opensuse.org/show_bug.cgi?id=998663
Alex
diff --git a/rpm/pre.sh b/rpm/pre.sh index f02d9c0..347b0d4 100644 --- a/rpm/pre.sh +++ b/rpm/pre.sh @@ -19,3 +19,22 @@ if [ @BASE_PACKAGE@ = 1 -a "$YAST_IS_RUNNING" != "" ]; then fi fi fi + +# On AArch64 we switched from 64k PAGE_SIZE to 4k PAGE_SIZE. Unfortunately +# btrfs can only use file systems created with the same PAGE_SIZE. So we +# check if the user has any btrfs file systems mounted and refuse to install +# in that case. +if [ $( uname -m ) = aarch64 -a "$( zgrep CONFIG_ARM64_64K_PAGES=y /proc/config.gz )" ]; then + if cut -d ' ' -f 3 /proc/mounts | grep -q btrfs; then + echo "You are using btrfs on a 64kb PAGE_SIZE kernel. This" >&2 + echo "kernel switched to 4kb PAGE_SIZE which will prevent" >&2 + echo "it from mounting that file system." >&2 + echo >&2 + echo "Refusing from installing this kernel, to make sure you" >&2 + echo "do not end up with an unusable system. If you want to" >&2 + echo "install it, please convert the btrfs file system to a" >&2 + echo "different file system." >&2 + + exit 1 + fi +fi-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Alex, 2016-09-15 13:47 GMT+02:00 Alexander Graf <agraf@suse.de>:
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.
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. 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. Greetings, Dirk -- 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 <agraf@suse.de>:
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
Hi Alex, 2016-09-19 10:32 GMT+02:00 Alexander Graf <agraf@suse.de>:
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.
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 to convince it to not fail to boot just because swap isn't there.
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, yast2-bootloader seems broken again. I fixed ovmf over the weekend finally. Greetings, Dirk -- 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 <agraf@suse.de>:
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
On Thu, Sep 15, 2016 at 01:47:11PM +0200, Alexander Graf wrote:
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.
The page size is used automatically at the mkfs time and stored independently as 'sectorsize'. The on-disk format does not depend on any runtime variables, it's the other way around (ie. runtime must support the on-disk values). -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (5)
-
Alexander Graf -
Andreas Färber -
Andrew Wafaa -
David Sterba -
Dirk Müller