Gentoo Repository News
installkernel is no longer implicitly installed - 26/02/2024 00:00 GMT
/sbin/installkernel is a script called by the kernel's "make install" as well as by the distribution kernel's post-install phase. If you are reading this then chances are you use and rely on installkernel[1] and what follows is essential for you. Previously sys-kernel/installkernel was implicitly installed on many systems via a dependency in sys-apps/debianutils. This dependency was toggled by the "installkernel" USE flag, and enabled by default. Until recently, sys-apps/debianutils was in turn pulled in by app-misc/ca-certificates, an essential package installed on many systems. However, this dependency of app-misc/ca-certificates on sys-apps/debianutils was removed[2]. As a result many users may find that sys-apps/debianutils and therefore sys-kernel/installkernel are no longer part of the dependency graph and will therefore be cleaned up by "emerge --depclean". Removing sys-kernel/installkernel from your system WILL change the way kernels are installed by "make install"! Instead of the versioned /boot/vmlinuz-x.y.z that you are used to, "make install" will simply copy bzImage (or equivalent for your arch) into /boot. This image may not be picked up by your bootloader or its configuration tools. To avoid surprises from such implicit dependencies from happening again in the future, the dependency on sys-kernel/installkernel in sys-apps/debianutils is removed. And as such, sys-kernel/installkernel is only installed on the system if it is either explicitly selected or pulled in via the distribution kernels (e.g. gentoo-kernel(-bin)). User Action Required (users of manually managed kernels) ==================== Users who manually configure, compile, and install their kernels, i.e. users of the sys-kernel/*-sources packages, and who wish to continue to use sys-kernel/installkernel, must ensure that it is explicitly selected by emerging it: emerge --noreplace sys-kernel/installkernel Users who find that sys-kernel/installkernel has already been cleaned from their systems and are therefore affected by the change in kernel installation described above should re-install sys-kernel/installkernel and then re-install their kernel. emerge sys-kernel/installkernel cd /usr/src/linux # (or other location of the kernel sources) make install No manual action is required for users of the distribution kernels: - sys-kernel/gentoo-kernel, or - sys-kernel/gentoo-kernel-bin, or - sys-kernel/vanilla-kernel [1] https://wiki.gentoo.org/wiki/Installkernel [2] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e6ccafd58bc7401fa371d2f255d72ddae0131e6
Posted By: Andrew Ammerlaan
GRUB upgrades - 01/02/2024 00:00 GMT
When booting with GRUB, it is important that the core image and modules have matching versions. Usually, running grub-install is sufficient to ensure this. On the UEFI platform, grub-install allows the core image to be placed in two different locations: EFI/gentoo/grubx64.efi This is the location used by grub-install without options. EFI/BOOT/BOOTX64.EFI This is the location used by grub-install --removable. On upgrades, it is common for users to mismatch the grub-install options they used for the current and previous versions of grub. This will cause a stale core image to exist. For example: /boot/efi/EFI/BOOT/BOOTX64.EFI (grub 2.06 core image) /boot/efi/EFI/gentoo/grubx64.efi (grub 2.12 core image) /boot/grub/x86_64-efi/*.mod (grub 2.12 modules) Booting this system using BOOTX64.EFI image would likely fail due to a symbol mismatch between the core image and modules. [1] Re-runing grub-install both with and without the --removable option should ensure a working GRUB installation. However, this will clobber any BOOTX64.EFI image provided by other loaders. If dual-booting using another boot loader, users must take care not to replace BOOTX64.EFI if it is not provided by GRUB. References: [1] https://bugs.gentoo.org/920708
Posted By: Mike Gilbert
installkernel new USE flag systemd-boot - 30/01/2024 00:00 GMT
/sbin/installkernel is a script called by the kernels 'make install' as well as by the distribution kernels post install phase. sys-kernel/installkernel provides two paths for installing the kernel: - the traditional installkernel, or - systemd's kernel-install In sys-kernel/installkernel versions lower then 20, systemd's kernel-install would default to the layout used for systemd-boot (layout=bls). To improve backwards compatibility with the traditional installkernel this is no longer the case in versions 20 and up. Instead the default layout setting when no other USE flags are enabled is a compatibility layout similar to the traditional installkernel (layout=compat). User Action Required (systemd-boot users) ==================== Users of systemd-boot should: - enable the "systemd-boot" USE flag when upgrading to >=sys-kernel/installkernel-20. See also: https://wiki.gentoo.org/wiki/Installkernel
Posted By: Andrew Ammerlaan
Merging of installkernel-gentoo and installkernel-systemd - 18/01/2024 00:00 GMT
/sbin/installkernel is a script called by the kernels 'make install' as well as by the distribution kernels post install phase. It was previously provided by sys-kernel/installkernel-gentoo or sys-kernel/installkernel-systemd. The functionalities of these two packages have now been merged into sys-kernel/installkernel. sys-kernel/installkernel now provides the systemd USE flag to switch between the traditional installkernel (formerly sys-kernel/installkernel-gentoo) and systemd's kernel-install (formerly sys-kernel/installkernel-systemd(-boot)). Additionally, the new sys-kernel/installkernel with the systemd flag enabled now provides a default install.conf configuration file which ensures that it will work out-of-the-box with no configuration (other then USE flag configuration) required for most setups. Details on configuration and customization can be found on the installkernel wiki page [1]. Below we provide the most important migration notes. User Action Required (GRUB users) ==================== Previously sys-kernel/installkernel-gentoo provided kernel installation automation for users of GRUB via USE=grub. The new sys-kernel/installkernel provides the same functionality, which now works with both the traditional installkernel and systemd's kernel-install. Users of GRUB should therefore: - check that the "grub" USE flag is enabled to ensure that systemd's kernel-install uses the correct layout that grub-mkconfig understands. Users of GRUB may wish to explicitly choose either the traditional installkernel or systemd's kernel-install, in which case they may do so via USE=-/+systemd. sys-kernel/installkernel is renamed from sys-kernel/installkernel-gentoo, therefore no user action is required to upgrade to the new package. User Action Required (systemd-boot users) ==================== Previously sys-kernel/installkernel-systemd provided kernel installation automation for users of systemd-boot. sys-kernel/installkernel provides the same functionality but only via systemd's kernel-install. Users of systemd-boot should therefore: - ensure that the "systemd" and "systemd-boot" USE flags are enabled when upgrading to >=sys-kernel/installkernel-14. Users who are using the distribution kernels (i.e. gentoo-kernel(-bin)) should enable the "dracut" USE flag on installkernel as well to pull in and enable the dracut initramfs generator. This is enforced by portage. Note that the automagic behaviour of the dracut kernel-install plugin is removed in sys-kernel/installkernel. Users who rely on the dracut plugin automatically generating an initramfs when installing the kernel must enable the "dracut" USE flag to retain this behaviour. The upgrade path is enforced by sys-kernel/installkernel-systemd-4, which is just a wrapper pulling in >=sys-kernel/installkernel-14 with the "systemd" flag enabled. sys-kernel/installkernel-systemd may be removed after installing >=sys-kernel/installkernel-14. emerge --noreplace sys-kernel/installkernel emerge --depclean sys-kernel/installkernel-systemd User Action Required (rEFInd users) ==================== Previously sys-kernel/installkernel-gentoo provided kernel installation automation for users of rEFInd. The new sys-kernel/installkernel provides the same functionality, which now works with both the traditional installkernel and systemd's kernel-install. Users of rEFInd should: - ensure that the "systemd-boot" and "grub" USE flags are NOT enabled when upgrading to >=sys-kernel/installkernel-20. Additionally, users of rEFInd may want to - enable the "refind" USE flag to install an icon file alongside the installed kernel image which rEFInd will pick up at runtime. Users of rEFInd may wish to explicitly choose either the traditional installkernel or systemd's kernel-install, in which case they may do so via USE=-/+systemd. sys-kernel/installkernel is renamed from sys-kernel/installkernel-gentoo, therefore no further user action is required to upgrade to the new package. User Action Required (users of other bootloaders and custom scripts) ==================== Users who have previously relied on custom installkernel or kernel-install plugins should either ensure that the same kernel installation method will be used after upgrading to >=sys-kernel/installkernel-14 (via USE=+/-systemd) or migrate these custom plugins (details are on the wiki [1]). Users of bootloaders other than GRUB, systemd-boot or refind may want to retain the traditional /boot layout. They may do so by: - ensuring that the "systemd-boot", "grub" and "refind" USE flags are disabled. Optional: Unified Kernel Images (all users) ==================== Users who wish to use Unified Kernel Images[2] (e.g. for EFI stub booting) may do so by - enabling the "ukify" and "uki" USE flags. Which will automatically install a bootable EFI executable to the EFI system partition. The UEFI firmware, as well as, Systemd-boot, GRUB and rEFInd are capable of loading Unified Kernel Images. For more details see the wiki page on Unified Kernel Images[2] [1] https://wiki.gentoo.org/wiki/Installkernel [2] https://wiki.gentoo.org/wiki/Unified_kernel_image
Posted By: Andrew Ammerlaan
Separate /usr now requires an initramfs - 05/01/2024 00:00 GMT
Systems which have /usr and / on separate filesystems have always required a dedicated initramfs to bring up both partitions. Systems where both /usr and / are on the same filesystem may use an initramfs if they wish, or choose not to. Historically, Gentoo has tried to make the separate filesystems use case work anyway. Despite all our efforts, it is broken and continues to get more broken under various configurations. The only workable solution is to support separate /usr but only when an initramfs is present. For more details on why this is broken, see: - https://bugs.gentoo.org/868306#c10 - https://bugs.gentoo.org/902829 - http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken - https://bugs.gentoo.org/915379 - https://github.com/trofi/nix-guix-gentoo/commit/43d84cc00af530ef912d9c98448b64d6b5282907 - https://github.com/trofi/nix-guix-gentoo/commit/8f194519982fbfabb6b3ca84c0806b1a379b5d06 - https://bugs.gentoo.org/825078 In 2013, Gentoo policy determined that separate /usr without an initramfs was officially no longer supported: - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202 - https://gitweb.gentoo.org/data/gentoo-news.git/tree/2013/2013-09-27-initramfs-required/2013-09-27-initramfs-required.en.txt?id=a79dd69b0cca439bc0c483c9193c79e0554819d0 11 years later, the support is being withdrawn. On 2024-02-05, we plan to begin work on decommissioning existing workarounds and will not accept any more. User Action Required ==================== If you have separate /usr and are not currently using an initramfs, you have until 2024-02-05 to set up an initramfs. If you do not, then at some point on or after this date, routine system upgrades will leave your system unbootable. For details on setting up an initramfs, see: https://wiki.gentoo.org/wiki/Initramfs/Guide
Posted By: Eli Schwartz
LXD to lose access for its image server - 28/12/2023 00:00 GMT
Earlier this year Canonical took their LXD project away from the community-run LinuxContainers and brought it under their own administration. While doing so, they removed management access from non-Canonical employees, along with other things. This caused LXD to be forked and so Incus was born. Incus would pull updates from upstream LXD to stay compatible. Recently LXD was re-licensed so Incus can't benefit from its code anymore. Therefore Incus will become a truly independent project. However it is LinuxContainers community that still hosts most LXD images for free, for Incus and LXD. With them unable to benefit or use LXD anymore, LinuxContainers have decided to stop building and hosting LXD images. Realistically they can't support LXD given these restrictions. They will start limiting access immediately in 2024 for non-LTS users which is LXD >=5.18, or "unstable" in Gentoo. LTS LXD, or "stable" (5.0) in Gentoo will be allowed to pull images until May (an estimate), or until Incus LTS will be released. Times are subject to change. What can you do? ================ 1: Switch to Incus. 2: Deploy your own image server. 3: Wait and see what Canonical does. For unstable users the matter is rather critical, while stable users have the luxury of waiting. Note that a downgrade from unstable to stable is not possible due to database schemas. Please follow or take a look at Gentoo bug #920527 with more information about this situation, and updates e.g. for timetables. Bug: https://bugs.gentoo.org/920527
Posted By: Joonas Niilola
CUPS no longer directly depends on its filters - 20/11/2023 00:00 GMT
Reasons ======= Historically, net-print/cups has both depended on and been a dependency of net-print/cups-filters. The latter is required for usability of a CUPS printing setup, but also must build against the former's libraries. This results in an ugly dependency cycle, and forcing the entire CUPS printing setup wherever USE=cups is enabled on a framework. Current upstream work on CUPS has focused on modularizing the codebase. There are now several packages, and there will be more in the future. Installing net-print/cups-filters is no longer sufficient to ensure all components are installed. In the future, when CUPS v3 is released, filters will be exclusive to legacy printers, and largely replaced with IPP Everywhere.[1] A more future-proof way to install a CUPS production printing setup is needed. User Action Required ======= cups-filters is required for current versions of CUPS. To prevent depcleaning if you are a CUPS user (and it was not installed just as a dependency for something else): emerge net-print/cups-meta If cups-browsed support is desired, add the following package.use: net-print/cups-meta browsed [1] https://openprinting.github.io/current/#the-new-architecture-for-printing-and-scanning
Posted By: Eli Schwartz
Plasma Profile to enable PipeWire, Wayland support - 21/05/2023 00:00 GMT
Reasons ======= Gentoo's Plasma profile has not had any sound server enabled since the days of KDE's own aRts. As the way we output sound has changed dramatically in the years since - using wireless or often several devices, dynamically connected and shared between multiple systems, a modern desktop environment is expected to handle this effortlessly by default. In Wayland sessions, the video functionality of PipeWire is not only used for screensharing but also to take screenshots and -recordings or simply to cast window content onto task managers' window previews. This is why PipeWire and Wayland enablement are happening at the same time. Plasma Wayland support has come a long way and we consider it stable enough for daily use with a lot - if not all - systems, even if some known papercuts remain [1]. Therefore it makes sense for Plasma profile to provide sane default settings. Changes ======= New global USE flags enabled: pipewire, pulseaudio, screencast, wayland New package.use default: media-video/pipewire[sound-server] We want broad sound server support in packages, and these settings will make PipeWire act as our PulseAudio server where there is no native PipeWire support. Impact On Happy X Users ======================= Minor. Most dependencies were already required with kde-plasma/plasma-desktop and its dependencies. Upcoming stable versions of kde-apps/spectacle and kde-apps/krfb will depend on (K)PipeWire unconditionally. No one will lose their X session, but will have the option to easily log in to a working Wayland session at any time. It is possible to set USE="-wayland" against these changes, but it will amount to no dependency savings, just micro-optimisation in affected packages. User Action Required ==================== In order to enact all changes: emerge -1avUD @world Check out how to configure PipeWire for your purpose [2][3] In order to keep a PulseAudio or ALSA-only setup: Invert above new USE flag settings as needed, see also [2]. In order to avoid media-video/pipewire completely: This can only be achieved by losing basic task manager, screenshot/screen recording/sharing functions as provided by Plasma and KDE applications. [1] https://community.kde.org/Plasma/Wayland_Showstoppers [2] https://www.gentoo.org/support/news-items/2022-07-29-pipewire-sound-server. html [3] https://wiki.gentoo.org/wiki/PipeWire
Posted By: Andreas Sturmlechner
OpenSSH directory configuration changes - 11/05/2023 00:00 GMT
Gentoo's OpenSSH package will start using the /etc/ssh/sshd_config.d and /etc/ssh/ssh_config.d directories for both Gentoo default settings and use by the administrator. The default /etc/ssh/sshd_config and /etc/ssh/ssh_config files will respectively include configuration files in /etc/ssh/sshd_config.d/* and /etc/ssh/ssh_config.d/*, making it possible for all customization and configuration to be done via 'drop-in' files if desired. Most users will not need to take any action. The only action required is if specific Gentoo defaults were overridden in the past, as the new ebuilds will install them to new files in the new listed directories. Such admins will need to edit the new files in the new directories or make overrides in their own files in the new directories using a smaller number in the filename. For example, if the system administrator has commented out 'AcceptEnv COLORTERM' in /etc/ssh/sshd_config, they will need to do the same in the new /etc/ssh/sshd_config.d/9999999gentoo.conf file.
Posted By: Sam James
Python 3.11 to become the default on 2023-05-01 - 02/04/2023 00:00 GMT
We are planning to switch the default Python target of Gentoo systems on 2023-05-01, from Python 3.10 to Python 3.11. If you have not changed the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will have immediate effect on your system and the package manager will try to switch automatically on the next upgrade following the change. If you did change the values, prefer a safer approach or have problems with the update, read on. Please note that the default upgrade method switches packages to the new Python versions as they are rebuilt. This means that all interdependent packages have to support the new version for the upgrade to proceed, and that some programs may temporarily fail to find their dependencies throughout the upgrade (although programs that are already started are unlikely to be affected). At the same time, the support for Python 3.9 target will be removed from the eclasses. The interpreter package will remain supported for as long as feasible though. PyPy3.9 will remain supported until PyPy3.10 comes out and becomes stable. If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared in make.conf, please remove these declarations as they will interfere with the package.use samples provided below. Using make.conf for Python targets is discouraged as it prevents package defaults from applying when necessary. This news item assumes using /etc/portage/package.use or your package manager's equivalent file for configuration. At this point, you have a few configuration options to choose from: 1. If you wish Python upgrades to apply automatically, you can remove PYTHON_TARGETS and PYTHON_SINGLE_TARGET declarations. When the defaults change, your package manager should handle the upgrade automatically. However, you may still need to run the update commands if any problems arise. 2. If you wish to defer the upgrade for the time being, you can explicitly set the old values in package.use. 3. If you wish to force the upgrade earlier, you can explicitly set the new values and run the upgrade commands. 4. If you wish to use a safer approach (i.e. less likely to temporarily break packages during the upgrade), you can perform a multi-step upgrade as outlined below. 5. Finally, you can use an arbitrary combination of PYTHON_TARGETS and PYTHON_SINGLE_TARGET. Deferring the upgrade ===================== To defer the upgrade, explicitly set the old targets: */* PYTHON_TARGETS: -* python3_10 */* PYTHON_SINGLE_TARGET: -* python3_10 This will enforce Python 3.10 and block any future updates. However, please note that this is only a temporary solution and you will eventually need to perform the migration. Forcing the upgrade =================== To force the upgrade earlier, explicitly select the Python 3.11 targets: */* PYTHON_TARGETS: -* python3_11 */* PYTHON_SINGLE_TARGET: -* python3_11 However, it is important to remember to remove this after the defaults change, as it will interfere with the automatic switch to the next Python version in the future. Safer upgrade procedure ======================= A safer approach is to add Python 3.11 support to your system first, and only then remove Python 3.10. However, note that this involves two rebuilds of all the affected packages, so it will take noticeably longer. First, enable both Python 3.10 and Python 3.11, and then run the upgrade commands: */* PYTHON_TARGETS: -* python3_10 python3_11 */* PYTHON_SINGLE_TARGET: -* python3_10 Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades: */* PYTHON_TARGETS: -* python3_10 python3_11 */* PYTHON_SINGLE_TARGET: -* python3_11 Finally, switch to the final version and upgrade: */* PYTHON_TARGETS: -* python3_11 */* PYTHON_SINGLE_TARGET: -* python3_11 You may wish to remove the target overrides after the defaults switch. Alternatively, you can keep them to block the next automatic upgrade to Python 3.12, and upgrade manually then. Upgrade commands ================ The Python 3.10 cleanup requires that Python 3.10 is removed from the complete dependency trees in batch. If some of the installed packages using an older Python version are not triaged for the upgrade, the package manager will throw dependency conflicts. This makes it important that the upgrade is carried via a --deep --changed-use @world upgrade, as well as that any stray packages are removed prior to it, e.g.: emerge --depclean emerge -1vUD @world emerge --depclean
Posted By: Michał Górny