First console command completes but ...

Bernard Leak bernard at brenda-arkle.demon.co.uk
Thu Jun 23 05:28:41 PDT 2005


Dear All,
                apologies if I'm doing something completely stupid.
(or duplicating an existing question - though I don't think
I am).

I've followed LFS 6.0 very, very nearly 100%: see later for
differences (a list complete in intention: certainly no other
differences looked important for me to take note of them...)
None of the changes seems to explain what I see.

    When I reboot into the LFS bare-bone system I get a
thoroughly normal-looking boot (I have set the boot option
for  "nosplash" so I get lots of gory details).  I emerge into
a login prompt, and can log in as root.  So far so good.
Now, the console accepts my first command, spits out the
output as requested, and then seems to hang without
actually returning control to the calling shell.  What I type is
echoed, and 'return' appears as a newline, but I get no other
response.  I can force a reboot with Ctrl-Alt-Del, but without
another machine to play with I can't do much else.

Looking over /var/log/sys.log from my other installation,
I get no warnings or errors (apart from an irrelevant
minor whinge about an NTFS partition).
I always get the useless (and, alas, familiar) message in /var/log/sys.log :
*"No module symbols loaded* - kernel modules not enabled"
Ho-hum, klogd being unhelpful as usual.

/dev/vcs1 and /dev/vcsa1 bounce in and out of existence
as udev gets going, but there are no notable surprises
(both end up created and remaining until I shut down).

Does anyone have anything to offer here?

My host (and target!) machine is new-ish and boring
   i686-pc-linux   (actually P4 on an Intel 845PE motherboard)
  
Host build tools (for building the bootstrap tools):
   kernel 2.6.11.6-mykernel-01
       (very, very close to unmodified, but I have added
        some private FS modules of my own).
   binutils-2.15.90.0.3
   gcc-3.4.3
   glibc-2.3.3

Not quite following Book:
       binutils 2.15 (which I think is *later* than the 2.15.91.0.2
              specified in the Book)
       glibc 2.3.5 rather than the CVS snapshot of 2.3.4
            (not out, I think, when the Book was in preparation,
             and of course includes the changes which prevented
             2.3.4 from working)
       man 1.5o2 rather than 1.5o
             (1.5o in fact was hard to track down: the only obvious
              difference was that at least one patch had already
              been (partially) taken, but the ChangeLog in the
              tarball doesn't even record the change of version)

I'm using almost pure udev; /dev/console, /dev/null and /dev/tty0
are statically set up initially.  This doesn't seem to be a problem.

Finally, I left my ethernet card unconfigured (waiting to use
DHCP following BLFS).  This is unimportant at present,
though it produces an "eth0 not configured" warning
while running 'network start'.

Not deviations from Book, really, but worth noting:
I already have a working grub installation, so I simply added a new
entry to /boot/grub/menu.lst.  /boot is not LFS-specific: I use the
same partition for my current system and for LFS.

I've built my kernel both with "mostly modules" and "modules only
where necessary".
This makes no difference to the relevant behaviour.
However, the version without modules doesn't give me the special
vga=788 requested (just 640x480, ugh)
Most odd - I could understand a missing entry in modules.conf,
but that would make the moduled version fail, and the (nearly)
solidary and monolithic version succeed!  I dare say I've got some
operation fail *because* a module can't be loaded, even though
the functionality is in the kernel anyway.  But this is unimportant
anyway.

Complete build scripts and logs are available for the LFS build.
All commands send output (standard and error) to the logs, except
when output is being copied / appended to some other file anyway.


                                                                         
                                      Bernard Leak.




More information about the lfs-dev mailing list