View previous topic :: View next topic |
Author |
Message |
Chuck379 n00b
Joined: 13 Oct 2024 Posts: 6
|
Posted: Sun Oct 13, 2024 11:26 am Post subject: doas fails to emerge - only when scripted |
|
|
doas fails to emerge when running an installation script that I am writting but it does emerge successfully if do each of the steps in the installation script manually.
This is the installation script:
Code: | # installs dependencies
echo 'app-admin/doas persist' >>/etc/portage/package.use
emerge --ask=n \
app-admin/doas \
app-admin/eclean-kernel \
app-portage/gentoolkit \
net-misc/chrony \
sys-block/io-scheduler-udev-rules \
sys-kernel/gentoo-kernel || exit 1
# configures doas
cat <<EOF >/etc/doas.conf
# https://wiki.gentoo.org/wiki/Doas
permit persist :wheel
permit nopass :wheel as root cmd shutdown
permit nopass :wheel as root cmd reboot
EOF
chown -c root:root /etc/doas.conf |
---
Failed emerge info: https://bpa.st/BYWQ
Emerge pqv: https://bpa.st/XW2A
Build log: https://bpa.st/GZXQ
---
I am completly lost in this, any help would be appreciated |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22640
|
Posted: Sun Oct 13, 2024 3:51 pm Post subject: |
|
|
Welcome to the forums. Per Guidelines item #4, please show us how to reproduce the problem. Are all of these statements correct?- You are running all commands as root, from a clean root shell (via /bin/su - or a log in as root on a tty). You are not using sudo, doas, or similar. You are not letting su retain any part of the user's login environment.
- Running emerge --ask=n app-admin/doas works correctly.
- Running bash shown-script.sh fails.
- You get the same version of doas in both paths.
|
|
Back to top |
|
|
Chuck379 n00b
Joined: 13 Oct 2024 Posts: 6
|
Posted: Sun Oct 13, 2024 4:37 pm Post subject: |
|
|
Thank you for the answering Hu.
- I am running this from a root shell after chrooting into a blank device, untaring the openrc stage3 archive and installing gentoo's base system as per the handbook.
- Running emerge --ask=n app-admin/doas works correctly
- Running bash shown-script.sh fails.
- And I get the same version of doas in both paths.
To give you a bit more context, I have manually installed gentoo's systems successfully more times than I can remember (when I say manually I mean, going through the whole handbook with no automation). During the past few weeks I have been creating these bash scripts to reduce the effort in installing gentoo everytime I want to install a new system on a different computer - I could probably go through other approaches as backing up a base system and use it wherever, but I digress. These scripts go through all the steps of the handbook and my only deviation so far is installing doas which does not successfully do it while scripted but it does work if I manually run the same command at that point of the automation.
I probably had multiple versions of the same scripts that installed doas successfully, but this time it does not work for whatever reason.
To replicate what I am doing is using a live ISO debian based system and install gentoo's through my scripts which I do not expect you to take that effort.
Thank you anyways, any idea for me to try would be welcomed! |
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1243 Location: Richmond Hill, Canada
|
Posted: Sun Oct 13, 2024 5:12 pm Post subject: |
|
|
Chuck379,
I think you may have misunderstood Hu's request.
We totally trust whatever user's report on how they arrived to the situation. However we are not in front of your computer so we need to examine if there are peripheral things that might have cause unexpected thing happen.
In the emerge design logic, the error condition you described cannot happen. Because running from command line vs running inside script should have exact same effect, either both success or both fail. so either there is something we don't see affect emerge or you running into a bug in emerge. however in order for us to determine which is the case we need to see more.
The error you reported in the build log is a C compiler identify missing declaration. Since emerge from each invocation should remove previous result and start from scratch so there is no reason to think the calling to C compiler from a interactive command vs from a batch script will work differently.
So it would be best if you can do Hu's request in one single shell session. And you do it such way that we can (sort of) see the whole sequence of the events.
and the events are, - whoami # To demonstrate the running user.
- emerge --ask=n app-admin/doas
- <however you invoke your script> #So we can see how it failed and with whatever error messages (if any)
|
|
Back to top |
|
|
Chuck379 n00b
Joined: 13 Oct 2024 Posts: 6
|
Posted: Sun Oct 13, 2024 9:08 pm Post subject: |
|
|
Thank you both for spending your time looking at this issue with me.
I tried collecting more information as you stated pingtoo and sorry for the delay preparing this answer.
This time, I booted up an Ubuntu live ISO and executed my script and collected the log messages: https://pastebin.com/UMJ64DQA
As you can see from the logs it failed again installing doas at the last step and before exiting chroot and unmounting the devices I ran whoami and emerge doas:
Code: | $ whoami
root
$ emerge --ask=n app-admin/doas
* IMPORTANT: 20 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
These are the packages that would be merged, in order:
Calculating dependencies... done!
Dependency resolution took 0.58 s (backtrack: 0/20).
[ebuild N ] app-admin/doas-6.8.2::gentoo USE="pam persist" 0 KiB
Total: 1 package (1 new), Size of downloads: 0 KiB
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) app-admin/doas-6.8.2::gentoo
>>> Installing (1 of 1) app-admin/doas-6.8.2::gentoo
>>> Recording app-admin/doas in "world" favorites file...
>>> Completed (1 of 1) app-admin/doas-6.8.2::gentoo
>>> Jobs: 1 of 1 complete Load avg: 0.55, 0.41, 0.48
* Messages for package app-admin/doas-6.8.2:
* The persist/timestamp feature is disabled by default upstream.
* It may not be as secure as on OpenBSD where proper kernel support exists.
* By default, doas will deny all actions.
* You need to create your own custom configuration at /etc/doas.conf.
* See https://wiki.gentoo.org/wiki/Doas for guidance.
* GNU info directory index is up-to-date.
* IMPORTANT: 20 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
|
Which finished successfully emerging doas.
Please let me know if this does not help give more hints to what is happening.
Looking into the logs again I find this portage message from sys-libs/pam:
Code: | * Messages for package sys-libs/pam-1.6.1:
* Some software with pre-loaded PAM libraries might experience
* warnings or failures related to missing symbols and/or versions
* after any update. While unfortunate this is a limit of the
* implementation of PAM and the software, and it requires you to
* restart the software manually after the update.
*
* You can get a list of such software running a command like
* lsof / | grep -E -i 'del.*libpam\.so'
*
* Alternatively, simply reboot your system. |
I reckon doas is using this PAM libs and might be the cause of the failure but being that the case I am not sure why running the command manually works..
Thank you again |
|
Back to top |
|
|
Banana Moderator
Joined: 21 May 2004 Posts: 1725 Location: Germany
|
|
Back to top |
|
|
Chuck379 n00b
Joined: 13 Oct 2024 Posts: 6
|
Posted: Mon Oct 14, 2024 12:07 pm Post subject: |
|
|
Thank you all for your answers.
While this post was active I was in communication with gentoo's doas maintainer: Felix Janda, who helped me immensely understanding the issue.
The problem was caused by the export variable """host""" that existed in the scripted installation while it did not exist while running the command manually.
The exported """host""" variable confused the installation of doas, more specifically runnig the configure step.
So, renaming the exported variable to something else solved the issue.
Thank you again |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22640
|
Posted: Tue Oct 15, 2024 12:09 am Post subject: |
|
|
More generally, you should be careful about exporting any variable with a simple name, as those pass through to underlying build systems. Over the years, I have repeatedly seen users who had the idea to define SYSTEM="..." in make.conf, and then were surprised when this broke the OpenSSL build. OpenSSL treats $SYSTEM as having specific meaning, and setting it to unsupported values causes problems.
Why are you using export on host at all? |
|
Back to top |
|
|
Chuck379 n00b
Joined: 13 Oct 2024 Posts: 6
|
Posted: Tue Oct 15, 2024 8:10 am Post subject: |
|
|
Hey Hu, thank you for your advice!
I was wrongly exporting a variable named host for ease of access to the machine's hostname even though uname -n would be enough.
This export was reused elsewhere in my own bash implementations.
Now own, I will be more aware of these "reserved" names. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22640
|
Posted: Tue Oct 15, 2024 3:24 pm Post subject: |
|
|
I think you misunderstood my question. From what I read of your scripts, you're chaining everything together with source, so you do not need to export anything, even for variables passed among your shell functions. You only need export for variables that need to be visible in the environment of child processes. Are there places where you want to run a child process, and it needs access to the content of one of these variables? |
|
Back to top |
|
|
Chuck379 n00b
Joined: 13 Oct 2024 Posts: 6
|
Posted: Tue Oct 15, 2024 7:19 pm Post subject: |
|
|
I see now what you are saying, thank you again for going into detail explaining things to me.
I am ashamed to say that I am a big noob in scripting and linux related topics even though one cannot count by their firngers the amount of years I have as experience in software development...
Answering to your question, no - there are no child processes where these exported variables will be used.
I can now understand that using source to execute different scripts do not make use of exports.
We live and we learn!
Thank you again |
|
Back to top |
|
|
|