Testing with the debian-testing-ppc64el-DVD-1.iso confirms that Debian
Trixie on ppc64el currently installs a 4KB page kernel by default. This
default (ref: #1074217) causes issues, especially for KVM virtualization
(e.g., "Can't support 64 kiB guest pages with 4 kiB host pages"),
hindering common ppc64el use cases. Debian Trixie should offer easier
access to a 64KB page size kernel.

While 64KB kernel variants, such as those provided by the
linux-image-powerpc64le-64k meta-package, are available in the Trixie
archive, their manual installation post-setup is inconvenient.

Request:

Make a 64KB page kernel the default for ppc64el Trixie.
OR

Add a clear installer option to select a 64KB page kernel.

This would improve usability for ppc64el users needing 64KB pages for
performance or virtualization.



Thanks and Regards,
Trupti

Hi,

Looping in the kernel team.

Trupti <trupti@linux.ibm.com> (2025-05-29):

My reading of debian/config/ppc64el/defines.toml in kernel-team/linux.git
suggests they are responsible for setting up the default, not d-i.

I believe this should be offered in expert mode, have you tried that?


Cheers,

(Removing kernel team)

AFAICS linux-image-powerpc64le-64k is not included in the DVD-1 image,
so it requires a network mirror. Same with linux-image-arm64-16k.

This is a bug in qemu.

We decided to make 4 KiB the default for all architectures.

Bastian

Could you please contact the qemu maintainer via
1107288@bugs.debian.org?  I can only do theoretical work on a fix for
qemu, but you might have access to the hardware as well.

Bastian

https://lore.kernel.org/qemu-devel/aEFwmU8PRo_SxV4T@zatzit/

I definitely don't want to change upstream defaults here.

Maybe qemu upstream can be convinced to change their default
now (in the next version, not in trixie), I dunno.

But I know right to nothing about ppc64 and its page sizes.

Thanks,

/mjt

Okay, so we should remove kvm support from ppc64*, because it is not
supported anymore?

Bastian

And noone asked for changed defaults, just overriding them when it
already saw it will not work.

Bastian

It looked to me as if all you have to do is pass a command line argument
to qemu-kvm telling it to use 4k page size instead of the default 64k.
Doesn't mean it doesn't support kvm.

Changing the default sounds like it could break kvm migration between
hosts.  Perhaps it would be friendly if qemu would detect the page size
doesn't work and print a message telling the user what argument they
have to add to work with 4k page systems.

I can't parse this sentence.

There's an easy way to specify page size for a guest.  I don't see any
reason to disable kvm on ppc.

/mjt

On Thu, 5 Jun 2025 20:41:58 +0300 Michael Tokarev <mjt@tls.msk.ru> wrote:
 > On 05.06.2025 16:15, Bastian Blank wrote:
 > > On Thu, Jun 05, 2025 at 02:13:59PM +0300, Michael Tokarev wrote:
 > >> But I know right to nothing about ppc64 and its page sizes.
 > >
 > > Okay, so we should remove kvm support from ppc64*, because it is not
 > > supported anymore?
 >
 > I can't parse this sentence.
 >
 > There's an easy way to specify page size for a guest. I don't see any
 > reason to disable kvm on ppc.
 >

Right, there are 2 issues(64k page size kernel as default and KVM with
4k kernel and 64k QEMU)
being discussed which aren't necessarily tied together.

While both 4K and 64K page size work on ppc64le, default recommended
page size on ppc64le
is 64k. This is irrespective of KVM being or not. For the record Ubuntu
on Power(and for that matter
other Linux lavors) also defaults to 64K page size and corresponding kernel.

For an out of box experience with Debian on Power, the request in this
defect is for 64k page
size kernel to be made default during installation.

after installing the base system, so they only offer kernel flavours
included in installation images. Only netboot images set up a network
mirror before installing the base system and offer all kernel flavours.

After reading #1079800 ("release-notes - Document that default ppc64el
kernel switched to 4k pages") [1], I thought about possible impact of
page size change on the installer, but do not have any ppc64 or arm64
hardware to test.

[1] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079800>

The kernel supports a swap space only if it matches the page size.
The kernel supports a btrfs filesystem with a sector size equal to the
page size or 4k (aka subpage block size support, see [2][3]).

[2] <https://btrfs.readthedocs.io/en/latest/Subpage.html>
[3]
<https://btrfs.readthedocs.io/en/latest/Status.html#status-subpage-block-size>

Bookworm:
- linux-image-powerpc64le has 64k page size.
- mkswap creates swap with 64k page size.
- mkfs.btrfs creates filesystem with 64k sector size.

Trixie:
- linux-image-powerpc64le has 4k page size.
- mkswap creates swap with 4k page size.
- mkfs.btrfs creates filesystem with 4k sector size.

1) Impact on reuse of existing swap and btrfs filesystem:

