Hi Steve, Thank you for your long reply.
Steve Langasek wrote: >> 1) networking doesn't work properly any more > >> system takes about 20 minutes to boot. Most of this time is wasted, because >> portmap is trying in vain to mount nfs-filesystems before >> networking has been set up properly. > > Sorry, this is totally unreproducible for me, on any of my etch systems. If > anything, etch with udev works much *better* at bringing my network > interfaces up than sarge did (especially in the case of the system with a USB > WLAN device :). This is totally reproducible for me. I can even reproduce it on fresh installs. >> /---/etc/network/interfaces-------- >> auto lo >> iface lo inet loopback >> >> # The primary network interface >> auto eth0 eth0:1 >> iface eth0 inet static >> address 141.n.n.n >> netmask 255.255.255.0 >> network 141.n.n.n >> broadcast 141.n.n.n >> gateway 141.n.n.n >> # dns-* options are implemented by the resolvconf package, if >> installed >> dns-nameservers 141.40.131.47 >> dns-search physik.blm.tu-muenchen.de >> iface eth0:1 inet static >> address 192.n.n.n >> netmask 255.255.255.0 >> broadcast 192.168.0.255 >> \----------------------------------- > > This looks fine here; but to my understanding, it's not consistent with your > claim that networking takes /a long time/ to be set up. With 'auto' > interfaces, the network should either be brought up immediately, or not at > all. See, e.g., > <http://www.debian.org/releases/testing/i386/release-notes/ch-information.en.html#s-asynchronous-network-start> > in the current release notes draft, which describes a problem of > unpredictable behavior *only* if using allow-hotplug. > > Questions about your setup: > > - how fast is the system that you're seeing this problem on? (processor > type/speed) Doesn't matter. > - what type of hardware is eth0/what driver does it use? > - are there any messages in dmesg about trying to bring up the network? > - are there any known problems with arp on this network? > - have you tried a test boot using only one interface on eth0, without the > alias? (since your NFS servers are all on the eth0:1 network, this would > require renaming eth0:1 to eth0 temporarily) Swapping eth0:1 and eth0 permanently solves the situation on the two installations I tried (one fresh install, one upgrade). Apparently, only the 'external' eth0 was up - or at least portmap and/or nis only used that one initially (wasting the 15-20 minutes). Permanently exchanging eth0 and eth0:1 brings boot time back to reasonable 34s. In the past eth0 has always been the 'external' interface and eth0:1 the 'internal', because it was easier to have the 'external' ip for installation. Something seems to have changed here from sarge to etch. I guess it should be mentioned in the release notes or changed back to how it is in sarge. >> In the past this very files have always worked ok with our nis and >> nfs-server. > > Ah, you're using nis? Have you read > <http://www.debian.org/releases/testing/i386/release-notes/ch-information.en.html#s-nis>? Yes, and I don't have network-manager installed. >> 2) Many packages have been removed that probably shouldn't >> most importantly: kde (etc.), kdm, cupsys, xserver-xorg was not installed >> instead of xserver-xfree86 > > Was this following the procedure currently documented at > <http://www.debian.org/releases/testing/i386/release-notes/ch-upgrading.en.html#s-upgradingpackages>? > > I suspect not, since you haven't mentioned which option you used from 4.5.4. I followed 4.5.4.1 Upgrading a desktop system; ie. aptitude install libfam0 xlibmesa-glu Rereading the section more carefully, I /should/ have done aptitude install x11-common libfam0 xlibmesa-glu So this was a mistake on my part. I was probably carried away by the headlines, thinking that 'desktop system' describes my situation better than 'system with some X packages installed'... >> 3) swap appears not to work correctly any more > >> syslog: >> Apr 4 13:15:32 merkur kernel: Unable to find swap-space signature > >> the boot console says something about 'swapon /dev/hdb2: invalid argumet' >> IIRC. > > Sorry, I have no explanation for why a working swap partition's signature > would have been invalidated by an upgrade. If you're *sure* that /dev/hdb2 > points to the correct partition (and it doesn't now point to a live > filesystem as a result of device reordering in 2.6.18!), you can use mkswap > to recreate the swap signature. Done & works! Thanks, also for making etch such a nice release 8-) Cheers and Happy Easter holidays (if it applies to you; in Germany we have 4 holidays till tuesday ;-) Johannes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
