Ticket #808 (closed defect: worksforme)

Opened 10 years ago

Last modified 9 years ago

Nonexistent $HOME breaks stuff

Reported by: cwixon@… Owned by: willie_chen
Priority: high Milestone:
Component: sysinit Version: 2007.2
Severity: normal Keywords:
Cc: buglog@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:


On my Neo1973 I have a MicroSD partition mounted at /home (which is analogous to
a pretty typical setup on a desktop Linux system), but the mmc device is brought
up AFTER some of the init scripts expect /home/root -- which is the default path
to the root user's HOME directory -- to already exist.

As a result, anything spawned by init or the gui finds that HOME=/


(1) Don't hardcode HOME=/home/root

I'm actually not entirely clear on the sequence of events here.

It's currently hardcoded in /etc/X11/Xinit -- oddly, as that script currently
stands, HOME is first set to /home/root, and then if that directory doesn't
exist and /root does, then HOME is set instead to /root. But if /home/root does
not exist and /root does not exist, the value of HOME is not changed. (It's not
clear to me whether Xinit is even run, though -- other variables set there don't
show up later.)

Also see /etc/init.d/mountall.sh -- which does sort of a manual version of the
getent | cut and attempts to make the root user's home if it doesn't exist --
though it does not use the HOME variable. It does this _after_ the mount -a but
for whatever reason, HOME still gets set to / on my device.

In the 2007.2 rootfs, /home/root does not exist at boot, and /root does not
exist at all by default, so HOME ends up as / and various configuration files
get stored there. It works, but it's not standard to put files there.

It would be preferable to use something like:

export HOME=getent passwd ${USER} | cut -f6 -d:

. . . but getent isn't available in the default rootfs and isn't in busybox.

And I would submit that Xinit isn't the right place for it. Perhaps something
in /etc/init.d that runs pretty early in the process would be a better candidate.

(2) As suggested by the Filesystem Hierarchy Standard, include a /root directory
in the rootfs images and use that as the default home directory for the root user.


This should go in the default rootfs /etc/passwd file so that it gets picked up
by the getent, above.

(3) Don't have the user run as root by default!

Yes, this is a known issue and I'm sure it will be rectified at some point, but
I include it here for completeness. Running this way is the root (ahem) of all

Change History

comment:1 Changed 10 years ago by cwixon@…

Curious behavior.

I had occasion to flash a new rootfs, and in so doing, I left /home on the
default filesystem.

Even when /home/root and /root both exist, I still get HOME=/ in the login shell
and not the value it's set to in /etc/passwd.

I can fix this by specifically extracting the value from /etc/passwd in a script
sourced by /etc/profile (e.g. in my case, /etc/profile.d/userprofile.sh):

export HOME="`cat /etc/passwd | grep $USER | awk

This is a successful workaround, but shouldn't this variable be set
automatically by the login process (/bin/tinylogin) based on the contents of

Finally, as a followup to my initial comment, section (1), I don't believe the
hardcoded value in Xinit is ever being set. The remaining comments stand.

comment:2 Changed 10 years ago by cwixon@…

I just checked on a brand new from-scratch image I built (2007-11-06), and $HOME
still isn't set correctly unless I set it myself in (e.g.)

Contrary to my initial post, I don't think this has anything to do with when
mounted partitions are brought up.

On a freshly flashed, freshly booted Neo, I open the terminal, type 'env', and
see that HOME=/

comment:3 Changed 9 years ago by nod_huang@…

  • Owner changed from buglog@… to michael@…

comment:4 Changed 9 years ago by john_lee@…

  • Owner changed from michael@… to willie_chen@…

reassign to willie

comment:5 Changed 9 years ago by roh

  • Owner changed from willie_chen@… to willie_chen

comment:6 Changed 9 years ago by john_lee

  • Status changed from new to closed
  • HasPatchForReview unset
  • Resolution set to worksforme

should be okay on the recent images.

Note: See TracTickets for help on using tickets.