Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 1745 - Bootstrap locks up (not hardware)
Summary: Bootstrap locks up (not hardware)
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: x86 Linux
: High major (vote)
Assignee: Daniel Robbins (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-13 20:22 UTC by Charles N. Burns
Modified: 2011-10-30 22:22 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Charles N. Burns 2002-04-13 20:22:06 UTC
I tried installing Gentoo Linux from the 16MB .ISO, which I downloaded on
12APR2002. install.txt worked well, except the minor point that when it says
"Oh, a new prompt!" I still had the regular hash mark prompt. (not sure if that
is significant)
Anyway, everything goes well until the "scripts/bootscrap.sh" which downloads
and builds for a while and then dies.
What occurs:
- The terminal running the script stops. I can hit enter and scroll the text up,
I can hit arrow keys and fill the screen with escape codes, etc. but nothing else.
- All other terminals simply lock up completely, except for the terminal that is
running "less" which is viewing "install.txt" -- Less continues to work
perfectly, scrolling up and down and searching, etc., until I exit. After I exit
from less, I get the same thing as the emerge terminal--it technically responds
to keypresses but does nothing useful.
- If I go to a new terminal window and hit enter to activate the terminal, I get
the same thing. Nothing happens after I hit "enter" other than my characters
being echod onto the screen, but no shell is started.
- All terminals that are open and are actually running a copy of BASH simply
lock up completely, not responding to anything at all in any way. It is as if
the shell program ceases to exist and the system doesn't realize it.

Additionally, CTRL-ALT-DEL does not work on any terminal. CTRL-C works only on
the term running the script, cancelling the process officially which has already
stopped anyway. After this, the term behaves like the others. Note that this
does indeed stop--it isn't stuck on a step that happens to take a long time,
unless any one single step can take over 20 mins on a fairly fast system without
ever accessing the hard drive and while locking everything else up.

Step to reproduce (if anyone else can reproduce this):
1) Follow instructions in /install.txt, including:
# cd /usr/portage
# scripts/bootstrap.sh

Notes:
- I am using the default options in /etc/make.conf for an Athlon/PPro which
include the -march=pentiumpro option. At first I was using a few extra flags,
but not since the first try at installing.
- I have zeroed out the hard drive twice using 'dd'
- I am using xfs for /, ext3 for /boot, and have 1GB swap.
- This is probably not a hardware stability problem. The system is made of all
top-quality parts and has successfully done "make world" in freeBSD several
dozen times. It has also passed memtest86 without ECC enabled, and has ECC
enabled for single and double bit errors. Everything superfluous is disabled
(All IDE channels, USB, all COM ports, parallel port) and the BIOS settings are
very conservative.
- I have also tried doing an install without ever opening a second terminal
- XFS is using recommended settings from install.txt, EXT2 boot partition is
using defaults
- Both the swap and main partition are below the 1024 cylinder boundry (which I
did just to see if it would effect anything)
- The last thing seen on the screen is:
"
checking for bzero... yes
checking for calloc... yes
checking for clock...
"
(FWIW, yes the clock is set)

Hardware:
- Single AthlonXP 1400MHz, well cooled
-  on Tyan TigerMP mobo with BIOS 1.04 (newest)
- Single 1GB Corsair reg ECC memory module certified for this motherboard.
- Matrox G400 video
- Adaptec 29160 (64 bit version) SCSI adapter
- Maxtor Atlas 10K III 18GB U160 hard drive (/ is a 7 GB partition)
- Intel Pro100 NIC
- Plextor 40X wide CD-ROM
- Good power supply (400W PCPower & Cooling Silencer)
- No sound, RAID, mouse, IDE devices, etc.
- Not overclocked (In fact, I can't with this mobo)
- When the system was running Windows 2000, I did a stability test in which I
ran SETI@Home and 3DMark 2001 in a continuous loop for about 31 hours. No problems.
- This system has had Redhat 7.2 W\ Ximian successfully run and installed for a
Unix desktop demo I gave in class, so it probably isn't a hardware Linux
incompatibility.
Comment 1 Dee-Ann LeBlanc 2002-04-14 13:37:54 UTC
I'm having this exact same problem, just about. When I reach the installation 
instruction section code listing 17 and type source /etc/profile, I do not get 
a new prompt. Then, later, when I bootstrap, the machine hangs. In my case, I 
have absolutely no access to the machine. The screen isn't even just blank, 
it's inaccessible ... as though the machine's not even sending a blank screen 
to the monitor. No keystrokes work whatsoever.

I've had the same results with several different make.conf flag combinations on 
a PIII 450, using ext3 for the file system.
Comment 2 Charles N. Burns 2002-04-14 15:48:21 UTC
Addendum:
If it matters, I found why the shell prompt does not update when the
instructions say: "# Ooh! A new prompt!"
The /etc/profile shell script that the instructions say to "source" checks to
see if $SHELL is "/bin/bash", but I have found that the $SHELL variable is
always "/bin/sh" even if the shell is bash. "/bin/sh" is a symlink to
"/bin/bash", so they are the same, but the variable is not the same so when
"profile" checks the $SHELL variable, it sees the wrong one and never sets the
prompt and whatever else it is supposed to set.

Workaround:
For users, prior to "source /etc/profile", type "SHELL = /bin/bash; export SHELL"

For the developers: Have /etc/profile simply not even check the shell. It's not
like csh or ksh is even installed at this point, and if someone does install it
and it screws up the install, it's their own fault for not following the
instructions. Alternatively, allow /bin/sh to be just as valid as /bin/bash
Comment 3 Charles N. Burns 2002-04-14 18:13:59 UTC
Update:
I have successfully installed Gentoo using the stage 3 ISO, and while in Gentoo
have successfully rebuilt everything without any problem. I suspect that the
kernel used for the install may be the problem, and suggest that it be changed
to a "safe" kernel, given that having the absolute latest kernel with high
optimizations does not matter for a kernel that won't be used for more than the
installation.
Comment 4 Daniel Robbins (RETIRED) gentoo-dev 2002-04-14 23:14:03 UTC
Yes, our current kernel's XFS dies with highmem; this will be fixed next release.