[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Misc problems with b-f 2.3.6 install, hppa

Richard Hirst wrote:
> At the end of an install, base-config 1.04, it offers to remove some pkgs;
> console-*, because I'm on serial console, I guess, and also base-config
> itself.  Is that expected?

console-* yes, base-config no. Unless you explicitly picked it for
removal in dselect I guess. If you didn't mark it for removal in
dselect, I don't know what could cause it to be removed. A conflict with
something? A dependancy issue with hacking base-config 1.04 into
testing? Was this on testing?

> Kind of makes it difficult to rerun base-config later, as an earlier
> screen suggested.
> Also, when I let it remove base-config I was screwed because init could
> nolonger find termwrap.

Well I do want to let users manually remove base-config if they know
what they're doing. But it needs to deal with itself being removed in
the middle of a base-config run. This will be fixed in 1.06.

> If I don't remove base-config, I get the 'you may now log
> in as root' screen, I hit return, and am back in to base-config.
> Run through it again, and then I get a real login prompt.

This I don't know. It sounds like base-config either unexpectly exited
before it could fix the inittab (but it fixes the innittab immeditly
after showing that message!), or the inittab fix didn't "take"
immeditely. (I do HUP init, perhaps there is really a little race
between init hupping and base-config finishing? Seems unlikly.) It would
be nice to know what the inittab contained the when it began looping
back through base-config.

(Another nice hack in base-config debugging is when debian first boots,
boot it up single user at first, and reconfigure debconf, picking the
debconf text frontend, and then run base-config manually. Then you can easily 
see any error messages that might flash by and suspend it to examine system

> In the first stage install I get nice |-+ chars to draw the box outlines
> (serial console, remember), but in the second stage install I get nasty
> 'A' with dots above in place of '-' for horizontal lines.  I set
> TERM=vt100 via the kernel command line for both halves of the install.

This is a whiptail (or slang) bug, I guess. Sounds like slang is not
detecting that your terminal does not support the alternate character
set. Slang's handing of this is pretty odd, and I have had to add a
--lowbit option to one slang-using program I wrote to make it work on
all systems.

Anyway, you should be able to reproduce the problem on an installed
system by runnnig whiptail:

	whiptail --msgbox test 10 20

see shy jo

Reply to: