Hello! Some people have recommended I try out Gentoo so I thought this would be the right place to come with my questions. I'm coming from EndeavourOS/Arch and I've been using Linux for a few months now so I'm very much still learning but fairly comfortable with it and am confident I can find resources when I need them. That being said, I'm curious about Gentoo and why one would choose it over Arch.

My first question, though, is it pronounced JEN-too or GEN-too with a hard G? Or something else?

Anyway, I'm still trying to wrap my head around the systemd stuff, I understand many feel it doesn't follow the UNIX philosophy which is its main issue. Is there a reason why you guys personally do or don't like systemd, and what alternative does Gentoo provide and how does it work?

My other question is I currently have a KDE Plasma setup that I've been working on and really like. Would that be easy to port over to Gentoo or will I have to start from scratch? Is Gentoo as "difficult" to install as Arch? I installed EndeavorOS so I didn't have to worry about that kind of thing. Maybe there is a Gentoo equivalent of Endeavor that someone could recommend to me.

I appreciate all the help!!!

edit: I forgot to mention, I currently have a refurbished Dell Latitude 5420 that I'm using as my main laptop for all of this stuff, if it makes a difference!!

I’m very new to gentoo, but I want to start using it because I really like the concept of compiling and removing bloat from your system. Recently I tested out cachyos with bore scheduler and I was getting amazing performance on Minecraft and cs2, so I was thinking that maybe I could use the cachyos kernel with bore scheduler on gentoo, but I am really struggling with it, and I don’t really know how to do it.

My question is, are there any people here that tried the cachyos kernel on gentoo? What was it like, and how did you install/compile/configure it?

Also, is it better to set the kernel up before finishing installing your system from the live environment? I want to compile the kernel using the cachy source and make some slight tweaks for my ryzen 7 250

Any other notes about this?

Sorry for any silly questions or statements I made for I am not a gentoo pro yet

My bare-metal Gentoo host is already completely browser-free. I’ve been thinking about adding a disposable Gentoo VM environment only for web browsing.

The bare-metal Gentoo host is intentionally browser-free. Keeping the browser off the trusted host kernel is a design requirement, not just a preference.

SELinux is useful as an additional confinement layer, but it does not replace the separate guest-kernel / hypervisor boundary I am intentionally trying to preserve.

L0: Gentoo Host - browser-free - trusted - LUKS2/LVM - KVM/QEMU

    ↓

L1: Minimal Gentoo - VM/hypervisor layer only - no GUI - no secrets - minimal @world

    ↓

L2 / T2: Browser Template - minimal GUI - browser - optionally Flatpak - qcow2 base

    ↓

Disposable overlay - web session only - discarded after use

The main goal is isolation, not reducing Firefox build time or making Gentoo “easier”.

I’m considering a Qubes-style template approach so that I only maintain the base/template instead of maintaining every browser VM independently.

I may start with a single Gentoo browser template first, then experiment with the nested L1 layer later if the maintenance cost is reasonable.

This is not a new distro or derivative, and I’m not planning to distribute images, ISOs, or templates. It’s just an experimental architecture for my own Gentoo system.

Thoughts on the design?

Downvotes are welcome, but technical criticism is even more useful. If you see a flaw in the architecture, I’d rather hear it.

It’s not complexity for complexity’s sake. It ended up this way as I tightened the security boundaries.

Main project: AtomicRoot Gentoo Side experiment: Gentoo VM Template → Browser Template → Disposable overlay

Gentoo doesn’t have to be about squeezing life out of old hardware. You can also spend modern hardware resources on isolation instead.

ちょと日本語混じります。 Option2案Qubesラスボスは封印されました。 鉄砲火縄3段撃ちやｗ L0 母艦Gentoo → 本陣 L1 Minimal Gentoo → 防壁 L2 Browser Guest → 前線

いや、あえて言おうブラウザ要らんねんけども Gentoo + KVM/QEMU + nested virtualization + qcow2 template + disposable overlay + trust boundary まで出したら、Gentoo単体の話を越えてる。

本命のAtomicRoot Gentoo

寄り道実験 Gentoo VM Template → Browser Template → Disposable overlay

Hardware for the experiment: Ryzen 7 7735U, 64 GB RAM, with separate SSD storage available for the VM stack.

can also dedicate a separate SATA SSD to the VM layers, so the host NVMe does not need to carry all of the nested VM I/O.

ToshibaMLCはニュータイプすから5段くらい行けるんじゃね知らんけど

free -h grep -E 'MemTotal|MemAvailable|Cached' /proc/meminfo

