View previous topic :: View next topic |
Author |
Message |
GameDevFox n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 05 Jul 2024 Posts: 3
|
Posted: Fri Jul 05, 2024 10:49 pm Post subject: Help with finding the source code for /usr/bin/init |
|
|
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 |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
szatox Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
Joined: 27 Aug 2013 Posts: 3329
|
Posted: Fri Jul 05, 2024 10:54 pm Post subject: |
|
|
Hint:
Code: | # which init
/sbin/init
|
_________________ Make Computing Fun Again |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Hu Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
Joined: 06 Mar 2007 Posts: 22375
|
Posted: Fri Jul 05, 2024 11:00 pm Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
jburns Veteran
![Veteran Veteran](/images/ranks/rank_rect_5_vet.gif)
Joined: 18 Jan 2007 Posts: 1215 Location: Massachusetts USA
|
Posted: Sat Jul 06, 2024 3:44 am Post subject: |
|
|
Code: | emerge --fetchonly /usr/bin/init | would get the source code for the init program. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
GameDevFox n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 05 Jul 2024 Posts: 3
|
Posted: Sat Jul 06, 2024 4:03 am Post subject: |
|
|
szatox wrote: | Hint:
Code: | # which init
/sbin/init
|
|
Thanks! That helped me figure out what my problem was. When I typed in `which init` I got `/usr/bin/init` but there's also an `/sbin/init` on my system.
When I tried `equery belongs /sbin/init` it returned `sys-apps/sysvinit-3.09` which is what I was looking for.
Side question: if in the future, I wanted to find the source code for binaries in the stage3, where would I find that? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
szatox Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
Joined: 27 Aug 2013 Posts: 3329
|
Posted: Sat Jul 06, 2024 9:24 am Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
pietinger Moderator
![Moderator Moderator](/images/ranks/rank-mod.gif)
Joined: 17 Oct 2006 Posts: 4842 Location: Bavaria
|
Posted: Sat Jul 06, 2024 10:11 am Post subject: |
|
|
szatox wrote: | /usr/bin/ doesn't look like a correct location for init. Root-only binaries are in /sbin, and /usr/sbin; |
Since the switch from split-usr to merged-usr, /sbin is a link to /usr/bin and /usr/sbin is also only a link to /usr/bin ... init is therefore really in /usr/bin. _________________ https://wiki.gentoo.org/wiki/User:Pietinger |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
szatox Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
Joined: 27 Aug 2013 Posts: 3329
|
Posted: Sat Jul 06, 2024 10:52 am Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Hu Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
Joined: 06 Mar 2007 Posts: 22375
|
Posted: Sat Jul 06, 2024 11:56 am Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
John R. Graham Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
![](images/avatars/1323583785534df64897db0.jpg)
Joined: 08 Mar 2005 Posts: 10644 Location: Somewhere over Atlanta, Georgia
|
Posted: Sat Jul 06, 2024 5:15 pm Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
GameDevFox n00b
![n00b n00b](/images/ranks/rank_rect_0.gif)
Joined: 05 Jul 2024 Posts: 3
|
Posted: Sat Jul 06, 2024 9:13 pm Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
GDH-gentoo Veteran
![Veteran Veteran](/images/ranks/rank_rect_5_vet.gif)
![](images/avatars/4552800915d460a483ae8d.jpg)
Joined: 20 Jul 2019 Posts: 1616 Location: South America
|
Posted: Sun Jul 07, 2024 2:52 pm Post subject: |
|
|
John R. Graham wrote: | What it amounts to is that the /usr merge isn't really complete. |
To be fair, the problem of filesystem layout vs file locations that the package manager records is not unique to Gentoo. Debian has exactly the same problem (in their rolling release-like unstable "sid", I believe); they had a non-merged /usr filesystem layout up to a certain version, are moving (unconditionally in their case because systemd; we still have OpenRC-based, non-merged /usr 23.0 profiles) to a merged /usr layout for the next one, and also opted for a merge-usr-like approach, i. e. moving things around without updating the package manager's knowledge. After a very long and heated debate between the merged /usr proponents and their package manager maintainers. _________________
NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer ![Smile :)](images/smiles/icon_smile.gif) |
Ionen wrote: | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though ![Smile :)](images/smiles/icon_smile.gif) |
|
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
John R. Graham Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
![](images/avatars/1323583785534df64897db0.jpg)
Joined: 08 Mar 2005 Posts: 10644 Location: Somewhere over Atlanta, Georgia
|
Posted: Sun Jul 07, 2024 6:25 pm Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Hu Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
Joined: 06 Mar 2007 Posts: 22375
|
Posted: Sun Jul 07, 2024 6:40 pm Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
John R. Graham Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
![](images/avatars/1323583785534df64897db0.jpg)
Joined: 08 Mar 2005 Posts: 10644 Location: Somewhere over Atlanta, Georgia
|
Posted: Sun Jul 07, 2024 7:05 pm Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Hu Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
Joined: 06 Mar 2007 Posts: 22375
|
Posted: Mon Jul 08, 2024 2:46 am Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Goverp Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
![](images/avatars/152613747847c6fd276c31a.jpg)
Joined: 07 Mar 2007 Posts: 2110
|
Posted: Mon Jul 08, 2024 8:07 am Post subject: |
|
|
Hu wrote: | 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. |
IMHO nothing affected by systemd is ever in anything other than "an interim transition state". ![Wink ;-)](images/smiles/icon_wink.gif) _________________ Greybeard |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
szatox Advocate
![Advocate Advocate](/images/ranks/rank-G-1-advocate.gif)
Joined: 27 Aug 2013 Posts: 3329
|
Posted: Mon Jul 08, 2024 8:41 am Post subject: |
|
|
Quote: | 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. | Well, maybe there was no reason to make this change in the first place?
Does usr-merge actually solve any problem? No? So why _should_ the whole world just obey someone's "because I said so" and fix their stuff that isn't broken?
I get the argument that /usr was introduced as a stop-gap measure when disk sizes couldn't keep up with software, and now the secondary hierarchy is not needed anymore. Great, the correct solution is to ditch /usr instead of making it the new root.
Still, it does not explain why sbin _should_ be merged with bin. Not necessarily a big deal, but it does make some sense to separate system binaries from user binaries.... If nothing else, it makes bash-completion's life easier. And I'd rather not give up on having /opt/bin and ~/bin in PATH, so there's no simplifying it to a single location. What are the benefits of dropping sbin and are they worth the effort? _________________ Make Computing Fun Again |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
Hu Administrator
![Administrator Administrator](/images/ranks/rank-admin.gif)
Joined: 06 Mar 2007 Posts: 22375
|
Posted: Mon Jul 08, 2024 12:12 pm Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
|