Bug 142707 - "id: command not found" errors in repair shell
Summary: "id: command not found" errors in repair shell
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: setup
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
URL:
Whiteboard:
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
Clone Of:
Environment:
Last Closed: 2005-04-15 20:54:44 UTC
Type: ---
Embargoed:


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