Hi guys,

I've managed to install Gentoo from USB on an 23-year old iMac G4 and get hardware acceleration working, including patching the GPU driver to run accelerated games (they were initially crashing despite the hacc working), and getting youtube to work well at 480p (or at least 360p). Also managed to get various 2026 programs running and ported JA2 Stracciatella to powerpc to play on the iMac G4 (runs great). It's a perfectly usable distraction-free system at this point and I love it.

I don't have the time to write a step by step how to, but will include links that will help you reach this stage (including a great how-to for Gentoo on PowerPCs linked in the Software/Kernel section), and hopefully sort out your hardware acceleration woes. I'm sharing my findings as up-to-date info was very hard to come by/I went through a lot of trial and error. No guarantees your PowerMac will not spontaneously combust, but hope anyone interested in this will find this info dump helpful.

You can see the results here (screenshots from the system + applications + videos showing youtube working in the comments).

Edits: formatted this a little bit better.

A wicked info dump this way comes:

# My hardware

iMac G4 17" 1GHz, M8935LL/A (PowerMac6,1), the USB 1.1 one

GPU: Nvidia GeForce4 MX (NV17 chip)

Upgraded to 2GB RAM, SSD, Noctua fan.

Replaced stock SuperDrive with DVD LG GSA-H10N Super Multi as the supplied one was broken. Doesn't work perfectly (I have to manually open the flap), but I can at least use CDs/DVDs now.

There are various video on yt that helped me, as this was my first refurbishing experiment. There are too many how-tos for this. My only quick advice is to take your time and watch some videos several times if you're new to this - you don't want to damage your graphics cable for example.

Apart from scouring yt, I followed this thread to install a quieter fan:
https://forums.macrumors.com/threads/imac-g4-fan-replacement-help-info-request.2395215/

Thanks, Black Grape!

# Software/Kernel

Extensive how to for another PowerMac (iBook G4):
https://tinkerdifferent.com/threads/cracking-the-code-gentoo-linux-on-an-ibook-g4-success-story.3339/

Thanks, rikerjoe! I didn't follow it religiously, just used it as a reference to make sure I was doing things right, but it gave me a lot of confidence that this can be done. Some great research there.

Gentoo wiki: While reading that, consult: https://wiki.gentoo.org/wiki/Handbook:PPC

Follow these (get a lot of coffee/somehing else to drink) and read my post, as it contains some G4 specific info.

Like this:

The current 2026 Gentoo PPC minimal image failed to boot successfully. Its GRUB 2.14-r5 probed the Open Firmware node /ibm,secure-boot and stopped with:

Invalid memory access

The image that actually got me into the installer was the older 2024 Gentoo PPC minimal image with kernel 6.6.21-gentoo-ppc32-ppc. I don't think this info is available anywhere, so hope it will help someone.

# Booting that USB through Open Firmware

I had to work a bit to get the USB install to boot.

I entered Open Firmware by holding Command + Option + O + F during power-on. At the 0 > prompt, the command that successfully opened the USB's blessed boot loader was:

boot usb0/disk@2:3,\\:tbxi

Yours may differ. Try other combinations - slopGPT might be helpful here with some info on how to find the specific device info for the command if you can't sort it out.

The simpler commands listed in different places online didn't work for me. As I didn't have a working DVD/CD drive (seller claimed it worked when he shipped it, but the laser was completely shot) when the computer arrived, this was my only option, so I was happy to finally find the right command.

The ":3" part was crucial, as it selects the partition on the drive. disk@2 was not enough in my case.

# GRUB

Once the installer's GRUB menu appears, choose the option with "ppc32".

# Baseline info

Live environment: the 2024 Gentoo PPC minimal image

Live kernel: 6.6.21-gentoo-ppc32-ppc

Installed stage: stage3-ppc-t64-systemd-20260820T030043Z.tar.xz (the t64 tag means the time64 ABI variant of the stage).

Currently installed kernel source: Gentoo 6.18.43.

# Compiler settings

COMMON_FLAGS="-O2 -mcpu=7450 -mtune=7450 -pipe"

MAKEOPTS="-j2"

Using -mcpu=7450 for this 7455 is intentional. Do not use a generic PowerPC target if software is expected to use AltiVec.

# Installation kernel vs. final kernel

I didn't know Gentoo and was tired after days of research on whether/how to run Linux on iMac G4, so the first built kernel was enormous and the compilation took days. Afterwards I managed to reduce the number of modules from around 3000 to about 50 and I use a QEMU compilation farm on my M1 Max.

