sh: argument expected

[saper]

Please identify some basic details to help process the report

"sh: argument expected" appears pretty often

A. Provide Hardware Details

1. What board are you using (see list of boards here)?

2. Does your computer have a dGPU or is it iGPU-only?

• dGPU
• iGPU-only

Thinkpad X230

3. Who installed Heads on this computer?

• Insurgo
• Nitrokey
• Purism
• Other provider
• Self-installed

Got this box from @tlaurion 💯

4. What PGP key is being used?

• Librem Key
• Nitrokey Pro 2
• Nitrokey Storage
• Yubikey
• Other

5. Are you using the PGP key to provide HOTP verification?

• Yes
• No
• I don't know

B. Identify how the board was flashed

1. Is this problem related to updating heads or flashing it for the first time?

• First-time flash
• Updating heads

2. If the problem is related to an update, how did you attempt to apply the update?

• Using the Heads GUI
• Flashrom via the Recovery Shell
• External flashing

3. How was Heads initially flashed

• External flashing
• Internal-only / 1vyrain
• Don't know

4. Was the board flashed with a maximized or non-maximized/legacy rom?

• Maximized
• Non-maximized / legacy
• I don't know

5. If Heads was externally flashed, was IFD unlocked?

• Yes
• No
• Don't know

C. Identify the rom related to this bug report

1. Did you download or build the rom at issue in this bug report?

• I downloaded it
• I built it

2. If you downloaded your rom, where did you get it from?

• Heads CircleCi
• Purism
• Nitrokey
• Somewhere else (please identify)

pre-installed, FW_VER says CBET4000 Heads-v0.2.0-1359-g411ca09

Please provide the release number or otherwise identify the rom downloaded

3. If you built your rom, which repository:branch did you use?

• Heads:Master
• Other (please identify)

4. What version of coreboot did you use in building?

• 4.8.1 (current default in heads:master)
• 4.13
• 4.14
• 4.15
• Other (please specify)
• I don't know

5. In building the rom where did you get the blobs?

• No blobs required
• Provided by the company that installed Heads on the device
• Extracted from a backup rom taken from this device
• Extracted from another backup rom taken from another device (please identify the board model)
• Extracted from the online bios using the automated tools provided in Heads
• I don't know

Please describe the problem

Describe the bug

New user, I have run factory reset and during the operation at a very late stage I got "sh: argument expected" displayed.
After this, factory reset completed successfully.

Now it appears in gui-init before first menu pops up:

******* Normal boot: /bin/gui-init
Unable to localte /boot files on any mounted disk
sh: argument expected

OEM factory reset complained about missing LUKS partition (because there isn't any) but otherwise all seemed to proceed well.

To Reproduce
Steps to reproduce the behavior:

Just boot the machine

Expected behavior

This error message should not appear

I am sorry for the unhelpful report, but although I consider myself a pretty competent shell programmer, I can't pinpoint the location of the possible error :(

[tlaurion]

@saper thanks for the report (and I'm happy you use the goodie given at FOSDEM :) )

No consequence but not beautiful.

gui-init is passing env variables before sourcing files as opposed to other scripts. I guess this is the source of it

Will check if moving those resolves the issue: https://github.com/osresearch/heads/blob/9676c794a2520d7cff22796b8db7f8ee16d7a6c8/initrd/bin/gui-init#L4

And following lines

[saper]

Wouldn't just adding quotes help? BOARD_NAME="${CONFIG_BOARD_NAME:=${CONFIG_BOARD}}" ?

(not sure if this is the problem though)

(in recovery shell, I have both of those variables set)

[saper]

I'm happy you use the goodie given at FOSDEM :) )

💯 This is the best conference swag ever 💯

[tlaurion]

I edited my answer, away from keyboard, but my point is that sourcing files should be done first prior of trying to use declared (maybe undeclared) variables at that point.

gui-init is called from init, which calls only cbfs-init (basically) prior of those lines.

So this is just hypothesis, not source of truth, and that error has been a tolerated annoyance until someone (you) bothered to raise an issue about it.

Will check into it tomorrow, first time I really look into it in goal of fixing it.

[saper]

@tlaurion btw. unrelated - not sure if this is interesting to you, but installing Qubes 4.1.0 from the "media-scanned" /dev/sda1 demo partition always fails, because anaconda demands that /dev/sda1 needs to be unmounted prior to install, even if I want to create /dev/sda2 /boot and /dev/sda3 root partition separately. One will always get "Error checking storage configuration" anaconda error. No matter how advanced partition editor will be used. Will not take it to Qubes or Red Hat bug tracker, but maybe something can be invented for the demo purposes ...

[tlaurion]

@saper using unpartitioned space is not working? Took for granted it would

[saper]

unfortunately, not. even partitioned everything by hand from the recovery shelll hoping I can tell "just use those existing partitions, please"

[tlaurion]

@marmarek any reason anaconda doesn't like iso mounted from /dev/sda1 (you can try on latest heads master) 'media-scan /dev/sda1' as reported under #1316 (comment) above for 4.1? (Unrelated to this issue per se). But would be a totally workable way to have coreboot flashing booth distribute QubesOS and other ISOs (and livecd) pushed forward while giving recovery option for Heads users. Unfortunately it doesn't seem to work as expected from anaconda perspective.

[marmarek]

I guess it wants to unmount all the partitions before modifying partition table (even if not really touching this particular partition). I can try later such setup.

[saper]

Something something findActiveDevicesOnActionDisks bla bla bla, maybe

[tlaurion]

@saper

"sh: argument expected" appears pretty often

Fixed under #1317 (which main PR is about adding debugging capabilities) where fd6daeb fixes the culprit.

Debugging things like these will be much more easier in the future.