Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
This is getting really long, so I'm going to remove more things I'm not answering directly. On Sun, Mar 28, 2021 at 07:31:02PM -0400, Joshua Kinard wrote: > > The problem is, there's a chicken-and-egg problem in the scenario where > > / and /usr are on separate partitions, and this is why a number of linux > > distros have moved to requiring an initramfs in this situation. > > I'm linking systemd's description here, only because it is the best > > writeup of the issue I've found [1]. > > Anything that is needed in the early boot process requires all of its > > libraries, > > dependent libraries, binaries, data files, etc to be on /, and this has > > become a moving target. > > Yeah, I've read systemd's explanation, and generally disagree with it. They > created the problem in the first place, then invented their own solution for > it, and now everyone acts like they're the wise men on the mountain for it. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html Rob Landley had a lot to say about how linux should be using initramfs to handle early boot long before systemd came along, so this has been an issue a lot longer than systemd; the systemd guys just amplified it. > I still don't see the connection to the static *.a libs and whether they're > on /lib or /usr/lib, though. Unless we're implying that where the *.a's go, > so too do the *.so's go, then THAT makes sense because *.so's ARE needed at > program runtime, whereas *.a's are not. It is a linker behavior issue we discovered and worked around. In the past, Gentoo has gone an extra mile to make some things useable by people who have separate /usr without an initramfs by moving only shared libraries to /lib*. We leave everything else that would be in libdir in the default location which is /usr/lib*. This includes things like static libs, pkgconfig files etc. When we started doing this we found that the linker favors libraries in /usr/lib* over libraries in /lib*, so if you are linking to libfoo and there's a static version in /usr/lib* and a shared version in /lib* you will link to the static version. That's what bug 4411 is about. gen_usr_ldscript gets around this by creating a linker script at the original location of the shared library in /usr/lib* when it moves the shared library to /lib*. See /usr/lib64/libbz2.so for an example of the generated linker script. Getting rid of gen_usr_ldscript would move the shared libraries back to their upstream location (/usr/lib*) and remove the linker scripts. This would also allow the removal of the usr-ldscript eclass and the gen_usr_ldscript function from eutils.eclass. The up side of this is that it allows us to get rid of some of our custom code in ebuilds, and it is completely transparent to most of our user base. The down side is that if you are using separate /usr with no initramfs, libraries that you were accessing in /lib* during early boot will moved to /usr/lib* and not be available before /usr is mounted. This would cause breakage until you reconfigured your system to boot with an initramfs and mount / and /usr before jumping into the real system. > I wonder if we couldn't shovel all static libs off to a dedicated folder > somewhere, like '/usr/lib/static//*.a', similar to the way debug files > are now consolidated under '/usr/lib/debug'. Since they're only needed > during a specific kind of compilation that we don't support out-of-the-box > that happens long after the system is fully booted, stuffing them off > somewhere unimportant would make some sense. Most modern software should be > using shared libs by default, and if it ain't, that's either a bug or that > software is for a very specific function (like a bootloader). If you started creating separate static libs folders you would need one per abi, so it would end up being pretty ugly. We don't build that many static libraries right now, so I'm not sure it is worth moving them to some other folder. If we put the shared libs back in the upstream expected location (/usr/lib*) we would eliminate the linker issue. *snip* > > The way I see it, when we start to remove the gen_usr_ldscript calls, > > people using a sep-usr mount without an initramfs will run into one or > > both of these issues: > > > > - they might have to increase the size of their root partition depending > > on what gets added to /lib* > > - if one package in that list drops gen_usr_ldscript without installing > > libraries in /lib*, it will mean they need an initramfs. > > I tend to make my root partitions ~4GB, which has often been plenty of room > for well over 15 years. But again, location of the *.a static libs is > irrelevant during system boot. They are not needed nor referenced when a > program executes. A statically-compiled program has all of its dependencies > lumped inside of it, so you could put it pretty much anywhere on the > filesystem and run it (ignoring for a moment 'noexec' potentially being > set). Or even mo
Re: [gentoo-dev] developing a separate repo spec
> On Mon, 29 Mar 2021, Tim Harder wrote: > Is there any interest these days in developing and maintaining a > separate repo spec [1]? Among other uses, it would help in describing > standardized repo features related to metadata/layout.conf settings > allowing devs to reference a single, canonical source in order to > support repo/profiles features. > The current spec doesn't define many repo specific features leading to > people jamming all sorts of conditional features in metadata/layout.conf > via profile-formats and other entries, none of which is defined in the > current spec. > Mostly I'm asking because I'm tired of trying to support a pseudo-spec > and am quite close to dropping pkgcore's support for the few > profile-formats features it tries to enable. Why not make it a chapter of PMS? A separate document would presumably imply having a repository API (RAPI?) decoupled from EAPI? Ulrich signature.asc Description: PGP signature
[gentoo-dev] [PATCH] xorg-3.eclass: strip -fno-plt from *FLAGS
From: Niklāvs Koļesņikovs <89q1r1...@relay.firefox.com> As discussed in #778494, the GCC flag -fno-plt will break lazy binding, which appears to still be necessary for Xorg. Stripping the offending flag out is the next best solution for reliable user experience on Gentoo. Closes: https://bugs.gentoo.org/778494 Closes: https://github.com/gentoo/gentoo/pull/20166 Signed-off-by: Niklāvs Koļesņikovs <89q1r1...@relay.firefox.com> Signed-off-by: Matt Turner --- eclass/xorg-3.eclass | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass index 811168ead98..6835c6617c5 100644 --- a/eclass/xorg-3.eclass +++ b/eclass/xorg-3.eclass @@ -1,4 +1,4 @@ -# Copyright 1999-2020 Gentoo Authors +# Copyright 1999-2021 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # @ECLASS: xorg-3.eclass @@ -326,8 +326,10 @@ xorg-3_flags_setup() { # Win32 require special define [[ ${CHOST} == *-winnt* ]] && append-cppflags -DWIN32 -D__STDC__ # hardened ldflags - [[ ${PN} == xorg-server || ${PN} == xf86-video-* || ${PN} == xf86-input-* ]] \ - && append-ldflags -Wl,-z,lazy + if [[ ${PN} == xorg-server || ${PN} == xf86-video-* || ${PN} == xf86-input-* ]]; then + filter-flags -fno-plt + append-ldflags -Wl,-z,lazy + fi # Quite few libraries fail on runtime without these: if has static-libs ${IUSE//+}; then -- 2.26.2
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On 3/28/2021 05:25, James Le Cuirot wrote:> On Sat, 27 Mar 2021 18:40:52 -0400 Joshua Kinard > wrote: > >> On 3/27/2021 18:16, James Le Cuirot wrote: >>> On Sat, 27 Mar 2021 17:43:34 -0400 Joshua Kinard >>> wrote: >>> I kinda wish the Linux kernel had an ability to partially boot, init the networking subsystem, then fetch an initramfs image over TFTP like it can do with NFS Root. That would solve the problem on my MIPS system(s) (and make install netboots better). I've dug around, but this does not seem to be a capability currently in the kernel, unless I have over looked something. Otherwise in the future, I may just have to setup an initramfs into an NFS Root and teach the SGI's to somehow deal with it. Which all still seems unnecessarily complicated because some other distro thinks it knows what's best for everyone else (but I digress...). >>> >>> NBD may be a slightly simpler alternative and a bit more like an >>> initramfs. nbdkit can do all sorts of weird things. I thought it >>> might have a plugin for cpio archives, allowing you to use a regular >>> initramfs generated by Dracut or similar directly. It doesn't >>> appear to but plugins are quite easy to write. Alternatively you >>> could just extract the initramfs and use nbdkit-linuxdisk-plugin. >> >> Can NBD be used like I described? Never played with it before. The >> MIPS machine has functioning local disk drives, and currently, it >> boots fine by just pulling a kernel off my TFTP server and booting from >> the local drive, no initramfs needed because I compiled everything into >> it. If we ever force sep-usr to end, then I'll need a way to teach it >> to mount /usr before dropping into /bin/init (and nothing else). > > Apologies, I went to experiment with this idea but I'd forgotten that > booting over NBD is not a built-in kernel feature and requires... an > initramfs. NFS looks like the only option with this general approach. I've kinda come to this conclusion myself. I could probably host an extracted, micro-initramfs on my NFS server that would be loaded by the kernel to jump to $REAL_ROOT. Not *too* much of an issue on the Octane, because I can store the kernel command line args in a PROM variable so that all I have to do is type "$foo" at the PROM prompt to load something. But, SGI did their best to be inconsistent, and IP27 systems cannot permanently save variables to NVRAM. Once you power cycle, all user-defined PROM vars are lost. And Linux's NFS Root command args are somewhat complicated from what I remember. Upshot is I boot the IP27 over serial console, so I can just save bootp() args in a text file on my desktop and paste it into the console for those instances. In any event, I kinda wish there was some way to just boot the kernel to a point, have it copy an initramfs image via TFTP, load it, run it, jump to $REAL_ROOT. If I had the time, maybe I could put something together like that myself, but time is not something I have much of right now. > Rich is right though, the initramfs can be tiny. Dracut images are heavy > because they are very flexible and pack a lot of features but none of > that is required. > > The kexec idea would be a nice bonus for you, if it works. Limiting what > kernel features you can enable must be frustrating. My primary kernel image for daily use on the Octane isn't terribly limited. The final vmlinux output is ~39MB, due to loading debugging symbols in. But the cutoff in size for Octane seems to be somewhere around 43-45MB, before the PROM errors out due to no available contiguous FreeMemory() areas (the mem region defined by the ARCS PROM where stuff can be loaded and executed). Netboot kernels for installs can creep up there if you go too crazy on kernel features and pack the netboot with supporting packages (mainly filesystem tools). This already impacts older systems, like SGI Indy, which cannot boot current MIPS netboot images because they have smaller FreeMemory() areas. I thought switching to musl would make the netboots smaller, but that oddly didn't work and musl netboots are about ~2MB larger than the older uclibc-ng versions. And all of my uclibc-ng stages have become unusable for some unknown reason. As soon as you rebuild ncurses in one, all binaries linked to it throws SIGSEGVs (which kills portage). glibc-based netboots are too big and will not load at all, even on the Octane. > It's also worth bearing in mind that you could just generate an image > with Dracut and extract it to a disk partition. That may seem a little > pointless if you're not using something like LVM or encryption but I > don't see the point in separate /usr either. ;) I'm guessing you don't > want to change your partition layout at this point though. No, no LUKS, encryption, btrfs, etc. Just mdraid w/ 0.90 metadata for auto-assemble. Which is why I hate having to use an initramfs for something so simple. Unnecessary comple
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On 3/28/2021 16:05, William Hubbs wrote: > On Sat, Mar 27, 2021 at 10:51:11PM -0400, Joshua Kinard wrote: >> On 3/27/2021 20:32, William Hubbs wrote: >>> On Sat, Mar 27, 2021 at 05:43:34PM -0400, Joshua Kinard wrote: On 3/23/2021 07:31, Rich Freeman wrote: > On Mon, Mar 22, 2021 at 6:54 PM Andreas K. Huettel > wrote: >> Council decided years ago that we don't support separate /usr without an initramfs, but we haven't completed that transition yet. >>> >>> Which doesn't imply that we deliberately break things. >> >> That's right. Though we should at some point start thinking about an end >> of support for separate usr without initramfs. >> > > Just to clarify - it is already unsupported at a distro level. It is > just that some individual packages still work with it. > > The current Council decisions on the issue are (just providing for > general reference): > > - "Since that particular setup may already be subtly broken today > depending on the installed software, Council recommends using an > early boot mount mechanism, e.g. initramfs, to mount /usr if /usr > is on a separate partition." > Accepted unanimously. [1] > > - "The intention is to eventually not require maintainers to support > a separate /usr without an early boot mechanism once the Council > agrees that the necessary docs/migration path is in place." > Accepted with 4 yes votes, 1 no vote, 2 abstentions. [1] > > - "The Council agrees that all preparations for dropping support for > separate /usr without an initramfs or similar boot mechanism are > complete. A news item will be prepared, and users will be given one > month to switch after the news item has been sent." > Accepted with 5 yes votes, 1 no vote, 1 abstention. [2] > > Current policy documentation: > Developers are not required to support using separate /usr filesystem > without an initramfs. [3] > > 1 - https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt > 2 - https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt > 3 - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202 Is there a list of software/ebuilds that currently do this "subtle" handling of separate /usr w/o initramfs? I've got just my MIPS systems left that use a separate /usr and do not boot with initramfs because I build fully monolithic kernels and that makes the resulting vmlinux images run up against hard size limits in the SGI PROM (firmware, BIOS, etc) on these machines if I try to pack too large of an initramfs in. I can check for any software that may be switched over soon to a hard initramfs requirement and look at my options. >>> >>> One group of packages involved in this is any package that calls >>> gen_usr_ldscript. We have this function for a couple of reasons. >>> >>> Gentoo has a policy that bans *.a static libraries from being >>> installed in /lib*. I think this policy is unique to Gentoo, >>> because Most build systems I've seen do not >>> have separate paths for static vs dynamic libraries, so all libraries >>> from a package are installed in /usr/lib* or /lib*. This policy was >>> originally hard coded into portage some time back (I can find the commit >>> if you want it) before it was made a formal policy by the qa team. >>> It has since become a formal policy. >>> >>> Because of this policy, we have to tell upstream build systems to >>> install libraries in ${ED}/usr/$(get_libdir). This is fine unless you >>> have separate usr with no initramfs. In that case, you have binaries on >>> / that link to shared libraries on /usr. When we saw this happening, we >>> started manually moving shared libraries from /usr/lib* to /lib* if >>> someone needed the package at boot time. Then we hit bug 4411 [1] >>> where the linker was prioritizing static libraries in /usr/lib* over shared >>> libraries in /lib*. >>> >>> I don't know if we tried to address that upstream or not, but ultimately >>> gen_usr_ldscript came out of it. >>> >>> Several folks have wanted to get rid of this function for years [2]. >>> >>> I have looked into it before, and there are several things that can be done. >>> >>> We can have packages that currently build static libraries and >>> use gen_usr_ldscript stop building static libraries and use the >>> appropriate setting in their build systems to install libraries in >>> /$(get_libdir). This is the path OpenRC is taking per request of the qa >>> lead. The next release will not support the static-libs use flag. This >>> will actively break anyone who is expecting this use flag to exist for >>> OpenRC. >>> >>> If a package does not build static libraries in the first place, there is >>> really no reason to call gen_usr_ldscript; the ebuild should be using >>> the upstream build s
[gentoo-dev] Packages up for grabs: x11-misc/piedock
Dear all the following packages are up for grabs after dropping desktop-misc: x11-misc/piedock https://packages.gentoo.org/packages/x11-misc/piedock It does not compile and needs patches. Upstream is informed too. We will have to last rite, if it is not fixed soon. I send in CC to Lars, who committed upstream some time ago. -- Best, Jonas
[gentoo-dev] developing a separate repo spec
Hi all, Is there any interest these days in developing and maintaining a separate repo spec [1]? Among other uses, it would help in describing standardized repo features related to metadata/layout.conf settings allowing devs to reference a single, canonical source in order to support repo/profiles features. The current spec doesn't define many repo specific features leading to people jamming all sorts of conditional features in metadata/layout.conf via profile-formats and other entries, none of which is defined in the current spec. Mostly I'm asking because I'm tired of trying to support a pseudo-spec and am quite close to dropping pkgcore's support for the few profile-formats features it tries to enable. Thanks, Tim [1]: https://bugs.gentoo.org/417013
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On Sat, Mar 27, 2021 at 10:51:11PM -0400, Joshua Kinard wrote: > On 3/27/2021 20:32, William Hubbs wrote: > > On Sat, Mar 27, 2021 at 05:43:34PM -0400, Joshua Kinard wrote: > >> On 3/23/2021 07:31, Rich Freeman wrote: > >>> On Mon, Mar 22, 2021 at 6:54 PM Andreas K. Huettel > >>> wrote: > > >> Council decided years ago that we don't support separate /usr without > >> an initramfs, but we haven't completed that transition yet. > > > > Which doesn't imply that we deliberately break things. > > That's right. Though we should at some point start thinking about an end > of support for separate usr without initramfs. > > >>> > >>> Just to clarify - it is already unsupported at a distro level. It is > >>> just that some individual packages still work with it. > >>> > >>> The current Council decisions on the issue are (just providing for > >>> general reference): > >>> > >>> - "Since that particular setup may already be subtly broken today > >>> depending on the installed software, Council recommends using an > >>> early boot mount mechanism, e.g. initramfs, to mount /usr if /usr > >>> is on a separate partition." > >>> Accepted unanimously. [1] > >>> > >>> - "The intention is to eventually not require maintainers to support > >>> a separate /usr without an early boot mechanism once the Council > >>> agrees that the necessary docs/migration path is in place." > >>> Accepted with 4 yes votes, 1 no vote, 2 abstentions. [1] > >>> > >>> - "The Council agrees that all preparations for dropping support for > >>> separate /usr without an initramfs or similar boot mechanism are > >>> complete. A news item will be prepared, and users will be given one > >>> month to switch after the news item has been sent." > >>> Accepted with 5 yes votes, 1 no vote, 1 abstention. [2] > >>> > >>> Current policy documentation: > >>> Developers are not required to support using separate /usr filesystem > >>> without an initramfs. [3] > >>> > >>> 1 - https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt > >>> 2 - https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt > >>> 3 - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202 > >> > >> Is there a list of software/ebuilds that currently do this "subtle" > >> handling > >> of separate /usr w/o initramfs? > >> > >> I've got just my MIPS systems left that use a separate /usr and do not boot > >> with initramfs because I build fully monolithic kernels and that makes the > >> resulting vmlinux images run up against hard size limits in the SGI PROM > >> (firmware, BIOS, etc) on these machines if I try to pack too large of an > >> initramfs in. I can check for any software that may be switched over soon > >> to a hard initramfs requirement and look at my options. > > > > One group of packages involved in this is any package that calls > > gen_usr_ldscript. We have this function for a couple of reasons. > > > > Gentoo has a policy that bans *.a static libraries from being > > installed in /lib*. I think this policy is unique to Gentoo, > > because Most build systems I've seen do not > > have separate paths for static vs dynamic libraries, so all libraries > > from a package are installed in /usr/lib* or /lib*. This policy was > > originally hard coded into portage some time back (I can find the commit > > if you want it) before it was made a formal policy by the qa team. > > It has since become a formal policy. > > > > Because of this policy, we have to tell upstream build systems to > > install libraries in ${ED}/usr/$(get_libdir). This is fine unless you > > have separate usr with no initramfs. In that case, you have binaries on > > / that link to shared libraries on /usr. When we saw this happening, we > > started manually moving shared libraries from /usr/lib* to /lib* if > > someone needed the package at boot time. Then we hit bug 4411 [1] > > where the linker was prioritizing static libraries in /usr/lib* over shared > > libraries in /lib*. > > > > I don't know if we tried to address that upstream or not, but ultimately > > gen_usr_ldscript came out of it. > > > > Several folks have wanted to get rid of this function for years [2]. > > > > I have looked into it before, and there are several things that can be done. > > > > We can have packages that currently build static libraries and > > use gen_usr_ldscript stop building static libraries and use the > > appropriate setting in their build systems to install libraries in > > /$(get_libdir). This is the path OpenRC is taking per request of the qa > > lead. The next release will not support the static-libs use flag. This > > will actively break anyone who is expecting this use flag to exist for > > OpenRC. > > > > If a package does not build static libraries in the first place, there is > > really no reason to call gen_usr_ldscript; the ebuild should be using > > the upstream build system to put the libraries where they
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
> On 28 Mar 2021, at 13:46, Ulrich Mueller wrote: > > >>> On Sun, 28 Mar 2021, David Seifert wrote: >> This is just bringing it in line with the rest of the eclass. You know, >> consistency. > > If that's the goal then the patch should update all occurences, though. Well, that was definitely the aim. To avoid any doubt, I don’t feel particularly passionate about which style we use so it was not the main point of this patch. Just copying existing style for consistency. > Especially those where usage is inconsistent within the same line. I’m mobile right now but maybe you could show me what you’re referring to? Thank you! We have review for a reason - to improve - but being vague doesn’t help me do that ;)
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
> On Sun, 28 Mar 2021, David Seifert wrote: > This is just bringing it in line with the rest of the eclass. You know, > consistency. If that's the goal then the patch should update all occurences, though. Especially those where usage is inconsistent within the same line. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
Hi, Thank you for doing this. LGTM modulo a few nits below. On Sat, 2021-03-27 at 22:21 +, Sam James wrote: > - if [[ ${EBUILD_PHASE} != "unpack" && ${EBUILD_PHASE} != "prepare" ]]; > then > - ewarn "QA Warning: running $1 in ${EBUILD_PHASE} phase" > + if [[ ${EBUILD_PHASE_FUNC} != "src_unpack" && ${EBUILD_PHASE_FUNC} != > "src_prepare" ]] ; then Maybe use 'has' here? > + eqawarn "Running '${1}' in ${EBUILD_PHASE_FUNC} phase" > fi > > > > > > > > > if ${missing_ok} && ! type -P ${1} >/dev/null ; then > - einfo "Skipping '$*' due $1 not installed" > + einfo "Skipping '$*' because '${1}' not installed" ...is not installed? ;-) -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
On Sat, 2021-03-27 at 22:21 +, Sam James wrote: > (Relatively) significant changes: > * inherit eutils for < EAPI 7 for eqawarn > * mark WANT_AUTO*, AUTOTOOLS_AUTO_DEPEND as @PRE_INHERIT > * convert phase test to EBUILD_PHASE_FUNC > * drop support for < EAPI 5 LGTM
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
On Sun, 2021-03-28 at 10:13 +0200, Ulrich Mueller wrote: > > > > > > On Sat, 27 Mar 2021, Sam James wrote: > > > -if [[ -z ${_AUTOTOOLS_ECLASS} ]]; then > > +if [[ -z ${_AUTOTOOLS_ECLASS} ]] ; then > > This just adds unnecessary noise to the git history. We don't have any > policy on whitespace before punctuation marks, but the examples in the > Bash manual don't have whitespace before semicolons. (Several more of > these changes in the reset of the commit.) This is just bringing it in line with the rest of the eclass. You know, consistency.
Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?
On Sat, 27 Mar 2021 18:40:52 -0400 Joshua Kinard wrote: > On 3/27/2021 18:16, James Le Cuirot wrote: > > On Sat, 27 Mar 2021 17:43:34 -0400 > > Joshua Kinard wrote: > > > >> I kinda wish the Linux kernel had an ability to partially boot, init the > >> networking subsystem, then fetch an initramfs image over TFTP like it can > >> do > >> with NFS Root. That would solve the problem on my MIPS system(s) (and make > >> install netboots better). I've dug around, but this does not seem to be a > >> capability currently in the kernel, unless I have over looked something. > >> > >> Otherwise in the future, I may just have to setup an initramfs into an NFS > >> Root and teach the SGI's to somehow deal with it. Which all still seems > >> unnecessarily complicated because some other distro thinks it knows what's > >> best for everyone else (but I digress...). > > > > NBD may be a slightly simpler alternative and a bit more like an > > initramfs. nbdkit can do all sorts of weird things. I thought it might > > have a plugin for cpio archives, allowing you to use a regular > > initramfs generated by Dracut or similar directly. It doesn't appear to > > but plugins are quite easy to write. Alternatively you could just > > extract the initramfs and use nbdkit-linuxdisk-plugin. > > Can NBD be used like I described? Never played with it before. The MIPS > machine has functioning local disk drives, and currently, it boots fine by > just pulling a kernel off my TFTP server and booting from the local drive, > no initramfs needed because I compiled everything into it. If we ever force > sep-usr to end, then I'll need a way to teach it to mount /usr before > dropping into /bin/init (and nothing else). Apologies, I went to experiment with this idea but I'd forgotten that booting over NBD is not a built-in kernel feature and requires... an initramfs. NFS looks like the only option with this general approach. Rich is right though, the initramfs can be tiny. Dracut images are heavy because they are very flexible and pack a lot of features but none of that is required. The kexec idea would be a nice bonus for you, if it works. Limiting what kernel features you can enable must be frustrating. It's also worth bearing in mind that you could just generate an image with Dracut and extract it to a disk partition. That may seem a little pointless if you're not using something like LVM or encryption but I don't see the point in separate /usr either. ;) I'm guessing you don't want to change your partition layout at this point though. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpAb6gauIo0N.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] autotools.eclass: eclassdoc, cosmetic changes, drop old EAPIs
> On Sat, 27 Mar 2021, Sam James wrote: > -if [[ -z ${_AUTOTOOLS_ECLASS} ]]; then > +if [[ -z ${_AUTOTOOLS_ECLASS} ]] ; then This just adds unnecessary noise to the git history. We don't have any policy on whitespace before punctuation marks, but the examples in the Bash manual don't have whitespace before semicolons. (Several more of these changes in the reset of the commit.) > - # Subdirs often share a common build dir #529404. If so, we can't > safely > + # Subdirs often share a common build dir, bug #529404. If so, we can't > safely Long line. > - if [[ ${EBUILD_PHASE} != "unpack" && ${EBUILD_PHASE} != "prepare" ]]; > then > - ewarn "QA Warning: running $1 in ${EBUILD_PHASE} phase" > + if [[ ${EBUILD_PHASE_FUNC} != "src_unpack" && ${EBUILD_PHASE_FUNC} != > "src_prepare" ]] ; then > + eqawarn "Running '${1}' in ${EBUILD_PHASE_FUNC} phase" What is wrong with checking EBUILD_PHASE? Ulrich signature.asc Description: PGP signature