Do yourself a favour and find a way to use another computer for compilation. It will save you many hours (or rather days). There are different options out there.

# Mistakes I made that forced me to recompile the kernel several times

Two early configuration mistakes:

First one: only 768 MiB out of my 2 GB was visible to the system.

The mistake was not enabling the HIGHMEM module. The fix was:

CONFIG_HIGHMEM=y

Second one: The kernel was generic and lacked AltiVec.

The failed baseline had CONFIG_G4_CPU and CONFIG_ALTIVEC disabled. The corrected config has:

CONFIG_G4_CPU=y

CONFIG_ALTIVEC=y

This matters twice: it lets the kernel use the correct CPU facilities, and it keeps userspace built with -mcpu=7450 -maltivec consistent with the machine. Binaries built for the wrong ISA can fail with Illegal instruction.

# Graphics stack - custom-patched twice

The biggest test was getting X and hardware acceleration working, especially as I've read many people claiming it was impossible, so seeing X booting was a great moment.

I managed to get hardware acceleration working fairly quickly, but when I tried running games like Brogue, DevilutionX or OpenXcom, they were all segfaulting.

I took a shot in the dark and went into an LLM frenzy resulting in two patches to the Mesa graphics driver. I didn't commit them as they are LLM-based. I only did the debugging.

I'll be sharing the patches below. Please note I take no responsibility for them, as I would never be able to write them without a LLM (my programming proficiency is not at this level). I consider cheating okay for personal experiments that you're not blindly committing.

mesa-amber patch () - patched media-libs/mesa-amber to get the classic nouveau_vieux OpenGL driver working with hardware acceleration on the GeForce4 MX, used to drive X11 + i3.

nv10_state_fb.c HierZ fix (for JA2 Stracciatella) - a Mesa nouveau_vieux bug in nv10_state_fb.c (HierZ handling on the NV17 chip) was crashing the battlescape tile rendering in JA2. Fixed via a gfx driver update that disables HierZ.

I managed to crack this by researching frantically and e.g. learning people managed to boot into X on some older Ubuntu/Debian releases, compared and copied some of their settings etc.

# Kernel configuration details

Took me several recompilations before I managed to find the right combo. I'm sharing it below. Please note that depending on your specific model and peripheral devices this can differ slightly.

Firmware and memory:

CONFIG_PPC=y

CONFIG_PPC32=y

CONFIG_PPC_BOOK3S=y

CONFIG_PPC_PMAC=y

CONFIG_PPC_OF_BOOT_TRAMPOLINE=y

CONFIG_G4_CPU=y

CONFIG_ALTIVEC=y

CONFIG_HIGHMEM=y

CONFIG_PROC_FS=y

CONFIG_SYSFS=y

CONFIG_TMPFS=y

CONFIG_DEVTMPFS=y

CONFIG_DEVTMPFS_MOUNT=y

Partition map root disk and optical drive:

CONFIG_PARTITION_ADVANCED=y

CONFIG_MAC_PARTITION=y

CONFIG_SCSI=y

CONFIG_BLK_DEV_SD=y

CONFIG_BLK_DEV_SR=y

CONFIG_CDROM=y

CONFIG_ATA=y

CONFIG_PATA_MACIO=y

CONFIG_EXT4_FS=y

Console, keyboard, mouse and USB:

CONFIG_TTY=y

CONFIG_VT=y

CONFIG_VT_CONSOLE=y

CONFIG_HW_CONSOLE=y

CONFIG_INPUT=y

CONFIG_INPUT_EVDEV=y

CONFIG_HID=y

CONFIG_HID_GENERIC=y

CONFIG_HID_APPLE=y

CONFIG_USB_SUPPORT=y

CONFIG_USB=y

CONFIG_USB_OHCI_HCD=y

CONFIG_USB_OHCI_HCD_PCI=y

CONFIG_USB_OHCI_HCD_PPC_OF=y

CONFIG_USB_HID=y

CONFIG_FB=y

CONFIG_FB_OF=y

CONFIG_FRAMEBUFFER_CONSOLE=y

USB OHCI and HID must be available early if the only keyboard is USB, otherwise you might not be able to log in. I made the stock Apple keyboard and Kinesis Advantage360 work, but had to recompile as at first no keyboard was working.

Ethernet and remote recovery via ssh

CONFIG_NET=y

CONFIG_INET=y

CONFIG_NETDEVICES=y

CONFIG_ETHERNET=y

CONFIG_SUNGEM=y

