doas fails to emerge - only when scripted

[Chuck379]

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:

[Hu]

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.

[Chuck379]

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!

[pingtoo]

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,

1. whoami # To demonstrate the running user.
   
2. emerge --ask=n app-admin/doas
   
3. <however you invoke your script> #So we can see how it failed and with whatever error messages (if any)

[Chuck379]

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:

[Banana]

[Chuck379]

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

[Hu]

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?

[Chuck379]

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.

[Hu]

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?

[Chuck379]

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