Bug 142707 - "id: command not found" errors in repair shell
Summary: "id: command not found" errors in repair shell
Alias: None
Product: Fedora
Classification: Fedora
Component: setup   
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
Blocks: FC4Target
TreeView+ depends on / blocked
Reported: 2004-12-13 06:15 UTC by Dmitry Bolkhovityanov
Modified: 2014-03-17 02:51 UTC (History)
1 user (show)

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

Attachments (Terms of Use)

Description Dmitry Bolkhovityanov 2004-12-13 06:15:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1)

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"

---- 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

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:

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 10:25:35 UTC
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 20:54:44 UTC
Fixed in 2.5.41-1.

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