Having some trouble setting up a serial console to boot a
dual boot system running Win98SE/Slackware 10.2. I am using
minicom as a terminal emulator linked to ttyS0 on another
system attached to the booting system through a null modem cable.

Host (or booting) system:

lilo.conf looks like this
inittab:

Remote:

minicom: all flow control off, modem init string set to ~^M~, all other
modem strings removed.

To boot the host from the remote, I start minicom and switch to another virtual terminal
such as tty2 and issue a wake-on-lan to start. Switching back to minicom (tty1) I wait
for the boot messages. The only thing that appears on the minicom screen is

There is no selection menu: it simply boots the default. However, I can
make a selection sitting at the host instead of the serial console.

Additional problems:

Once booted into Linux:

1. Cannot reboot or shutdown host machine (CTRL-ALT-DEL and shutdown -h now do not work)
   
2. dmesg does not contain bootup messages after NIC setup
   
3. dmesg contains the following entries never before occurring
   Adding Swap: 811272k swap-space (priority -1)
   ide0(3,3):Removing [4 78196 0x0 SD]..done
   ide0(3,3):Removing [46 78193 0x0 SD]..done
   ide0(3,3):Removing [46 78192 0x0 SD]..done
   ide0(3,3):Removing [46 78191 0x0 SD]..done
   ide0(3,3):Removing [46 78189 0x0 SD]..done
   ide0(3,3):There were 5 uncompleted unlinks/truncates. Completed
   
4. debug has odd error messages:
   Jun 6 09:26:36 chipper login[834]: invalid password for `UNKNOWN' on `ttyS0'
   Jun 6 09:26:48 chipper last message repeated 4 times
   Jun 6 09:26:48 chipper login[834]: REPEATED login failures on `ttyS0'
   Jun 6 09:27:42 chipper login[830]: ROOT LOGIN on `tty1'
   
5. Since I can't boot Linux, there is no login prompt presented.

I am very new to this and could use a little help. Any suggestions?

If you wish, I will give you what help I can. But there are a few things you should know going in. IIRC I tried to control LILO on a RH7.0 or RH8.0 system via a serial line several years ago and I was never able to get it to work satisfactorilly. What I finally concluded (rightly or wrongly) was that in causing LILO to produce a GUI menu on the monitor at boot time, RH had modified LILO in some way that was interferring with what I was trying to do. The fact that you are using Slackware gives me some hope you won't have that problem. Beyond that, I have one system I have setup where I can log into via a serial line, using getty. I have never set the kernel to send messages to serial, but I did assist another LQ member in doing so for debug purposes a little while back. So I don't know how far I can help you , but if you are willing to proceed ...

Traditionally (as I understand it), at boot LILO would print the word LILO and wait. You could cause it to produce a menu by hitting Control, Shift, or Alt. Or if promt was included in lilo.conf (as you have done) the menu would be presented w/o needing to press a key. The version of RH I was using had been modified instead to present a GUI at boot time. Just so I know what we are dealing with here, can you tell me what your Slackware system presents on the monitor at boot time?

Assuming you have an unmodified (unbutchered!) LILO, here is part of what the lilo.conf manpage says about the serial command:

So for a stock version of LILO, I beleive putting a break condition on the line prior to the timeout will bring up the menu. Minicom is supposed to be able to do this with ctrl-A followed by F. If you can't get this working, have you considered making a different image the default using the LILO default command? I am guessing MS Windows won't be too useful to you from a terminal.

At best, that first "console=" is unnecesarry. At worst it might be causing problems. Same for your other Linux image.

As I read agetty's man page, that should be.

agetty is reporting login attempts, presumably from garbage. This may because you called it incorrectly, as noted above. (Edit: the last line is logging your login as root from the attached keyboard/monitor.)

I haven't addressed everything, but let's see how far this gets you.