The installer can detect (via libparted) and use an existing swap only
if it matches the installer kernel page size (4k). So it cannot use a
swap space created by a previous version with 64k page size without
reformatting it. No big deal though.

The installer can detect (via libparted) an existing btrfs filesystem
regardless of its sector size but can use it only if its sector size is
4k. So it cannot use a btrfs filesystem created by a previous version
with 64k sector size without reformatting it (and losing all its data).

2) Impact if linux-image-powerpc64le-64k (or linux-image-arm64-16k on
arm64) is selected:

systemd.swap seems to run swapon with --fixpgsz which reinitializes the
swap space if it does not match the kernel page size, so swap page size
mismatch should be fixed automatically during first boot.

A kernel with 64k page size is said to support btrfs filesystems with
either 4k or 64k sector size, so it should be able to mount btrfs
filesystems with 4k sector size created by Trixie installer.

Thank you,for the very helpful and detailed analysis of the potential
btrfs and swap incompatibilities.

I do have access to ppc64el VMs and will perform the Bookworm-to-Trixie
test scenario you described.

I will post my findings here shortly.

Thanks Trupti.

Ext* filesystems which have a block size larger than the kernel page
size are also not supported. Big filesystems created with usage type
(-T) "largefile" or "largefile4" might have a block size above 4k when
the page size is 64k. But I do not have any hardware to test it.

Confirming test scenario on ppc64el (Bookworm-to-Trixie installer) for
both Btrfs and Ext4 partitions.

Both the 15GB Btrfs (/dev/sda4) and 30GB Ext4 (/dev/sda5) partitions,
previously created with 64k page size (Bookworm), were recognized by the
Trixie installer. However, neither could be assigned a mount point
without requiring reformatting, implying data loss.

This confirms the page size incompatibility issue for reusing existing
filesystems. Screenshot of these behaviors to follow

Thanks Trupti.

How was the ext4 filesystem created and what was its block size ?
You can see the block size with blkid or tune2fs -l.

The Ext4 filesystem on /dev/sda5 was created using mkfs.ext4 -T
largefile4 /dev/sda5.
Its block size is 64KB.

To clarify how the Ext4 filesystem on /dev/sda5 was created and its
block size, here is the command output used:


"root@debian:/home/usr# /sbin/mkfs.ext4 -T largefile4 /dev/sda5
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 491520 64k blocks and 8192 inodes
Filesystem UUID: 34c23dcc-c08d-4829-bcea-b1d99286a6e0
Superblock backups stored on blocks:
	65528, 196584, 327640, 458696

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done"


Thanks Trupti.

Can you check with "-T largefile" and without -T for completeness ?

Yes, I have performed the additional tests you requested for
completeness.And the block size output for newly created partitions are
as follow:

root@debian:/home/usr# /sbin/tune2fs -l /dev/sda5 | grep "Block size"
Block size:               4096
root@debian:/home/usr# /sbin/tune2fs -l /dev/sda4 | grep "Block size"
Block size:               65536


The results are the same: the Trixie installer was unable to use either
partition without requiring a reformat.

The partition created with -T largefile was incompatible.
The standard ext4 partition created without any -T option was also
incompatible.

