No ttys, no login shell

Ken Moffat ken at linuxfromscratch.org
Thu Oct 25 16:51:28 PDT 2007


On Thu, Oct 25, 2007 at 10:35:14PM +0000, paul.rogers at juno.com wrote:
> 
> > If you are using an earlier book, the correct fix may be different.
> >I think we used to create /mnt/lfs/dev/null as a node before
> >populating /dev for chroot (so, if you are doing that, ensure
> >nothing is mounted on /mnt/lfs/dev when you create the missing
> >node(s) there).
> 
> Ken, I'm still back on 6.1, which ain't broke, as far as my usage.  
> When I built it I did deviate from the book as far as putting a few
> essential devices in the root's /dev mount point, so if something
> wierd happened I could hopefully get up.  Nothing ever has, udev's
> been fine, but I just felt better knowing it's there.  I remember 
> wondering if that mightn't be a good failsafe for the book.
> 
 I defer to the udev experts - copying the static devices in recent
versions of udev seems to work fine.  Now, if the root filesystem
got totally hosed, minimal static devices might help a little but
there would still be a vast amount to do to recover from backups,
and the root system would almost certainly be inadequate for that.
At one time, a static shell had its proponents.  But thinkos like
'rm -rf' can remove all of /bin in the blink of an eye.  So, backups
and a recovery strategy are probably a better idea.

 The other case where I remember problems with devices was
incompatible udev changes (e.g. a kernel upgrade needed a newer
udev).  That sort of change seems to get stamped on nowadays, so I
don't think it is a current problem.

 People used to care a lot more about failsafe behaviour (e.g. I can
remember somebody posting a quite involved script to ensure
everything necessary was there before giving his users their
graphical login, with fallbacks to a console login).  For commercial
use, that isn't a bad idea (probably second on the list of important
things after monitoring the vulnerability lists).  But most LFS/BLFS
users are the only, or the main, user on a home system.

 Adding unnecessary complexity, particularly where hardly anybody
will use/test it, is not useful for any of the books.  For an
individual system, feel free to take a different view.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-support mailing list