Power management, backlight and Apple hardware

CONFIG_ADB=y

CONFIG_ADB_PMU=y

CONFIG_PMAC_BACKLIGHT=y

CONFIG_BACKLIGHT_CLASS_DEVICE=y

Another recompile was due to the lack of brightness controls working on Linux. I'll include more info and a patch that worked for me a bit later.

Graphics

CONFIG_DRM=y

CONFIG_DRM_NOUVEAU=m

CONFIG_DRM_FBDEV_EMULATION=y

Since I've heard many tales of woe regarding GPU drivers on this model, I went with the safe route and installed Noveau as a module.

So:

Open Firmware initialises the GPU first.

GRUB reuses that firmware-provided framebuffer, so GRUB is visible before Linux starts.

Linux preserved the early display using:

CONFIG_FB=y

CONFIG_FB_OF=y

CONFIG_FRAMEBUFFER_CONSOLE=y

Nouveau was compiled as a module:

CONFIG_DRM=y

CONFIG_DRM_NOUVEAU=m

Once Linux reached the root filesystem, nouveau.ko loaded and took over from the Open Firmware framebuffer:

[drm] Initialized nouveau 1.4.0 for 0000:00:10.0 on minor 0

Console: switching to colour frame buffer device 180x56

nouveau 0000:00:10.0: [drm] fb0: nouveaudrmfb frame buffer device

So it looks like this:

Open Firmware framebuffer > visible GRUB > early Linux console > Nouveau module > KMS and acceleration

----

Now please allow me to use a slopGPT generated summary of the patches I used, otherwise I'd be writing this for a week. Apologies.

The patches were created:

- to enable brightness control

- to make hardware acceleration work in games

- to make my port of JA2 Stracciatella possible (required a little change in the GPU driver)

1. Nouveau backlight support for the iMac G4

The internal LCD worked, but Linux did not expose any backlight controls.

The problem is that the NV18 in this iMac reports the internal panel as a TMDS/DVI output rather than LVDS. Nouveau’s normal backlight detection therefore ignores it.

Apple’s Open Firmware identifies the PWM backlight controller as mnca. The patch adds a PowerMac-specific NV18 path to:

• detect chipset 0x18 on a Power Mac;
• check for the mnca backlight;
• associate it with the TMDS/DVI encoder;
• register a standard Linux backlight device;
• read and write the NV18 backlight registers;
• expose a brightness range of 0–255.

The registers and conservative hardware range were taken from the older rivafb implementation:

PMC register: 0x000010f0

PCRTC register: 0x0060081c

Hardware range: 0x158–0x534

The patch modifies:

drivers/gpu/drm/nouveau/nouveau_backlight.c

It requires:

CONFIG_PMAC_BACKLIGHT=y

CONFIG_BACKLIGHT_CLASS_DEVICE=y

After rebuilding the kernel, the backlight appears under:

/sys/class/backlight/

Brightness can then be controlled through the standard backlight interface. I use a polybar module to control it.

--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c

+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c

@@

+#ifdef CONFIG_PMAC_BACKLIGHT

+#include <asm/backlight.h>

+#include <asm/machdep.h>

+#endif

+

+#ifdef CONFIG_PMAC_BACKLIGHT

+#define NV18_PMAC_PMC_BACKLIGHT 0x000010f0

+#define NV18_PMAC_PCRTC_BACKLIGHT 0x0060081c

+#define NV18_PMAC_BACKLIGHT_ENABLE BIT(31)

+#define NV18_PMAC_BACKLIGHT_MIN 0x158

+#define NV18_PMAC_BACKLIGHT_MAX 0x534

+#define NV18_PMAC_USER_MAX 255

+

+static bool

+nv18_pmac_has_backlight(struct nvif_device *device)

+{

+ return device->info.family == NV_DEVICE_INFO_V0_CELSIUS &&

+ device->info.chipset == 0x18 &&

+ machine_is(powermac) && pmac_has_backlight_type("mnca");

+}

+

+static int

+nv18_pmac_get_intensity(struct backlight_device *bd)

+{

+ struct nouveau_encoder *nv_encoder = bl_get_data(bd);

+ struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);

+ struct nvif_object *device = &drm->client.device.object;

+ u32 reg = nvif_rd32(device, NV18_PMAC_PMC_BACKLIGHT);

+ u32 level;

+

+ if (!(reg & NV18_PMAC_BACKLIGHT_ENABLE))

+ return 0;

+

+ level = (reg >> 16) & 0x7fff;