Thank you for the response. This seems to be a rather unique hardware
setup for an everyday user and there seems to be a paucity of good information
about the serial terminal setup. Remember, I said good information; there
is a ton of what I consider mostly drivel in many forums and The Serial
Console HOWTO is just like every MAN page I have ever read; short on examples
and lacking necessary information.

After writing my initial blurb I did some experimenting. As indicated previously, I
get this prompt on my minicom screen when I boot the host machine:

The "Loading Windows98SE" actuall appears only after 5 seconds which is what is set
in the countdown timer. I find that I can type another kernel "Label" at the prompt
and will boot whatever OS it represents, such as:

I just don't receive a selection menu as I do when I am sitting at the regular console
(tty0 or actually tty1). Unfortunately Alt-Z F does not bring up a selection GUI as you
and others have hinted. I'll have to read further on making a different image; not sure
what that would do. I seem to recall something about pressing TAB to
bring up a list, but I'm not sure what minicom command would do that.

The other problems mentioned seemed to be caused by 'agetty' running on the remote machine.
I had uncommented the serial line "s1" in the remote's inittab thinking that I could
use a serial console on either machine. Turns out the getty running on the remote console
interferred with a number of things on the host and the remote. Recommenting that inittab
line on the remote cured everything except the ide errors which appear to be something else
altogether.

As it turns out, some of the documentation and comments I ran across do indicate that some
dmesg information will not appear on the regular console (tty0/tty1) if you setup the
serial console as the primary (which is what append="console=tty0 console=ttyS0,9600n8"
apparently does). I haven't tested it, but it is apparently necessary to include the tty0
console, otherwise no boot up messages will appear on the regular console.

Nevertheless, once I had removed the getty from the remote, I could see all the bootup
messages and get a login while connected with minicom. It also works with Hyperterminal in
Windows.

It is interesting to note that you mentioned trying to use LILO on a Redhat 7.0 or 8.0
system and never getting the serial terminal to work properly. According to an article on
LILO vs. GRUB, Redhat ceased using LILO as the default boot manager in favor of GRUB with
the advent of version 7.2. You stated:

I have seen several graphics depicting a GUI screen using GRUB on a serial terminal, but I have
yet to find something similar when LILO is employed. I would like to hear more on how you
produced the GUI selection screen using LILO if in fact you did.

I would simply remove the 'timeout = 50'; I can't remember the details of the timing, but you are either telling lilo to select 'windows' after 0.05s, 0.5s, or 5s. At any rate, it's a short timeout and the default is windows (the first bootable entry in lilo.conf).

When windos boots, don't expect any more communications on the serial port. If Linux is booted, you should expect to be able to use the remote serial device as your console.

Not quite sure what pinniped is talking about although it seems you
are providing a way to stall default booting of Windows after 5 seconds.

This is not really a problem. I can halt the default boot by simply
entering a single character at the boot prompt. I then take my time
entering a recognizable kernel "label" to boot whatever system I want.

The true problem, if you can call it that, is the inability to obtain
some sort of GUI, similar to the one seen on the host console (tty0/tty1),
which allows scrolling to a selection. This does not happen with CTRL-A F,
as suggested. This morning I quickly tried "TAB" which gave me:

a simple list which I suppose is a reminder of which labels will boot
specific systems. However, this is not a GUI selection menu and I still
have to enter the proper label at the boot prompt and press enter to
actually boot.

As previously mentioned, GRUB can supposedly provide a GUI interface
but it appears that LILO cannot. I have read many comments explaining
that serial lines cannot provide graphic information which is borne
out by entering Midnight Commander from the serial console. Lots of
garbled output and non-working function keys. I'm not sure how much
of the problem is software rather than the serial line. It might be
a little slower, but it seems to me that any information you can send
over ethernet could also be sent over a serial line.

Unless there is something I am missing...?