This creates a clear risk of data loss for users upgrading from
Bookworm. To ensure a safe user experience, a dedicated 64k installer
image is a necessity. Providing this for Trixie, and making it the
default for future ppc64el releases, would prevent data loss and align
Debian with platform standards.

Thanks Trupti.

Thank you for taking the time to test.

I guess this one was created without -T ?

And this one with "-T largefile" ?

This is expected if the block size is 64k. However I guess -T is not
widely used.

This is unexpected if the block size is 4k, and much more annoying. What
is the error message in kernel log ?

Hello Pascal,

Thank you for following up on this!

  Yes,this was created using the command "mkfs.ext4 /dev/sda5" with 4k
block size.

   Yes, this was created using the command "mkfs.ext4 -T largefile
/dev/sda4" with 64k block
   size.

   Yes, this is the correct behavior of the Trixie installer, as
/dev/sda4 has a 64K block size.

    I was unable to add any mount point and also needed to format the
partition in order to use
    it.I have attached a screenshot showing the behavior of the Trixie
installer for the /dev/sda5
    partition with a 4K block size.

    Kindly take a look and confirm if this behavior is expected or not.

   Yes, that's correct — the Trixie installer should recognize the
partition and allow it to be
   used as is.However, it is displaying different behavior in this case.

   I have checked and did not find any errors.
   For your reference, I have attached the kernel log file along with the
tune2fs output for the
   /dev/sda5 partition.



Thanks Trupti.

Hello,

My apologies, I realize my previous reply was incomplete. Please find
all the requested information below.

Thanks Trupti.

Hello Pascal,

To complete the end-to-end test scenario, I am now creating test files
on the Bookworm partitions.

I will proceed with the Trixie installation, manually preserving the
partitions, and will then verify the files are intact in the new system.
I will post the final results of this data integrity test here soon.

Thank you.

Hello Pascal,

You were absolutely right — I’ve completed the testing as suggested.

I tested ext4 (4K & 64K) and Btrfs partitions between Bookworm (64K
kernel) and Trixie (4K kernel), and the following behavior was observed:

1]ext4 partitions with 4K block size worked fine — existing files were
accessible without issues.

2]ext4 (64K) and Btrfs partitions couldn’t be mounted in Trixie (showed
a "Mount Failed" error),
   and the installer failed unless those partitions were formatted.


ext4 with a 4K block size is compatible across both kernels. However,
partitions created with a 64K block size (ext4 or Btrfs) are not
supported by the 4K kernel. These need to be formatted during
installation, which can lead to potential data loss.

Thanks Trupti.