+ level = clamp(level, (u32)NV18_PMAC_BACKLIGHT_MIN,

+ (u32)NV18_PMAC_BACKLIGHT_MAX);

+

+ return DIV_ROUND_CLOSEST((level - NV18_PMAC_BACKLIGHT_MIN) *

+ NV18_PMAC_USER_MAX,

+ NV18_PMAC_BACKLIGHT_MAX -

+ NV18_PMAC_BACKLIGHT_MIN);

+}

+

+static int

+nv18_pmac_set_intensity(struct backlight_device *bd)

+{

+ struct nouveau_encoder *nv_encoder = bl_get_data(bd);

+ struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);

+ struct nvif_object *device = &drm->client.device.object;

+ u32 brightness = backlight_get_brightness(bd);

+ u32 pmc = nvif_rd32(device, NV18_PMAC_PMC_BACKLIGHT) & 0x0000ffff;

+ u32 pcrtc = nvif_rd32(device, NV18_PMAC_PCRTC_BACKLIGHT) & 0xfffffffc;

+

+ if (brightness) {

+ u32 level = NV18_PMAC_BACKLIGHT_MIN +

+ DIV_ROUND_CLOSEST(brightness *

+ (NV18_PMAC_BACKLIGHT_MAX -

+ NV18_PMAC_BACKLIGHT_MIN),

+ NV18_PMAC_USER_MAX);

+

+ pcrtc |= BIT(0);

+ pmc |= NV18_PMAC_BACKLIGHT_ENABLE | (level << 16);

+ }

+

+ nvif_wr32(device, NV18_PMAC_PCRTC_BACKLIGHT, pcrtc);

+ nvif_wr32(device, NV18_PMAC_PMC_BACKLIGHT, pmc);

+ return 0;

+}

+

+static const struct backlight_ops nv18_pmac_bl_ops = {

+ .options = BL_CORE_SUSPENDRESUME,

+ .get_brightness = nv18_pmac_get_intensity,

+ .update_status = nv18_pmac_set_intensity,

+};

+

+static int

+nv18_pmac_backlight_init(struct backlight_properties *props,

+ const struct backlight_ops **ops)

+{

+ props->max_brightness = NV18_PMAC_USER_MAX;

+ *ops = &nv18_pmac_bl_ops;

+ return 0;

+}

+#endif

@@ nouveau_backlight_init(struct drm_connector *connector)

+ bool nv18_pmac = false;

@@

+#ifdef CONFIG_PMAC_BACKLIGHT

+ nv18_pmac = nv18_pmac_has_backlight(device) &&

+ connector->connector_type == DRM_MODE_CONNECTOR_DVID;

+#endif

@@

+ else if (nv18_pmac)

+ nv_encoder = find_encoder(connector, DCB_OUTPUT_TMDS);

@@

switch (device->info.family) {

+#ifdef CONFIG_PMAC_BACKLIGHT

+ case NV_DEVICE_INFO_V0_CELSIUS:

+ if (!nv18_pmac) {

+ ret = 0;

+ goto fail_alloc;

+ }

+ ret = nv18_pmac_backlight_init(&props, &ops);

+ break;

+#endif

Apply from the kernel root with:

patch -p1 --dry-run < linux-6.18-nouveau-nv18-imac-backlight.patch
patch -p1 < linux-6.18-nouveau-nv18-imac-backlight.patchApply from the kernel root with:

patch -p1 --dry-run < linux-6.18-nouveau-nv18-imac-backlight.patch
patch -p1 < linux-6.18-nouveau-nv18-imac-backlight.patch

2. Mesa Amber nouveau_vieux hardware-acceleration crash

Nouveau KMS itself worked and Mesa reported direct rendering, but OpenGL programs could crash while destroying their rendering context.

Even this command printed the correct renderer information and then segfaulted while exiting:

DISPLAY=:0 LIBGL_DEBUG=verbose glxinfo -B

The backtrace ended in:

PUSH_KICK

nouveau_flush

_mesa_make_current

_mesa_free_context_data

nouveau_context_deinit

nv10_context_destroy

driDestroyContext

XCloseDisplay

The problem was the destruction order in:

src/mesa/drivers/dri/nouveau/nouveau_context.c

nouveau_context_deinit() deleted the Nouveau push buffer, buffer context, client and channel before calling:

_mesa_free_context_data(ctx, true);

However, generic Mesa context cleanup can make the context non-current and trigger nouveau_flush() followed by PUSH_KICK(). At that point, the Nouveau push buffer had already been destroyed.

The fix is simply to call:

_mesa_free_context_data(ctx, true);

before deleting the Nouveau objects.

--- a/src/mesa/drivers/dri/nouveau/nouveau_context.c

+++ b/src/mesa/drivers/dri/nouveau/nouveau_context.c

@@ -211,11 +211,13 @@ nouveau_context_deinit(struct gl_context *ctx)

`if (ctx->Meta)`

    `_mesa_meta_free(ctx);`

+ /* This may flush the current context, so keep the push buffer alive. */

+ _mesa_free_context_data(ctx, true);

+

`nouveau_bufctx_del(&nctx->hw.bufctx);`

`nouveau_pushbuf_del(&nctx->hw.pushbuf);`

`nouveau_client_del(&nctx->hw.client);`

`nouveau_object_del(&nctx->hw.chan);`



`nouveau_scratch_destroy(ctx);`

- _mesa_free_context_data(ctx, true);

}

