Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
> On Tue, 02 Jan 2024, Eli Schwartz wrote: > +++ > b/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt The short-name is rather long. GLEP 42 strongly recommends to stay below 20 characters: https://www.gentoo.org/glep/glep-0042.html#news-item-identities > +Title: Separate /usr now requires an initramfs > +Author: Eli Schwartz > +Content-Type: text/plain > +Posted: 2024-01-02 > +Revision: 1 > +News-Item-Format: 2.0 > +Display-If-Installed: sys-apps/baselayout[split-usr] This is not a valid header. (Format 2.0 doesn't have Content-Type.) > +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 The 2013-09-27-initramfs-required news item already said: | Linux systems which have / and /usr on separate file systems but do not | use an initramfs will not be supported starting on 01-Nov-2013. | | If you have / and /usr on separate file systems and you are not | currently using an initramfs, you must set one up before this date. | Otherwise, at some point on or after this date, upgrading packages | will make your system unbootable. It is also in the Handbook since 2014: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Optional:_Building_an_initramfs What has changed that we would need another news item? Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
>> +++ >> b/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt > The short-name is rather long. [...] In fact, the filename is also invalid by GLEP 42. Sorry for missing this the first time. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
Ulrich Mueller writes: > [[PGP Signed Part:Undecided]] >> On Tue, 02 Jan 2024, Eli Schwartz wrote: > >> +++ >> b/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt > > The short-name is rather long. GLEP 42 strongly recommends to stay below > 20 characters: > https://www.gentoo.org/glep/glep-0042.html#news-item-identities > >> +Title: Separate /usr now requires an initramfs >> +Author: Eli Schwartz >> +Content-Type: text/plain >> +Posted: 2024-01-02 >> +Revision: 1 >> +News-Item-Format: 2.0 >> +Display-If-Installed: sys-apps/baselayout[split-usr] > > This is not a valid header. (Format 2.0 doesn't have Content-Type.) > >> +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 > > The 2013-09-27-initramfs-required news item already said: > > | Linux systems which have / and /usr on separate file systems but do not > | use an initramfs will not be supported starting on 01-Nov-2013. > | > | If you have / and /usr on separate file systems and you are not > | currently using an initramfs, you must set one up before this date. > | Otherwise, at some point on or after this date, upgrading packages > | will make your system unbootable. > > It is also in the Handbook since 2014: > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Optional:_Building_an_initramfs > > What has changed that we would need another news item? The fact that we continued to support it means we had various confused users (like in the cited bug 868306). The job was never finished, with usr-ldscript remaining pervasive in the tree, and then it appearing supported - or at least not unsupported. > > Ulrich > > [[End of PGP Signed Part]]
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
Eli Schwartz: [...] > +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. [...] Well, that is not technically correct, just have the required kernel drivers (eg. AHCI and ext2/4) compiled in and use the same busybox commands as in the initrd, but placed in /, to bring up the system to the point that /usr is mounted. I have a static dev, compiled in drivers, busybox init and mount, and separate / and /usr on a box here, works perfectly well. Soo, add a clause about what gentoo supports out of the box and that you can make it work if you wish. If there is a general wish I can write an article about how to make it work. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
k...@aspodata.se writes: > Eli Schwartz: > [...] >> +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. > [...] > > Well, that is not technically correct, just have the required kernel > drivers (eg. AHCI and ext2/4) compiled in and use the same busybox > commands as in the initrd, but placed in /, to bring up the system > to the point that /usr is mounted. > > I have a static dev, compiled in drivers, busybox init and mount, and > separate / and /usr on a box here, works perfectly well. > Soo, add a clause about what gentoo supports out of the box and that > you can make it work if you wish. Is there a need to state this? To me, it feels obvious, and falls into the category of 'you can do it but don't expect much help'. As an example of entries in this category, I used to use runit for service management and supervision, and only used the openrc boot target. Naturally, this worked, but it worked due to me maintaining it, and had no Gentoo-provided support. The same is true for many, many configurations, so I don't see the need to state that explicitly. > If there is a general wish I can write an article about how to make > it work. > > Regards, > /Karl Hammar > > --- > Aspö Data > Lilla Aspö 148 > S-742 94 Östhammar > Sweden -- Arsen Arsenović signature.asc Description: PGP signature
[gentoo-dev] Testing request: sys-kernel/gentoo-kernel-bin[generic-uki]
Dear all, First of all happy new year! Those of you that have already synced the tree this year might have already noticed that gentoo-kernel(-bin) has gained two new USE flags yesterday. The first (USE=modules-compress) I think is pretty self-explanatory, it installs all modules xz compressed. The second new USE flag is USE=generic-uki, this will install the kernel along with a prebuilt, experimental(!), generic initramfs and unified kernel image. Let me explain first why this is something you might want to use. A Unified Kernel Image[1] combines the initramfs, cmdline, kernel and some other things into a single EFI executable. This is great because it allows the whole thing to be signed, and verified when booting with Secure Boot[2] enabled. Whereas in the usual plain kernel image + initramfs configuration, only the former is verified, leaving the possibility of injecting something malicious into the initramfs. We have supported generating your own Unified Kernel Images for some time now. However, since building the UKI must always happen after building the initramfs, which happens locally in postinst, this has so far always relied on users generating and protecting their own UKI-signing key. This is where USE=generic-uki comes in, it allows users to take full advantage of the extra verification UKIs offer, without the hassle of managing and protecting a custom signing key. Though I know this works in my setups, there are still some open questions and more testing in different setups is needed to determine how generic our generic image actually is. We include many things in this generic initramfs, but it is not feasible for me to test all of the possible booting scenarios, so this is where we can use the help of the community. Some of the open questions are: - OpenRC compatibility: Since this is a generic image and because it is not possible to override a UKIs cmdline at boot when secure boot is enabled, we cannot rely on root= to tell us where the root partition is. Instead we rely on systemd-gpt-auto-generator[3] to dynamically determine the correct partition layout. To what extent the inclusion of systemd and its utilities in the initramfs impacts the possibility of booting an openrc system with the generic UKI is still unknown. (Though I have a suspicion that systemd will not be happy about handing over control to another init system, and that therefore it might not work at all.) - Network booting: We include the dracut modules that should in theory make the resulting UKI support network booting. However this is still untested. - Measured Boot: Ukify does the systemd-measure magic that should in theory make it possible to unlock secrets conditionally on whether the PCR registers match the predetermined value (i.e. Measured Boot). This has not yet been tested (mostly because the TPM on my system is behaving a bit odd, and I lack the experience with TPMs to determine why and how to resolve it). It would be great if folks could give our generic-uki a test drive to help us explore what works, and what does not. All feedback is welcome on #gentoo-dist-kernel or via bug report. Here's a brief list of steps to set this up: - Enable USE=generic-uki on gentoo-kernel-bin - If installkernel-systemd is used, configure it as follows in /etc/kernel/install.conf: layout=uki uki_generator=none initrd_generator=none - If installkernel-gentoo is used, enable USE=uki - (re-)emerge gentoo-kernel-bin - If shim/mokutil is used, import our certificate: mokutil --import /usr/src/linux-6.6.9-gentoo-dist/certs/signing_key.x509 - If shim/mokutil is not used, but secureboot is still desired, ensure our certificate will be accepted by the UEFI (steps depend on the vendor) - Ensure a known-working alternative kernel/UKI is also present - If refind is used, configure it to find the new UKI. If systemd-boot is used it will be auto-discovered and no further setup is required. - Reboot If any of the documentation on the wiki is unclear, then please also let me know so I can improve it. Some frequently asked questions: - What bootloaders are supported?: systemd-boot, refind. And possibly version 2.12 and up of grub. - Can I use the prebuilt generic initramfs image, without using the generic UKI, or use the generic initramfs to generate my own custom UKI?: Yes, see [5]. - Can I combine this with USE=modules-compress?: Yes - Are boot splashes supported?: No, including plymouth in the initramfs requires including the gpu drivers and firmware as well. These files are huge and they are many. At this time the cost of the increased uki and gpkg size is not something we are willing to pay. If there are any other questions feel free to drop by #gentoo-dist-kernel. Best regards, Andrew [1] https://wiki.gentoo.org/wiki/Unified_kernel_image [2] https://wiki.gentoo.org/wiki/Secure_Boot [3] https://wiki.gentoo.org/wiki/Systemd#Automatic_mounting_of_partitions_at_boo
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
On 1/2/24 3:22 AM, Ulrich Mueller wrote: >> On Tue, 02 Jan 2024, Eli Schwartz wrote: > >> +++ >> b/2024-01-02-separate-usr-now-requires-an-initramfs/2024-01-02-separate-usr-now-requires-an-initramfs.txt > > The short-name is rather long. GLEP 42 strongly recommends to stay below > 20 characters: > https://www.gentoo.org/glep/glep-0042.html#news-item-identities > >> +Title: Separate /usr now requires an initramfs >> +Author: Eli Schwartz >> +Content-Type: text/plain >> +Posted: 2024-01-02 >> +Revision: 1 >> +News-Item-Format: 2.0 >> +Display-If-Installed: sys-apps/baselayout[split-usr] > > This is not a valid header. (Format 2.0 doesn't have Content-Type.) Thanks, I was too hasty in my double-checking -- I fixed all 3 formatting bugs locally. >> +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 > > The 2013-09-27-initramfs-required news item already said: > > | Linux systems which have / and /usr on separate file systems but do not > | use an initramfs will not be supported starting on 01-Nov-2013. > | > | If you have / and /usr on separate file systems and you are not > | currently using an initramfs, you must set one up before this date. > | Otherwise, at some point on or after this date, upgrading packages > | will make your system unbootable. > > It is also in the Handbook since 2014: > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Optional:_Building_an_initramfs > > What has changed that we would need another news item? > > Ulrich As Sam said, the idea is to give people a heads up that they have to do something to adapt -- given it's been 10+ years, it feels a bit not-good to suddenly carry out the original promise without warning. This is a good reason why when something is promised, it should actually be done on schedule... Given everything was already decided and signed off on, there's no need to rehash whether or not to do it. We can just do it. But users should get a heads up that there is something they need to do to ensure their system will be working -- and 10+ years is simply too much of a gap between the time of the news and the time of fulfillment. -- Eli Schwartz
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
On 1/2/24 4:15 AM, k...@aspodata.se wrote: > Eli Schwartz: > [...] >> +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. > [...] > > Well, that is not technically correct, just have the required kernel > drivers (eg. AHCI and ext2/4) compiled in and use the same busybox > commands as in the initrd, but placed in /, to bring up the system > to the point that /usr is mounted. > > I have a static dev, compiled in drivers, busybox init and mount, and > separate / and /usr on a box here, works perfectly well. > Soo, add a clause about what gentoo supports out of the box and that > you can make it work if you wish. > If there is a general wish I can write an article about how to make > it work. You need the required kernel drivers regardless of having /usr on a separate partition. The problem here is solely about after the kernel has booted, mounted the / filesystem, and run init -- init needs to fully bring the system up. While it's no doubt possible to do this with finely-crafted busybox usage, there's a lot of ways it could break if you aren't *very* careful, and that should not require ongoing support. It's firmly in the "you break it, you bought it" category. But I have no objection if it's mentioned on the wiki in the initramfs article or somewhere similar. I don't think this is a blocker for dropping hacks like usr-ldscript.eclass usage, though. -- Eli Schwartz OpenPGP_0x84818A6819AF4A9B.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
Hello Eli, Maybe add also a link to: https://wiki.gentoo.org/wiki/Early_Userspace_Mounting (IMHO this article is a better starting point than https://wiki.gentoo.org/wiki/Custom_Initramfs ) Many Greetings, Peter
[gentoo-dev] [PATCH] distutils-r1.eclass: Add support for dev builds in setuptools-rust
Signed-off-by: Michał Górny
---
eclass/distutils-r1.eclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/eclass/distutils-r1.eclass b/eclass/distutils-r1.eclass
index 5a99ba88eddb..4e77237c3009 100644
--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -1401,6 +1401,9 @@ distutils_pep517_install() {
)
;;
setuptools)
+ if in_iuse debug && use debug; then
+ local -x SETUPTOOLS_RUST_CARGO_PROFILE=dev
+ fi
if [[ -n ${DISTUTILS_ARGS[@]} ]]; then
config_settings=$(
"${EPYTHON}" - "${DISTUTILS_ARGS[@]}"
<<-EOF || die
--
2.43.0
[gentoo-dev] Last rites: net-mail/courier-makedat
# Alfredo Tupone (2024-02-02) # No more used by any package (bug #921167) # remove in 30 days net-mail/courier-makedat -- Best regards, Alfredo Tupone
Re: [gentoo-dev] [PATCH] 2024-01-02-separate-usr-now-requires-an-initramfs: add news item
Arsen:: > k...@aspodata.se writes: > > Eli Schwartz: ... > >> +Systems which have /usr and / on separate filesystems have always > >> required a > >> +dedicated initramfs to bring up both partitions. ... > Is there a need to state this? ... "Always required" is false. Not supported by gentoo is correct. Regards, /Karl Hammar
[gentoo-dev] Package up for grabs: net-im/skypeforlinux
I have updated net-im/skypeforlinux to the latest upstream version before dropping myself as a maintainer of this package. I believe that in 2024 Skype as a technology has become pretty much obsolete and have removed it from all my machines at this point. There are two open bugs. Regards David signature.asc Description: This is a digitally signed message part
