Raptor Computing Systems Community Forums (BETA)
Software => Operating Systems and Porting => Topic started by: Hasturtium on December 13, 2023, 10:17:19 am
-
I am debating jumping from Fedora to Debian on my Blackbird machine, which would coincide with a nice storage upgrade. I've had plenty of Debian/Ubuntu family experience on x86 so that part doesn't give me heartburn, but there are a few questions I'd like to have answered before I make the switch.
- Does the stock kernel for Bookworm work with RDNA2 Radeons? What should I do to prevent Debian from trying to use the BMC video versus my RX 6600? (IIRC it installs kernel 6.1 but I don't know what the current version they're providing is - I assume it'll Just Work, outside of possibly coaxing x.org to properly init the Radeon with a config file)
- Are there any snafus or gotchas beyond what MauryG5 has experienced in this thread?
- Is Chromium actually working and installable?
-
Have another computer handy because Debian still have not readded the ast module for initramfs to their installation images.
Have a look at the wiki (https://wiki.raptorcs.com/wiki/Operating_System_Specific_Workarounds/Debian#Blank_VGA). You'll need to set console=hvc0 to grub cmd line and conduct the TUI installer from another machine through obmc-console-client. Huge PITA, but worth it to have Debian IMO.
-
Hi Hasturtium, I have been using Debian for a few years now and I must say that I have now found my ideal size on Power. As for the various things you want to know, Chromium I can confirm that it is stable and works perfectly, in fact, Debian has been the starting operating system for Chromium on Power for some time now as Raptor develops it officially on Debian and updates it regularly and punctually. As for the rdna2 graphics card, I know that from Kernel 6.2 onwards, it is regularly supported and works without problems. Friend TLE has been using a Radeon 6600 for some time now with success. I currently still use an XT5700 and therefore the previous generation but in any case I compile the Kernel myself to keep it always updated to the latest version and in fact I have recently compiled and installed 6.6.5. To make it work regularly you need 3 things on Debian, 1 the Kernel from version 6.2 or higher, 2 the updated Debian firmware and then lastly the file called XORG.CONF set in the correct way so as to tell Xorg that you are using an external graphics card instead of internal AST.
-
Did anybody ever ask other Debian kernel people about integrating my patch in the official kernel packages?
I've updated the 4k kernel patch to work with Debian 12
It is on this branch (https://gitlab.com/dpocock/linux-kernel-debian/-/tree/pocock/bookworm-ppc64el-4k) in a repository that is forked from the official Debian kernel packaging repository. I've kept the change set as minimal as possible so it is very easy to diff it against the official kernel and see that it is just the page size config option changing.
To make it compile, I had to include one extra patch, the patch from Debian bug #996170 (https://bugs.debian.org/996170).
Any feedback is welcome whether you are running the 64k or the 4k kernel
This is where I posted the full set of commands for compiling a Debian kernel with the patch (https://forums.raptorcs.com/index.php/topic,200.msg1460/topicseen.html#msg1460)
-
Using the Debian 12 (bookworm) kernel 6.1 package with 4k page size I started getting errors in the log and eventually Firefox would freeze and the whole GUI (GNOME desktop) would freeze. The system is still accessible over SSH.
After the first crash, I started radeontop and noticed up to 80% GPU VRAM utilisation with Firefox running.
I rebooted into the kernel from bullseye (5.10.46-4.1 built from my 4k page size branch), running with the Debian 12 filesystem and it is running fine, no crashes. I have had that kernel running for months on end on this platform using the bullseye filesystem.
I'm going to build the 6.7.12 kernel backport for bookworm with the 4k page size and try that as well.
journalctl captures a lot of errors like this, sometimes they appear for hours before it eventually crashes. I was able to repeat the crash a couple of times.
I see it as a good thing that the platform is still responding over SSH even when the GUI has crashed.
kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory for command submission!
kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory for command submission!
kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Not enough memory for command submission!
...
The crash is captured too:
kernel: ------------[ cut here ]------------
kernel: WARNING: CPU: 5 PID: 6577 at drivers/gpu/drm/ttm/ttm_bo.c:357 ttm_bo_release+0x538/0x5b0 [ttm]
kernel: Modules linked in: xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge snd_seq_dummy snd_hrtimer snd_seq rfkill qrtr 8021q garp stp mrp llc overlay sunrpc binfmt_misc ext4 crc16 mbcache jbd2 uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio snd_hda_codec_hdmi videobuf2_v4l2 videobuf2_common snd_usbmidi_lib snd_hda_intel snd_rawmidi snd_intel_dspcfg videodev snd_seq_device evdev joydev snd_hda_codec mc snd_hda_core snd_hwdep snd_pcm sg snd_timer snd ofpart soundcore ipmi_powernv powernv_flash ctr ipmi_devintf at24 vmx_crypto mtd regmap_i2c ipmi_msghandler gf128mul opal_prd parport_pc lp parport fuse configfs loop ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress xts ecb uas usb_storage dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic
kernel: raid1 raid0 multipath linear md_mod hid_generic usbhid hid sd_mod amdgpu gpu_sched drm_buddy i2c_algo_bit drm_display_helper drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt xhci_pci fb_sys_fops xhci_hcd nvme nvme_core t10_pi tg3 drm mpt3sas crc64_rocksoft_generic usbcore crc64_rocksoft crc_t10dif crct10dif_generic crc64 crct10dif_common drm_panel_orientation_quirks raid_class libphy usb_common scsi_transport_sas
kernel: CPU: 5 PID: 6577 Comm: Renderer Not tainted 6.1.0-21-powerpc64le-4k #1 Debian 6.1.90-1.1
kernel: Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1203 opal:skiboot-9858186 PowerNV
kernel: NIP: c00800000f4d2120 LR: c008000012fe7270 CTR: c00800000f4d2198
kernel: REGS: c00020001bc571d0 TRAP: 0700 Not tainted (6.1.0-21-powerpc64le-4k Debian 6.1.90-1.1)
kernel: MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 84824244 XER: 20040036
kernel: CFAR: c00800000f4d1c34 IRQMASK: 0
GPR00: c008000012fe7270 c00020001bc57470 c00800000f508800 c0000003b100c5c0
GPR04: 0000000000000000 0000000ffcac0000 0000000000041a8b 0000000000000000
GPR08: 0000000000041a8a c00020001af87738 0000000000000000 c008000013564c90
GPR12: c00800000f4d2198 c000000ffffdbf00 c00020001b054b80 c0002000ef821798
GPR16: 00000000002c6800 0000000000000001 0000000000000000 0000000000000000
GPR20: 00000000002c6880 c000200015080000 0000000000000071 00000000002c6800
GPR24: 0000000000000003 c00020001af87010 0000000000000000 000000003ee00000
GPR28: c0000003b100c458 c000200015080000 c000200015085508 c0000003b100c5c0
kernel: NIP [c00800000f4d2120] ttm_bo_release+0x538/0x5b0 [ttm]
kernel: LR [c008000012fe7270] amdgpu_bo_unref+0x38/0x60 [amdgpu]
kernel: Call Trace:
kernel: [c00020001bc57470] [c00800000f4d1f18] ttm_bo_release+0x330/0x5b0 [ttm] (unreliable)
kernel: [c00020001bc57500] [c008000012fe7270] amdgpu_bo_unref+0x38/0x60 [amdgpu]
kernel: [c00020001bc57530] [c0080000130105fc] amdgpu_vm_ptes_update+0xc24/0xc60 [amdgpu]
kernel: [c00020001bc576a0] [c00800001300935c] amdgpu_vm_update_range+0x304/0x880 [amdgpu]
kernel: [c00020001bc577c0] [c008000013009f04] amdgpu_vm_bo_update+0x2ec/0x630 [amdgpu]
kernel: [c00020001bc578e0] [c008000012ff0bcc] amdgpu_gem_va_ioctl+0x674/0x6b0 [amdgpu]
kernel: [c00020001bc57a20] [c008000012f07040] drm_ioctl_kernel+0x118/0x230 [drm]
kernel: [c00020001bc57a80] [c008000012f073b0] drm_ioctl+0x258/0x560 [drm]
kernel: [c00020001bc57bf0] [c008000012fc00b8] amdgpu_drm_ioctl+0x70/0xd0 [amdgpu]
kernel: [c00020001bc57c40] [c0000000005493f4] sys_ioctl+0x744/0x1460
kernel: [c00020001bc57d40] [c00000000002afd8] system_call_exception+0x138/0x260
kernel: [c00020001bc57e10] [c00000000000c0f0] system_call_vectored_common+0xf0/0x280
kernel: --- interrupt: 3000 at 0x7fff8eb4433c
kernel: NIP: 00007fff8eb4433c LR: 00007fff8eb4433c CTR: 0000000000000000
kernel: REGS: c00020001bc57e80 TRAP: 3000 Not tainted (6.1.0-21-powerpc64le-4k Debian 6.1.90-1.1)
kernel: MSR: 900000000280f033 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 44224840 XER: 00000000
kernel: IRQMASK: 0
GPR00: 0000000000000036 00007fff75b9bb20 00007fff8ec56f00 0000000000000053
GPR04: 00000000c0286448 00007fff75b9bc00 0000000000280000 00000002c5a00000
GPR08: 0000000000100000 0000000000000000 0000000000000000 0000000000000000
GPR12: 0000000000000000 00007fff75ba68c0 00007fff75b9c028 00007fff75b9c178
GPR16: 00007fff75b9c508 0000000000000001 0000000000020000 00007fff75b9cd18
GPR20: 0000000000000001 0000000000020000 00007fff75b9be80 0000000000ea0000
GPR24: 0000000000000000 0000000000200000 0000000000000004 0000000000200000
GPR28: 0000000000000053 00000000c0286448 00007fff75b9bc00 00007ffefa5ca0a0
kernel: NIP [00007fff8eb4433c] 0x7fff8eb4433c
kernel: LR [00007fff8eb4433c] 0x7fff8eb4433c
kernel: --- interrupt: 3000
kernel: Instruction dump:
kernel: 4bfffe30 60000000 60000000 60420000 0fe00000 7c0802a6 fb610068 fba10078
kernel: f80100a0 60000000 60000000 60420000 <0fe00000> 4bffffe0 60000000 60420000
kernel: ---[ end trace 0000000000000000 ]---
kernel: [drm:amdgpu_gem_va_ioctl [amdgpu]] *ERROR* Couldn't update BO_VA (-12)
kernel: Kernel attempted to read user page (0) - exploit attempt? (uid: 1000)
kernel: BUG: Kernel NULL pointer dereference on read at 0x00000000
kernel: Faulting instruction address: 0xc008000012fe8f30
kernel: Oops: Kernel access of bad area, sig: 11 [#1]
kernel: LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV
kernel: Modules linked in: xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge snd_seq_dummy snd_hrtimer snd_seq rfkill qrtr 8021q garp stp mrp llc overlay sunrpc binfmt_misc ext4 crc16 mbcache jbd2 uvcvideo videobuf2_vmalloc videobuf2_memops snd_usb_audio snd_hda_codec_hdmi videobuf2_v4l2 videobuf2_common snd_usbmidi_lib snd_hda_intel snd_rawmidi snd_intel_dspcfg videodev snd_seq_device evdev joydev snd_hda_codec mc snd_hda_core snd_hwdep snd_pcm sg snd_timer snd ofpart soundcore ipmi_powernv powernv_flash ctr ipmi_devintf at24 vmx_crypto mtd regmap_i2c ipmi_msghandler gf128mul opal_prd parport_pc lp parport fuse configfs loop ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress xts ecb uas usb_storage dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic
kernel: raid1 raid0 multipath linear md_mod hid_generic usbhid hid sd_mod amdgpu gpu_sched drm_buddy i2c_algo_bit drm_display_helper drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt xhci_pci fb_sys_fops xhci_hcd nvme nvme_core t10_pi tg3 drm mpt3sas crc64_rocksoft_generic usbcore crc64_rocksoft crc_t10dif crct10dif_generic crc64 crct10dif_common drm_panel_orientation_quirks raid_class libphy usb_common scsi_transport_sas
kernel: CPU: 4 PID: 6567 Comm: firefox-es:cs0 Tainted: G W 6.1.0-21-powerpc64le-4k #1 Debian 6.1.90-1.1
kernel: Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1203 opal:skiboot-9858186 PowerNV
kernel: NIP: c008000012fe8f30 LR: c008000013030f54 CTR: c00000000098c350
kernel: REGS: c000200033e2ae10 TRAP: 0300 Tainted: G W (6.1.0-21-powerpc64le-4k Debian 6.1.90-1.1)
kernel: MSR: 900000000280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24224244 XER: 200400dd
kernel: CFAR: c008000013030f50 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
GPR00: c008000013030f54 c000200033e2b0b0 c00800001377c600 c000200015085508
GPR04: c0000003b100c400 0000000000000000 000000003ee00000 0000000000000080
GPR08: 0000000000001000 0000000000000000 c0000003cce4e800 c008000013565488
GPR12: c00000000098c350 c000000ffffdcc00 00000000002c6880 00000000002c6880
GPR16: 0000000000080000 c0000003b100c400 0000000000001000 c000200033e2b408
GPR20: 0000000000000000 c000200015080000 c0000003b100c400 0000000000000000
GPR24: 000000003ee00000 c0000003cce4e800 00000000000003f1 0000000000001000
GPR28: 000000003ee00000 c000200033e2b3e8 0000000000000080 0000000000000000
kernel: NIP [c008000012fe8f30] amdgpu_bo_gpu_offset_no_check+0x28/0x78 [amdgpu]
kernel: LR [c008000013030f54] amdgpu_vm_sdma_set_ptes+0x5c/0x1b0 [amdgpu]
kernel: Call Trace:
kernel: [c000200033e2b0b0] [c000200033e2b110] 0xc000200033e2b110 (unreliable)
kernel: [c000200033e2b0e0] [c008000013030f54] amdgpu_vm_sdma_set_ptes+0x5c/0x1b0 [amdgpu]
kernel: [c000200033e2b150] [c00800001303195c] amdgpu_vm_sdma_update+0x3b4/0x440 [amdgpu]
kernel: [c000200033e2b220] [c00800001300fd40] amdgpu_vm_ptes_update+0x368/0xc60 [amdgpu]
kernel: [c000200033e2b390] [c00800001300935c] amdgpu_vm_update_range+0x304/0x880 [amdgpu]
kernel: [c000200033e2b4b0] [c008000013009f04] amdgpu_vm_bo_update+0x2ec/0x630 [amdgpu]
kernel: [c000200033e2b5d0] [c008000012ff5a28] amdgpu_cs_ioctl+0x1610/0x22c0 [amdgpu]
kernel: [c000200033e2b880] [c008000012f07040] drm_ioctl_kernel+0x118/0x230 [drm]
kernel: [c000200033e2b8e0] [c008000012f073b0] drm_ioctl+0x258/0x560 [drm]
kernel: [c000200033e2ba50] [c008000012fc00b8] amdgpu_drm_ioctl+0x70/0xd0 [amdgpu]
kernel: [c000200033e2baa0] [c0000000005493f4] sys_ioctl+0x744/0x1460
kernel: [c000200033e2bba0] [c00000000002afd8] system_call_exception+0x138/0x260
kernel: [c000200033e2be10] [c00000000000c0f0] system_call_vectored_common+0xf0/0x280
kernel: --- interrupt: 3000 at 0x7fff8eb4433c
kernel: NIP: 00007fff8eb4433c LR: 00007fff8eb4433c CTR: 0000000000000000
kernel: REGS: c000200033e2be80 TRAP: 3000 Tainted: G W (6.1.0-21-powerpc64le-4k Debian 6.1.90-1.1)
kernel: MSR: 900000000280f033 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 48884842 XER: 00000000
kernel: IRQMASK: 0
GPR00: 0000000000000036 00007fff62bfe1f0 00007fff8ec56f00 0000000000000053
GPR04: 00000000c0186444 00007fff62bfe2f0 0000000000180000 00007fff62bfe478
GPR08: 0000000000100000 0000000000000000 0000000000000000 0000000000000000
GPR12: 0000000000000000 00007fff62c068c0 00007fff7dc86600 0000000000000005
GPR16: 00007fff623f0000 0000000000000001 0000000000000031 0000000000000001
GPR20: fffffffffffffffd 0000000000000000 00007fff59870000 00007fff59860000
GPR24: 00007fff8b4e1000 00007fff62bfe428 00007fff62bfe448 0000000000000000
GPR28: 0000000000000053 00000000c0186444 00007fff62bfe2f0 00007fff62bfe2d0
kernel: NIP [00007fff8eb4433c] 0x7fff8eb4433c
kernel: LR [00007fff8eb4433c] 0x7fff8eb4433c
kernel: --- interrupt: 3000
kernel: Instruction dump:
kernel: 007936f8 00000000 3c4c0079 384236f8 7c0802a6 60000000 7c0802a6 fbe1fff8
kernel: f8010010 f821ffd1 e92301c8 e86301a8 <ebe90000> 80890010 3863aaf8 7bff83e4
kernel: ---[ end trace 0000000000000000 ]---
kernel:
kernel: note: firefox-es:cs0[6567] exited with irqs disabled
-
I took the 6.7.12-1 backport for bookworm and applied the 4k page size patch.
It has the same problem with amdgpu that I saw using the 6.1 kernel with 4k patch. Errors about "Not enough memory for command submission!" and eventually Firefox and the whole desktop freeze.
I pushed each of my branches for anybody else who wants to try it. Maybe it is fine with other GPUs
This is the 4k patch against the 6.7.12-1 kernel on the branch for unstable and testing (https://gitlab.com/dpocock/linux-kernel-debian/-/tree/pocock/sid-ppc64el-4k?ref_type=heads)
The same patch backported for the 6.7.12-1 kernel on bookworm-backports (https://gitlab.com/dpocock/linux-kernel-debian/-/tree/pocock/bookworm-backports-ppc64el-4k?ref_type=heads)
The 6.1 standard kernel branch for bookworm with the 4k page size patch (https://gitlab.com/dpocock/linux-kernel-debian/-/tree/pocock/bookworm-ppc64el-4k?ref_type=heads)
There are various other web sites discussing the error message. Some of them suggest that the amdgpu firmware needs to be updated.
One of them points to a new version of the amdgpu firmware that appeared in the upstream kernel tree in June 2024 (https://gitlab.freedesktop.org/drm/amd/-/issues/3220#note_2463104)
At present, the Debian firmware package still has older amdgpu firmware from 2023 - you can see the current versions here (https://tracker.debian.org/pkg/firmware-nonfree), even unstable hasn't been updated since June 2023.
Here is the packaging repository on Debian Git (Salsa), we can't clearly see the actual versions of the amdgpu firmware files (https://salsa.debian.org/kernel-team/firmware-nonfree/-/tree/master)
-
Sorry but why are you using the 4K page size? AMDGPU drivers have long since eliminated the bug that occurred at the time for the default page sizes used on Power, i.e. 64K. I have long since returned to 64K pages on the Kernel and I have not had any problems for a long time on my Radeon 5700XT. Why do you have to use that size? I still use 11.9 as my Debian version, I have not wanted to update yet because I like Gnome 3.38 better as it is more original in its animations and use, compared to the current Gnome 3.4X... When I am forced to update then I will.
-
4KB page sizes are still required for the nouveau driver, and may be useful in bringing Intel's xe up on ppc64le too. The maintainer of Void Linux stood by the practice too out of personal preference and cross-platform compatibility.
-
I put some of my observations in this blog post (https://danielpocock.com/power9-aarch64-64k-page-sizes/)
The BtrFs issue is particularly annoying if you create a BtrFs using 4k on an external drive or USB stick and you want to attach that drive to a host running the 64k page size.
They made some improvements to BtrFs in more recent kernels but last time I looked at it they still said the combination of 64k page size with 4k BtrFs block size is experimental. Then again, they still tell us the BtrFs itself is experimental.
Porting applications to POWER and porting to 64k are two different problems. Trying to solve them both at the same time in an environment where at least some people are here as hobbyists may be asking too much.
-
I put some of my observations in this blog post (https://danielpocock.com/power9-aarch64-64k-page-sizes/)
The BtrFs issue is particularly annoying if you create a BtrFs using 4k on an external drive or USB stick and you want to attach that drive to a host running the 64k page size.
They made some improvements to BtrFs in more recent kernels but last time I looked at it they still said the combination of 64k page size with 4k BtrFs block size is experimental. Then again, they still tell us the BtrFs itself is experimental.
Porting applications to POWER and porting to 64k are two different problems. Trying to solve them both at the same time in an environment where at least some people are here as hobbyists may be asking too much.
Yeah, I'd forgotten about Btrfs, that's potentially a big one. As a self-avowed hobbyist and minimal dabbler in coding, that much is definitely true.
-
when I had my blackbird I only ever used the 64k page size but I wonder if some applications would've performed better or didn't crash under 4k, this was mostly game software stuff but maybe some other things as well. I suppose i'll mess with it whenever power10 rolls around.
-
Guys sorry, do you think it is possible to manually install Chromium 127 in Debian 11? I am still using 11.9 and I would like to wait a little longer to switch to 12 because I like the Gnome 3.38 version better than 40 and therefore I would like to keep 11.9. Only that I saw that Chromium after version 120, is no longer updated and I saw that now it only comes out on Debian 12. I wrote via Twitter to Rapotor but I never received a response. I was wondering if by downloading and installing it manually, I could put it on 11.9...
-
I tried to compile a 6.11.4 kernel with 4K pages after updating the firmware but it still doesn't work. However, I was unable to update the mesa drivers, it tells me they are up to date but probably another procedure is needed to install them. I then decided to compile a 6.1.114 long-term support kernel and that works fine and I'm using it now while waiting for the problems for the new Kernels to be resolved. I have been able to verify that the problem occurs from version 6.2.X onwards, something has been changed in the Kernel and Debian 12 no longer works. However, the thing that I still don't understand is why Debian 11, which is older, works fine with all Kernels including 6.11.X, while Debian 12 doesn't work... A regression that I don't understand...
-
In order to work 4K from 64K o.s it need recompile Gnu Packages most Mesa.
-
Yet back then when I used the Kernel with 4K pages for a while on Fedora, which also had big problems with the Kernel in 64K version, it was enough to change the setting in the Kernel with 4K pages options and it worked. In any case, the mystery remains of what could have changed from Kernel 6.2.X onwards and what above all was changed in Debian 12 compared to Debian 11, to give these problems now...
-
It is really important for somebody to raise this topic on the relevant Debian mailing list for ppc64 porting (https://lists.debian.org/debian-powerpc/)
Given that I did the work to get the 4k discussion started for both Debian and Fedora (https://danielpocock.com/power9-aarch64-64k-page-sizes/) I would like to raise the topic in the Debian list but some of the non-developing/non-uploading developers are censoring my messages there due to the Debian politics (https://danielpocock.com/debian-history-harassment-abuse-culture-evolution/).
It is really sad that so many people are suffering because of the politics in Debian. It is really bad for people who spent money on the Raptor hardware and it is also really bad for my family, friends, neighbors and many other people who had these political problems forced upon them by the social media set.
-
Daniel I was also thinking of taking the problem directly to the Debian forums at this point, can you tell me which are the main forums where I can write and bring the problem? From what I understand the problem is not only for us on Power but also on other architectures they are having problems with Debian 12 on the new Kernels... This problem must be solved once and for all because it is absurd not to be able to use the new Kernels on the latest version of Debian and then on the old Debian instead everything works perfectly it makes no sense... I updated because now on 11 they do nothing anymore and they don't update almost anything anymore and we are left behind. I like Gnome 3.38 better than 3.4X but unfortunately now we have to use this but at least everything works damn it...
-
I prefer 64K than 4K. I am using 64K on GnuTrisquel 11 GnuLinux (Libre) v6.11 and all wonderful. I think that PPC deserve 64K. Also it is shame for Debian being friendly with blobs propietary all this is happen because Evil Fedora.
Also i am worried that pocock it selling all ppc machines. = (
-
Daniel I was also thinking of taking the problem directly to the Debian forums at this point, can you tell me which are the main forums where I can write and bring the problem?
Please join the debian-devel mailing list (https://lists.debian.org/debian-devel). That has always been the main place to communicate about issues that span multiple architectures.
From what I understand the problem is not only for us on Power but also on other architectures they are having problems with Debian 12 on the new Kernels... This problem must be solved once and for all because it is absurd not to be able to use the new Kernels on the latest version of Debian and then on the old Debian instead everything works perfectly it makes no sense... I updated because now on 11 they do nothing anymore and they don't update almost anything anymore and we are left behind. I like Gnome 3.38 better than 3.4X but unfortunately now we have to use this but at least everything works damn it...
If you search the Debian Bug Tracking System (BTS) (https://bugs.debian.org) for all the reports about Debian installation failures and Debian upgrade failures you will see that I personally spend time testing the upgrades and installations during the freeze process before every release and I share all my feedback about bugs.
Now that Debian has become so political they reject legitimate bug reports without even looking at them. Even if a found a zero-day security issue, the political filters would block me reporting that. One bug report from an experienced developer might avoid problems for another 10,000 anonymous users who don't know how to report bugs.
There have been various reports and surveys in 2024 revealing that young people are not getting involved and the existing developers are getting older (https://www.theregister.com/2024/07/15/opinion_open_source_attract_devs/)
Personally, I feel the Code of Conduct gaslighting is a big factor in that (https://danielpocock.com/category/code-of-conduct-gaslighting/). When young people go out to the pub on a Saturday night, the last thing they hope to see are their parents, their professors or their boss in the same pub. Yet when you see some reference to Code of Conduct for a weekend event like FOSDEM, it is not a real weekend any more. If they want to have people behave like their boss is around all the time, why not move FOSDEM to a weekday so more people can ask their company to pay them for the time we spend there?
When people see lawsuits, they don't always know who is right or wrong but they just go somewhere else.
When people see the press team writing statements to denounce a volunteer, people subconsciously reduce their effort to do testing or reporting bugs during the pre-release freeze.
Therefore, the quality of the software declines and we risk getting into some kind of death spiral where the politics pushes some people away and then the lack of reliability pushes even more people away and it becomes harder and harder to recover.
They are always talking about having a "safe space". If they push everybody out so it is just 15 or 20 core members of the cabal then I'm sure they will feel safe but they won't have a real distribution any more.
-
I did what you told me Daniel, I signed up to the Debian mailing list and after they sent me the acceptance response to the subscription, I immediately sent an email to the address: debian-bugs-rc@lists.debian.org and I exposed there the problem of Kernels that from 6.2.X onwards on 12 do not work. Let's see what they answer me and I hope I wrote in the right place...
-
It is really sad that so many people are suffering because of the politics in Debian. It is really bad for people who spent money on the Raptor hardware and it is also really bad for my family, friends, neighbors and many other people who had these political problems forced upon them by the social media set.
all i know is the installer was broken, i'm sure it still is lol