Bug 142707 - "id: command not found" errors in repair shell
"id: command not found" errors in repair shell
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: setup (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
:
Depends On:
Blocks: FC4Target
  Show dependency treegraph
 
Reported: 2004-12-13 01:15 EST by Dmitry Bolkhovityanov
Modified: 2014-03-16 22:51 EDT (History)
1 user (show)

See Also:
Fixed In Version: 2.5.41-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-15 16:54:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dmitry Bolkhovityanov 2004-12-13 01:15:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1)
Gecko/20021003

Description of problem:
If the system was for some reason shut down uncleanly, and filesystem
check was requested upon next boot, and if fsck requires manual check,
the repair shell is started.

But upon this a number of errors are reported by bash ("screenshot"
follows):

---- CUT ----
*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
*** Warning -- SELinux is active
*** Disabling security enforcement for system recovery.
*** Run 'setenforce 1' to reenable.
Give root password for maintenance
(or type Control-D to continue): <<the-root-password-is-typed>>
bash: id: command not found
bash: id: command not found
bash: id: command not found
bash: [: too many arguments
bash: dircolors: command not found
bash: id: command not found
bash: [: =: unary operator expected
(Repair filesystem) 1 # _
---- CUT ----

This is definitely because of /etc/bashrc blindly assuming that
/usr/bin is in $PATH -- it refers to just `id`.  The same glitch is
present in /etc/profile.

(I'm not sure on which package the bugreport should be filed -- while
above files belong to setup-*.rpm, they are used by bash.  And,
"dircolors" error is caused by /etc/profile.d/colorls.sh, belonging to
coreutils-*.rpm.)

This seem to be related to bug #78029, which is marked as fixed (but
is obviously not completely fixed).


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
A quick test can be performed with a command "PATH=/bin bash -l"

Actual Results:  Lots of errors

Expected Results:  Just a prompt should appear

Additional info:
Comment 1 Dmitry Bolkhovityanov 2004-12-13 05:25:35 EST
Just thoughts: in fact, "the right thing" would be to move "id" from /usr/bin/
to /bin/ (since it is used by startup files of */bin/*bash, which should be
available even when no /usr exists), and make appropriate symlink
/usr/bin/id->../../bin/id.  But I suspect that will open its own can of worms...
Comment 2 Bill Nottingham 2005-04-15 16:54:44 EDT
Fixed in 2.5.41-1.

Note You need to log in before you can comment on or make changes to this bug.