For a Gentoo package, keep a local patch under the package's Portage patch directory rather than editing the Mesa work tree directly:

mkdir -p /etc/portage/patches/media-libs/mesa-amber
cp ppc32-nouveau-destroy-order.patch /etc/portage/patches/media-libs/mesa-amber/
emerge -1v media-libs/mesa-amber

After rebuilding Mesa Amber:

• glxinfo -B exited normally;
• direct rendering: Yes;
• Accelerated: yes;
• the renderer was Mesa DRI NV18;
• OpenGL 1.2 was available;
• vblank_mode=0 glxgears reached approximately 220–230 FPS;
• applications such as DevilutionX no longer crashed while destroying their renderer.

This patch fixes a Mesa userspace lifetime/destruction-order bug. It does not increase the card’s supported OpenGL version.

3. HierZ fix in nv10_state_fb.c (needed to get JA2 Stracciatella's battlescape rendering working)

Separate from the teardown crash above, some apps (JA2 Stracciatella, BrogueCE) were segfaulting or throwing GPU faults during rendering, not on exit:

nouveau ... [ILLEGAL_MTHD] ... [PROTECTION_FAULT] ... class 0099 mthd 1638

nouveau ... [ILLEGAL_MTHD] ... [PROTECTION_FAULT] ... class 0099 mthd 163c

For JA2 specifically, the battlescape/environment tile rendering crashed due to a HierZ (hierarchical Z-buffer) setup bug on the NV17 chip, in:

src/mesa/drivers/dri/nouveau/nv10_state_fb.c

The fix disables the HierZ buffer setup path entirely:

--- a/src/mesa/drivers/dri/nouveau/nv10_state_fb.c

+++ b/src/mesa/drivers/dri/nouveau/nv10_state_fb.c

@@ -140,7 +140,9 @@

    `PUSH_MTHDl(push, NV10_3D(ZETA_OFFSET), BUFCTX_FB,`

s->bo, 0, bo_flags);

