I am forced to do a networkless install due to ridgid corporate firewall policy not even webrsync works!. I have tried a stage 1 install and found this bug bought in the documentation as well as in the universal live cd 2004. It has been reported numerous times in the forums and there seems to be no cure. I cant understand why after copying the portage snapshot and sorce files of the live cd (as mentioned in the dowcumentation) it still tries during bootstrap.sh to download some files of the server. I see that MY CHOICE HAS NOT BEEN RESPECTED AND THAT YOU ARE FORCIG PEOPLE WHO CANT DO NET INSTALLS TO DO A STAGE 3 INSTALL. As i want to twek my system and Gentoo is all about choices i see a big flow in the distribution hear and would apriciate if it was seen to. Reproducible: Always Steps to Reproduce: 1.chroot into new gentoo enviroment 2.run bootstrap.sh 3.tries to download (obviosly stoped by firewall) 4.Returns back to root Actual Results: No bootstraping and Seriosly unsatisfied user Expected Results: Bootstrap into a stage 2 install as instructed by the installation (x86 arcitecture) documentation following net less procedures. Windows xp, corporate firewall at remote privet ISP, Usb keyboard and optical PS2 mouse (not much else that i see relevant) Tanks in advance for your time.
Stage1-Installations have never been and will never been covered with networkless installations. Networkless-Installations only work with stage3 + GRP (requires universal livecd + GRP/Packages-CD)
If you have the ability to view web sites from work, you have the ability to use webrsync. Make sure you've set your proxies properly for wget (man wget) and it will work.
Also, how would you recommend that we supply all of the possible distfiles that you could have when doing a stage1? What if you changed your USE flags? What if you decided to use bootstrap-2.6.sh? Either of those would require different distfiles than the sensible defaults that we provide. We simply cannot be expected to provide the source downloads for every possible combination of software in the portage tree.
The problem seems to be in the gentoo kernell as i can use the normal net install (tanks to the guys at the forums who pointed this out) if i use the SMP kernell wich does the trick.
Just a tale from the stale... :-)) IIRC, I experienced an unusable network device using 2004.3-r1 x86 universal CD Boot on my P3-celeron-1066 laptop with e100. I was participating on 21c3 (if You don't know this, 21c3 can -in this context- be imagined as a big lan party, whereby this lan itself might be a reason for misbehaving network devices:)... There was no network uplink for a real long time period where I found a seat. Though links were up on the switches, the uplink was down, so there was no dhcp server reachable, and I was kind of "waiting for the uplink"... Later, when the uplink was reported to be up by other users nearby, I still had no network connectivity, gave "net-setup eth0" some tries, gave manual starting of dhcpcd some tries, configured private IPs (192.168.x.x) manually. Don't remember if I unloaded/loaded the net module, if possible then I sure did, but without success. Tested with some loopback cables, pinging each of the other hosts and the broadcast address in turn, exchanging cables between my laptop and two other PCs, all with a 192.168.x.x/24 net and three different IPs assigned. tcpdump captured nothing coming in on my laptop (only my pings going out) and nothing coming in on the other hosts from my laptop as well, though the other PCs answered sent their echo-replys to each other. After rebooting, network operated flawlessly (as before, at home) and the loopback worked, too. I wouldn't believe this, if I hadn't experienced it myself. The only experience that comes close to this was with kernels before 2.4.5 on SMP (dual-cpu) >450 MHz and dual-eepro100 onboard, where the eth0 was unusable after about every 20st reboot (some message like RXRing empty), but module unloading was a cure in that case. I had a machine set up to reboot all the time some 24 hours to make sure about that... Though my laptop is only a single-cpu (p3 celeron) machine, maybe the reboot is a common fix? In this bug's "base comment" only "chroot" is mentioned, so if Nicholas just did "mkfs, unpack stage, unpack portage, chroot" over and over, then there is a little chance of coincidence... :-)
