Source
r/bash•
Public-Disorder

Command fails in script but copy-paste into terminal works fine.

SOLVED: it seems that my script broke due to switching to the lts kernel, which takes longer to recognize the partition name. Adding a sleep timer for 30s seems to have solved the issue. Not really a bash specific problem but you guys were super helpful. Thanks!

This is driving me absolutely insane, especially since it used to work and now it refuses to no matter what I do.

The command in question is:

echo -n "$CRYPTPASS" | cryptsetup luksFormat -d - --align-payload=8192 -s 256 -c aes-xts-plain64 /dev/disk/by-partlabel/cryptsystem

It fails with the error: Device /dev/disk/by-partlabel/cryptsystem doesn't exist or access denied.

The partition in question definitely exists with the defined label. I can literally copy-paste the command into the terminal right after getting the error from the script and it works fine.

I'm about ready to throw my PC out the window at this point so I'd really appreciate any help you can offer.

Posted Jan 22, 2020, 6:19 AM UTC · edited

1213
Xenther•

What are the perms of the device? Is the script being executed by cron or something else that has different ID or GID?

3
Public-DisorderOP•

The script is run manually as root, so permissions shouldn't be an issue. It's not mounted and has been secure wiped and had a new GPT table and partitions created immediately prior to this command.

It's a live system with an installation script, running in VirtualBox.

The part that gets me is if I exit the script and immediately run that exact command again, it works fine. I can't figure out how tf that is possible.

2
pnht•

Oh! It is possible that the "mapped" names (things under /dev/disk and /dev/mapper) don't exist when the script runs. If I remember correctly, those are all created by udev, not instantly upon seeing the disk.

Just add a sleep 30 to your script and see if that fixes it.

If so, you can then use something more elegant like:

#!/bin/bash

if [[ ! -e /dev/disk/by-partlabel/cryptsystem ]]
then
  x=$(( x + 1 ))
  sleep 1
  if [[ $x -gt 30 ]]
  then
    echo "/dev/disk/by-partlabel/cryptsystem never became available"
    exit 1
  fi
fi
echo -n "$CRYPTPASS" | cryptsetup luksFormat -d - --align-payload=8192 -s 256 -c aes-xts-plain64 /dev/disk/by-partlabel/cryptsystem
2
Public-DisorderOP•

I suspected something like this and tried some smaller sleep times in between commands I will try the 30s wait and post the result.

2
Public-DisorderOP•

Thank you! This seems to work and allows me to continue using the lts kernel, which is something I require but switching to it seems to be the reason why my script stopped working in the first place.

I guess the reason it worked for me previously is because udev recognizes the change a lot faster with the 5.x kernel vs 4.19 lts.

2
pnht•

Happy to help :-)

Glad you got it fixed... now on to your next bug> Squish them as fast as you can, but know when you need sleep more than fixing another bug (as it's 2 AM here and I have to get up at 7 ....

1
oh5nxo•

if, or until loop ? :)

2
pnht•

Are you running the script in the same terminal as cutting and pasting works in?

  • when root gets "access denied", suspect apparmor or selinux
    • run sudo setenforce 0 to temporarily disable selinux
    • run sudo systemctl stop apparmor
    • Now try the script again

next, try:

  • In your script, add 2 lines before the line that fails:
id
ls -ld /dev/disk/by-partlabel/cryptsystem

tell us what that shows

1
Public-DisorderOP•

Same terminal window yes. This particular script is called by the initial menu script, so it is running in a subshell I believe?

This is Arch linux live environment so there is no selinux or app armor. I have verified that /dev/disk/by-partlabel/cryptsystem exists from the terminal window, but I will add those lines to the script and see what the output is from there. One moment.

2
Public-DisorderOP•

Okay so id confirms that I am running as root, and ls confirms that there is a softlink pointing to /dev/sda3 which is correct.

Interestingly enough it works now, since I rebuilt the live environment with the latest kernel, instead of 4.19 lts. I'm going to try what another user suggested and add a 30s wait on the lts build. Perhaps udev takes longer to show changes on the lts kernel?

2
pnht•

Yeah, I hate trying to fix something that is only happening "sometimes".

1
Public-DisorderOP•

Same. That's why I'm so frustrated at this point, I've had a bunch of those problems with this script. This is the last and most persistent one but using the latest kernel isn't a solution, since it has issues with btrfs (found that out with one of the other intermittent problems).

2