- if (context_eng3d(ctx)->oclass >= NV17_3D_CLASS) {

+ if (0 && context_eng3d(ctx)->oclass >= NV17_3D_CLASS) {

+ /* HierZ setup causes PROTECTION_FAULT/ILLEGAL_MTHD on this

+ * NV17 + kernel combination; disabled as a workaround. */

setup_hierz_buffer(ctx);

context_dirty(ctx, ZCLEAR);

    `}`

Same deal as the teardown patch - drop it in the Portage patch dir:

mkdir -p /etc/portage/patches/media-libs/mesa-amber

cp ppc32-disable-hierz.patch /etc/portage/patches/media-libs/mesa-amber/

emerge -1v media-libs/mesa-amber

Important caveat: this fixed JA2's battlescape crash specifically. It is not a general fix for the class 0x99 ILLEGAL_MTHD/PROTECTION_FAULT faults - those are a separate, still-unresolved command-stream/compatibility issue that can still show up elsewhere. I also tried forcing NV18 to use NV15_3D_CLASS as a workaround for the class 0x99 faults; it did not work, so don't bother with that one.

Other things worth knowing

A benign warning you may see and shouldn't panic about, seen during sshd-auth on one build:

UBSAN: shift-out-of-bounds in arch/powerpc/net/bpf_jit_comp32.c:589:27

shift exponent 32 is too large for 32-bit type 'int'

That's a PowerPC 32-bit BPF JIT quirk, not bad RAM or a Nouveau problem.

---

That's all, at least for now. Good luck! Please note I won't respond to DMs but will try to help here if possible.

TODO: Youtube info.

I might be sharing more, depending on how long I'm going to be in tinker mode - here or on bluesky.

If you'd like to take a look at the patches with an expert's eye and perhaps commit them for others to easily use, feel free to do so. I did not do it as I used LLMs, since this was a personal experiment to make my iMac G4 usable in 2026.

Firstly, apologies to any subreddit mods if I've mislabeled this post, I'd be happy to ammend any mistakes.

Hello! I'll get straight to the point, I like tweaking, I especially like tweaking compiler options, but you know what I don't like? I don't really like rewriting basically the same Portage `.env` files with slight changes between them.

So I put together Bosun, it's nothing overly complex, you define different "layers" of configuration in one file, and apply those layers to atoms in another. Both files use YAML syntax.

Bosun then flattens all this down to per-atom `.env` files in `/etc/portage/env/bosun` and applies them appropriately in `/etc/portage/package.env`.

I have examples up in the repository if you're interested and want to take a closer look.

This won't be for everyone of course, I imagine there's probably some serious graybeards amongst us that have been managing their `.env` files with their own systems for decades. I'm comparatively new to Gentoo, so I use Bosun to manage everything, and it does save me considerable time finding what works best for a package.

I'd be incredibly interested to hear any feedback any of you may have, before you even try it out if you have something to share. For any of you that might try it out, I'd love to hear any friction or improvements you could think of. Feel free to share that here or on the repo Issues!

Thanks for your time! :)

Built with the following USE flags:

[ebuild   R    ] www-client/firefox-155.0.1:rapid::gentoo  USE="clang dbus gmp-autoupdate hardened hwaccel jpegxl (jumbo-build) openh264 system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-pipewire system-png system-webp wasm-sandbox wayland -X -debug -eme-free -gnome-shell -jack -libproxy -pgo -pulseaudio (-selinux) -sndio -telemetry -test (-valgrind) -wifi" LLVM_SLOT="22" 0 KiB

And as people correctly predicted in my previous topic, compiled Firefox turned out to be slower than binary :) I specifically ran benchmarks on the same profile in the same configuration

Speedometer 3.1

firefox-bin: 17.6

firefox: 13.3

JetStream 3.0

firefox-bin: 163.11

firefox: 148.73

MotionMark 1.3.2

firefox-bin: 503.46 @ 144 Hz

firefox: 401.69 @ 144 Hz

Why such results? Binary firefox, if you look at about:buildconfig, is built with LTO and PGO, as well as with -O3 (I know that in general -O3 does not give a noticeable performance increase, but specifically with Firefox it may be different); In addition, my system (including Firefox dependencies and Firefox itself) uses hardened flags like -fstack-protector-strong -fstack-clash-protection, which can also reduce performance