I mispoke in my previous post. After re-reading some documentation, it is not a menu (much less a GUI!) that the traditional arrangement of LILO brings up but just a prompt. As you have noted in your subsequent post, pressing tab shows you the available options but you still need to type one. The traditional LILO doesn't deal with a GUI at all. Not even an ncurses type of psuedo GUI or that arrangement of "buttons" <that some piece of software whose name I forget creates> that are controlled with TAB/ENTER. If you are seeing any kind of a GUI or menu on the monitor at boot time, I think it is a modification that Volkerding made.

I am not following this discussion about local and remote machines at all. I thought you had one machine (I'll call it A) which you were trying to control over a serial line from another machine (B). And that you had supplied A with two "console=" bootline parameters, modified A's lilo.conf by adding serial and instructing A's inittab to spawn agetty. And the only thing you were using B for was to run minicom to connect with A and interface the mentioned changes to A. Am I wrong?

I appologize. On your first post I misread tty0 as ttyS0.

I don't see how you can get a login prompt on B running minicom w/o running agetty or something similar on A. TMK this issue is completely independent of the boot issues we've been talking about. Except ... Something just occured to me. If the kernel keeps using ttyS0 after its initial boot (I don't know, but I would think it would) then you will have a conflict if you also try to use ttyS0 for agetty.

When I installed RH8.0 I was given the option to use either GRUB or LILO. I selected LILO since I was already familiar with it. I have since become familiar with GRUB.

My experience with GRUB is it does not produce what I would consider a real GUI, like you get, for example, running X11. It does produce (with a properly configued menu.lst file) a menu similar to (I believe) what you can create using ncurses where you control menu selection with up/down keys and ENTER. For another reference, this is similar to the interface for cfdisk. You can also tell GRUB to go to a command line where you have a surprisingly wide variety of commands available.

I didn't -- Red Hat did. It was setup with the installation of the OS. As opposed to what I have seen with GRUB this is a true GUI, although I think with low resolution graphics (640 x 480 or smaller?). I think it is rather nice. It includes the RH "shadowman" (I think I am using the right term for this) logo with a mainly blue background. In a white box down the left side is a list with room for up to maybe about a dozen entries.I don't have a digital camera, which is the only way I know (prior to booting an OS) I could take a screen shot.

As I mentioned earlier, I believe Red Hat modified LILO to create this. And possibly broke some serial capability in doing so.

As already mentioned, I believe this is the traditional LILO interface. You probably aren't going to get any more unless you modify LILO yourself.

There may be some confusion here about what is meant by a GUI. As that term is commonly used (for example, what is produced by X11) you can't do a GUI on a terminal (or terminal emulator) -- terminals simply don't have that kind of capability. However, I believe MC is a different issue (I have little experience with it). I believe it is another example of an ncurses type interface that I mentioned earlier. And that, TMK, should be able to be recreated on a terminal. Now I have had problems doing something similar over ssh on a local virtual terminal that was caused by a mismatch between the way the two machines were configured. So I suspect any problem with MC with a terminal is probably due to a mismatch between the terminal's capability/configuration and what the sending end is told about the configuration.

Buy in terms of LILO over a serial line, I suspect nobody has ever added the capability for a menu. (The source code is free to study and modify! ) If being presented with a menu is important to you, perhaps you should try GRUB. (Note: I see serial capability documented with GRUB but I have never tried it.)

Sorry about the 'getty' confusion. I tried to make clear in my original post the distinction between the booting computer and the computer acting as the terminal by using the Host/Remote exemplar. In your example, A was running a getty on ttyS0, as it should, and I also had getty running over ttyS0 on B. My point is that you can't have a getty running on each end of a serial connection or any connection for that matter. Enough said.

You also have my head spinning a bit with your discussions of a true GUI
interface produced by LILO and the ncurses-like interface that GRUB
produces. At first you say:

Are you talking about the prompt you get with a serial terminal or the traditional LILO ncurses-like menu you would normally see which LILO produces at the regular console (tty0 or tty1)? I am assuming you are talking about the serial terminal, and I don't think Patrick has modified anything in LILO.

However, it appears that Redhat has:

Again, I'm not sure if you're referring to the serial terminal or the traditional boot screen.

It doesn't really matter since I have satisfied myself that LILO, as it is, will not provide any type of GUI-like interface allowing a cursor key selection of kernel images to boot on a serial line.

As you say:

Although I've played with GRUB before, I wasn't able to make it work properly and just gave up. LILO seems to work well enough over a serial line as it is and a selection menu, whether it is ncurses-like (make menuconfig) or a true GUI, is nothing more than an interesting footnote.

Thanks for your help.

The confusion over what LILO will produce may stem from the fact that the only LILO I have used is Red Hat's, which paints a pretty picture on the screen. Perhaps I still shouldn't be calling it a GUI since you can't use a mouse with it. (Just up/down arrows.) Still, the kind of picture it paints is beyond the capability of a traditional terminal.

I believe this is Red Hat's modification. So my assumption about what I've called a "traditional" LILO interface comes from what I have read. When booting the computer with the RH version of LILO it first displays the "pretty picture." You can use up/down arrows and ENTER to select one of the options. Or, you can hit ctl-X and it will give a boot prompt (pretty picture goes away). IIRC, at this point hitting TAB will show you the options. The advantage of the command prompt is you can add aditional boot parameters.

So did you finally get everything working at a satisfactory level (even if not everything you hoped for)?

"As previously mentioned, GRUB can supposedly provide a GUI interface
but it appears that LILO cannot."

There is no GUI, just a simple ncurses-like menu system. You can bet there are a lot of ^H and other strange characters sent to the serial terminal.

To your lilo.conf, add:
install=menu

Then of course run lilo again so the changes take effect ...

Trying to solve problems in Linux is complicated by the fact that information
is usually a combination of old and new. It's often difficult to weed out
the extraneous or outmoded. The last posts reminded me to re-examine the
current documentation: man lilo.conf

The menu boot loader is the default in my version of LILO:

I am reasonably sure this is what you see in the Redhat distribution, although,
as you say, it may have been altered somewhat to be used over a serial line,

Man lilo.conf goes on to talk about using a bitmap as a background for the menu
with several other specifications:

The Serial Console HOWTO specifically states
that the "message=" does not work with a serial line and should not be used.
The man page goes on to explain:

All of this seems to point out that "install=menu" will do nothing since it is
in fact the default. Furthermore, nothing is mentioned in the section on serial
line specs about the 'menu' default. I may continue to experiment with the bitmap
options, but it appears that, over a serial line, text becomes the interface.

It works well enough to be useful as is. Unless you have any further input...?

One final comment.

While searching a little farther for the correct skinny on the
'menu' problem I came across the following annotated lilo.conf
man page from

http://www.linux-tutorial.info/modul...page=lilo.conf

These comments do not appear in the lilo.conf man page
on my Linux system.

How true, as I am about to illustrate ...

Both RH7.0 and RH8.0 use LILO v21.4.4. So, of course, their documentation says nothing about the new interpretation of "install=". Even my copy of Linux in a Nutshell (4th edition; (c) 2003 / purchased 2004) says nothing about it. And I have nothing newer! Here is the somewhat cryptic way my (old) man page describes "install="

The Nutshell book described it similarly. Neither gives a clue that that file has something to do with the user interface. Both of my lilo.conf files have the line: install=/boot/boot.b. I never did understand what that was about, but it worked ...

So I am glad you checked your documentation.

Thanks for posting the currently correct info you found. It may help somebody who stumbles onto this thread.

And just to add a little more fuel to the fire:

I had always wondered where this elusive boot.b was
and also where the boot-menu.b, boot-text.b appear since they
are absent in the /boot directory. Reading down just a little
further in the above referenced annotation:

Well, I think we have just about beaten this subject to death. I'm
sure we could add more if we tried, but I seem to have other things
to do. Imagine that.

Thanks again for your input!