[The mail I am replying to was sent to the bug but was not forwarded to
the list for some reason, although its size of 98ko is much smaller than
the previously observed limit of ~450-500ko. You can see it and its
attached screenshot at
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106757#120>]
(...)
- With bookworm d-i and installed system 64k page size kernel,
mkfs.btrfs with default options and mke2fs -T largefile|largefile4
create filesystems with 64k block size.
- With trixie d-i 4k page size kernel, btrfs and ext* with 64k block
size filesystems are not supported and cannot be reused without being
reformatted with 4k block size (and losing data).

Shouldn't it at least be mentioned in ppc64el installation manual ?

Yes, I agree — this behavior should definitely be documented in the
ppc64el installation manual, especially to warn users about the
incompatibility and potential data loss when using ext4 or Btrfs
filesystems with 64k block size on a 4k page-size kernel.

Also, summarizing our discussion here regarding feasible solutions for
users who want to install a 64k page-size kernel from the beginning:

One possible option is to provide a dedicated official 64k ISO for
ppc64el.

Another approach could be to include both 4k and 64k kernel variants in
the same ISO, allowing users to select the preferred option from the
boot menu — similar to what was done in older multi-arch amd64+i386
images.

I kindly request the Debian Installer team to consider implementing one
of these installation options for Debian on PowerPC, so that users who
require a 64k setup can install it safely and directly.


Thanks Trupti

Looping Debian installer team.

Hi Team,

I tested both the “Expert Install” workflow using the Trixie netinst ISO
and the DVD installer for ppc64el. In both cases, only the 4K page-size
kernel was available—there was no option to select the 64K kernel. As
Pascal noted, the installer can only offer kernels that are already
present on the ISO.

Could you please include the linux-image-ppc64le-64k package on the
ppc64el installation ISOs for Trixie? This change would enable users to
choose the 64K kernel directly during installation and ensure a smoother
out-of-the-box experience on Power hardware.

Thanks Trupti

Hi Trupti,

A small side note (just in case) because I got the impression that you
(and others at IBM) are not fully aware that Debian doesn't expect you
to use the Debian Installer to do system upgrades. We expect people to
just change the apt sources and run (a variant of) $(apt full-upgrade).

Paul

Hi Paul,

Thanks for the suggestion.

I upgraded my system from Bookworm to Trixie using apt full-upgrade. The
system is now running Trixie, but it's still using the old Bookworm
kernel (6.1.0-37-powerpc64le).

Is there a way to make sure the system automatically installs and uses
the latest 64K kernel during the upgrade?

Thanks Trupti

Hi,


Did you reboot? Can you check what you have in /boot?


Currently only by installing the non-default kernel. Because the default
upgrade path should install the 4k kernel.

Paul

Yes, I did reboot after the full upgrade. The system is now running the
Trixie kernel, but it’s still using the default 4K page size. My goal
was to upgrade to Trixie with the 64K kernel, but the upgrade path
installs only the 4K kernel by default, and switching to 64K requires
manually installing the linux-image-powerpc64le-64k package.

This isn’t just about avoiding manual steps — as mentioned earlier, 64K
is the recommended page size for ppc64el, and other distributions like
Ubuntu already use it by default on Power.

As Pascal pointed out earlier, offering this choice in the installer
(e.g., via expert install) would require including the 64K kernel
packages in the ISO image itself. That’s why I’m requesting that the 64K
kernel be included in the installation images — so users can choose
between kernel flavours at install time without needing post-install
steps. It would be helpful if this could be considered for future Debian
releases.


Thanks Trupti.

Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-05-29):

I suppose something like this might do the trick?

    kibi@tokyo:~/debian-cd/debian-cd.git (kibi/easy)$ git diff
    diff --git a/tools/generate_di+k_list b/tools/generate_di+k_list
    index 2bee6440..9801b932 100755
    --- a/tools/generate_di+k_list
    +++ b/tools/generate_di+k_list
    @@ -305,6 +305,7 @@ grub-ieee1275
     powerpc-utils
     powerpc-ibm-utils
     linux-image-powerpc64le
    +linux-image-powerpc64le-64k
     #endif

     #ifdef ARCH_alpha

This might push other packages out of the netinst though.

Cc-ing debian-cd@, who is responsible for installation images.


Cheers,

I suppose so, if it pulls dependencies in.

Trxie RC2 ppc64el netinst image size is only 545 MiB, so I suppose there
is still some room on a CD (650 MiB) ? However it might push other
packages out of the DVD-1 image.

Hi Trupti,


Debian did so to *until* trixie. So, are you also discussing this with
the kernel maintainers? If so, can you link the discussion to me please?
A merge request to the release notes [1] suggest the kernel maintainers
thought about the switch, so it seems like you're not well aligned with
them or just have a disagreement about what should be the
recommendation. Please feel free to (also) comment on that merge request.

Paul

[1] https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/292

Hey folks,

Sorry for the delayed response - catching up on sleep after debconf.

Yeah, that patch is the obvious thing here. On the ppc64el netinst I
think we have plenty of space.

I'll tah that now and trigger a test build.

could you grab the latest faily netinst and see if that works better
for you now please?

Hello Steve,

Thank you so much for adding the extra kernel.

I will check with the new daily netinst image and let you know the
results as soon as possible.

Best regards,
Trupti

Hello,

I tried installing Trixie using the Expert Install option with the
latest daily netinst image, and I was able to select the 64K kernel
right from the start of the installation. It's working now.

Thanks again for providing this option!

Best Regards
Trupti.