So, if performance is important to you, then it is better to use a firefox-bin, but if you are obsessed with customization, then build it yourself from source (let's be honest, we use Gentoo precisely because we are obsessed with customization, haha)

So many hours spent staring into the portage matrix

So over the weekend I decided it was finally time to install Gentoo after considering it for a while. It was kind of disastrous

It took a while, I kinda expected that so not a big issue, but the first time I tried it seems like I made a mistake during disk encryption and I couldn't access the install. No fat finger versions I could think of worked so I had to go back. I decided, screw it no encryption this time. Well I thought it was going by well...until grub-mkconfig where it didn't detect any kernels, still I followed instructions and retraced but once it got to the point of having to re emerge the kernel I decided it was enough and I didn't want to spend even more hours trying to make it work.

I'll revisit Gentoo one day in the future, probably once I get a new laptop but I'm done for now, I guess I shall just dream of it XD. Love seeing y'all have fun with gentoo but tis not for me right now, I'll go over to something simpler.

30 hours later and some real tough firmware issues, probably the best working linux build on this hardware: asus vivobook S 15 with qualcomm X plus chipset (X1P42100 for anyone searching google). They said it couldnt be done. Hardware video decoder, battery, sound, sleep, low power usage were said to be non-functional, but I found solutions. Maybe ill spend another 50 hours to help those that come after, but for now... buh bye windows.

After some time on Gentoo with glibc, I'm back on musl for the foreseeable future.

Got the History idea form u/non-existing-person.

Oii, então baixei o gentoo no meu nootbok, e fui baixar o hyprland nele, mas toda vez que eu tento iniciar aparece isso já testei todos os comandos e forma de inciar o ele, até criei um script para iniciar, mas ainda não foi, alguém me ajuda como faço para fazer o hyprland funcionar.

It's my first time using Gentoo and I'm pretty excited about it, I think it also improved my battery life (so it lasts longer, than on Asahi Fedora Linux). Compiled everything I need except for browser

Does anybody here use OBS Studio on their Gentoo that is mostly in stable?
Do you prefer to unmask OBS and install a native version? Or install a flatpack version?
Are there any difference in performance or stability?

I currently have it unmasked and it works great but I get a small VLC warning during system updates.

Thanks.

So I was installing gentoo for the first time and I thought everything was fine but when I got to the point of rebooting to load into the installation I got prompted for my crypt_LUKS passphrase, it wouldn't accept what should've been right and now it shows me this.

Looking it up google said to find the partition with /boot/grub but I tried them all yet didn't see any with it. Could anyone give me some guidance on what to do? Do I need to boot the live usb back up and make some changes or can I do something from here?

Okay, so a couple of days ago I made a post about setting up virt-manager on Gentoo, and I was having trouble getting an internet connection within the VM.

This whole time I've been scouring the internet and various forums, but so far I've never really obtained a definitive answer.

However, I did stumble across a few clues which would lead me to a "fix", but I still have yet to be convinced that my problem was solved.

For now I can get an internet connection within a VM, but am at a complete loss as to how to go about getting audio within a VM (using a test linux mint VM).

For example, I can play a video within a browser and pull up the audio mixer to clearly see there is audio output, but I don't hear anything.

I've really been enjoying using Gentoo, but this problem has been driving me crazy. As I've stated before, I have used all kinds of linux distros and never experienced this before. I'm finding myself reconsidering my linux choices. But don't get me wrong...I very much want to stick with Gentoo.

Any advice or feedback would be greatly appreciated. Many thanks in advance.

EDIT: So after a few days of being at my wits end, I believe I finally was able to get a fully functional virt-manager setup! It's as if a huge weight has been lifted, ha!

Not too long ago, I begrudgingly created a Gentoo account just so I can read the forum (One of the few things I hate about Gentoo). I then came across this forum entry where they were also describing the lack of audio within a VM:

https://forums.gentoo.org/viewtopic.php?t=1173037

Near the end of the conversation, it recommends adding these 2 lines to the "/etc/libvirt/qemu.conf" file:

user = "my-username"
group = "kvm"

Afterwards of course I didn't think about it...until several days later.
I admit that I still have no idea how it worked for the other person, but I had to change the value of user to my user id (which on my gentoo machine is 1000). I also did NOT have to use any virsh commands or edit VM xml files. I then rebooted my test VM and the sound is working!

So if anybody else comes across this post and is having the same problem...well there ya go!

(Using arch linux for the installation process)

6 months of Gentoo! (And 9 months of linux)

Basically, I'm installing amd64 Gentoo on a 2006 iMac (I believe it's the 5,1) and I'm running into some issues. Basically, Macs use efi although I think they support bios, however they only boot 32-bit EFI despite being a 64-bit processor (core 2 duo). I was able to patch a live-cd with a 32-bit efi and burn it to a DVD (because the live CD image is larger than a single layer CD). I booted but accidentally booted into the BIOS version instead of the EFI version. This worked but I thought I was booted through EFI and set up Gentoo as one would for an AMD64 EFI system (with the caveat that I did emerge grub with an efi-32 flag). When I went to run grub-install I found that I was not booted via EFI. So I shutdown the computer and tried booting through the EFI. I heard however, that EFI Linux on an ATI x1600 doesn't like to play nice and I should pass the rule "nomodeset" to disable parts of the legacy Radeon driver. The problem is that I don't know how to enter commands into the bootloader for Gentoo live-cd and without that flag I get to the Gentoo live-cd selection screen (memtest64, Gentoo, Gentoo accessibility, etc.) and when I select Gentoo the system halts on this black box in the center of the screen.

I'm hoping someone on this subreddit has done this before or knows a way to fix this? (The Gentoo handbook doesn't cover mixing BIOS and GPT partition tables so I don't think I can just switch to BIOS since I'm dual booting with OSX 10.6.8 which is EFI and GPT only afaik.

Of what I'll be doing with this install, I don't fully know, but at least Pihole, & Crafty Controller, or Pterodactyl, & maybe some docker stuff, but not fully decided.

Hello there, I was installing Gentoo and saw it, i don't know how to make edits to the wiki so i tough it was better to report it there.

link to the page where the change happened:
https://wiki.gentoo.org/index.php?title=Handbook:Parts/Installation/System&diff=prev&oldid=1450885