Help with finding the source code for /usr/bin/init

[GameDevFox]

I'm looking for the source code for /usr/bin/init because I want to learn about the entire system from when the kernel is loaded to when all the services are run.

My understanding is that after the linux kernel loads the root filesystem it runs the 'init' process (which I understand to be /usr/bin/init), and then `init` starts everything else.

I tried using `equery` to find out which package provides /usr/bin/init which led me to discover that it's actually part of the `stage3` that I installed during setup.

The thing is, I can find source code easily for EVERYTHING in Gentoo EXCEPT the state3 tar ball.

Does anyone know where I can find the code the assembles the `stage3` so I can find out how it builds `init` and where it gets it's source code from?

For reference, the stage3 I'm using is: stage3-arm64-openrc-20240702T180413Z.tar.xz

Thank you

[szatox]

Hint:

[Hu]

Welcome to the forums.

Start with finding the package that owns the program in question. equery belongs helps here, and I suspect you already did that, since you say the file came in via the stage3. Once you know what package provides the program, emerge --fetchonly category/package will download the source of the package.

[jburns]

[GameDevFox]

[szatox]

Stage 3 tarballs are build with emerge using main portage tree ( ::gentoo).
There really is nothing special about them, you can equery b paths of interests to match them with ebuilds, and inspect ebuilds (or perhaps even query it) to get download paths.

/usr/bin/ doesn't look like a correct location for init. Root-only binaries are in /sbin, and /usr/sbin; init, as a PID 1 is also a special case that can be called from / directly. */bin/ is where programs intended for regular users go. I don't know why you have anything named init there.
_________________
Make Computing Fun Again

[pietinger]

[szatox]

I see. I've never switched the profile, so I guess it kinda makes sense. I mean the explanation, not the change
If installation goes the way I think it goes*, it is reasonable to expect a discrepancy between paths reported by which and paths recorded by portage. Looks like we've got an inconvenient interaction with PATH here.


*: emerge prepares to install init into /sbin, and records this path.
/usr/bin and /sbin are linked together, so they contain the same files
PATH lists /usr/bin/ before /sbin, so init is found in this location first, as reported by which
Effectively, emerge is tricked by the underlying filesystem into putting files in the wrong location. Like in: not where it expects.
_________________
Make Computing Fun Again

[Hu]

Correct, and there has been at least one bug report arising from this confusion. equery belongs wants to work with the paths that emerge recorded. emerge recorded the paths that it saw in $D, which are the paths the application thought it was using, before the symlinks redirected things. Possible solutions to this are:

• emerge should (re)arrange $D when using a merged-usr profile, so that the recorded paths in the gpkg reflect that all programs get dumped in /usr/bin. This would cause init to be in /usr/bin regardless of what symlinks are present on the installed filesystem.
• emerge should rewrite the VDB CONTENTS file to reflect what symlinks it followed when copying files to the live filesystem. The gpkg would still record the canonical path.
• All packages everywhere should be modified to install everything into /usr/bin, so that /bin, /sbin, and /usr/sbin need never exist even as a link.
• Every tool that consumes CONTENTS should be modified to canonicalize (respecting installed symlinks) paths in CONTENTS before trying to compare them to user input.

There may be others. Some of these are clearly a lot of work for questionable gain.

[John R. Graham]

What it amounts to is that the /usr merge isn't really complete. It can be argued that the tools aren't ready for the state of the filesystem or that the tree isn't ready. It's enough of a practical and philosophical annoyance to me that I'm regretting choosing the new default profile on my new workstation install, enough so that I'm thinking about writing an inverse of the merge-usr tool in order to switch to a split-usr profile while avoiding a reinstall.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[GameDevFox]

I love learning about Gentoo and Linux systems in general and learned a bunch of extra things from this discussion than I originally anticipated.

I'm heard the Gentoo community was one of the best communities out there and you guys have proved it.

Thanks to everyone to contributed to this thread and any who may post on this thread afterwards.

[GDH-gentoo]

[John R. Graham]

Yeah, well, "They suck, too," isn't that much of a comfort, except maybe to acknowledge that having the package management tools provide sane answers to all reasonable queries in this interim transition state is a non-trivial problem.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[Hu]

I have not seen anything that would lead me to think this is an interim transition state. I think that merged-usr intends to have those symlinks present indefinitely, and that there is no one pushing to convert all packages to explicitly use /usr/bin in their install paths.

[John R. Graham]

I'd argue that the tools are in an interim transition state—or a not transitioned at all yet state—because they don't provide sane output for all sane inputs. I'd argue that the tools modification is—or should be—part of the merged-usr work. On the state of the filesystem, no argument.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.

[Hu]

Yes, we are in a state where the tools are not ready, and hopefully someone will have time to correct that. I was thinking of option 3 ("All packages everywhere should be modified ...") and noting that not only is that not done, but there does not seem to be any entity pushing in that direction, even on a small scale. If all packages were modified to stop relying on these links and just use /usr/bin for everything, then equery would resume working, without any changes to its code. However, nobody is working on that. Considering it would touch thousands of packages, it is a massive project, best suited to an entity with the resources to force through massive changes. The systemd project itself seems ideally suited to that work, since they have a penchant for forcing through massive changes, and they did create this problem by pushing all systemd users to merged-usr.

[Goverp]

[szatox]

[Hu]

I can offer no substantive answers to your questions, and I agree that it seems like churn for the sake of churn. As far as I know, the reason Gentoo (or any other distribution) is even looking at usr-merge is because the systemd project announced that they would no longer support systemd on a non-usr-merge system. Many people use systemd. Those people would then be stuck with the situation that they stop taking all updates, fork systemd and maintain a version that works on non-usr-merge, convince systemd not to remove support for non-usr-merge, or switch their systems to usr-merge.

I've seen vague handwaving about how it makes certain special purpose setups like root-on-read-only-NFS and minimalistic containers easier, but I know of no reason that those could not have done usr-merge in their little corner and left the rest of the world alone.