Hi Johannes, Thank you for taking the time to submit a report.
On Wed, Apr 04, 2007 at 08:07:43PM +0200, Johannes Wiedersich wrote: > There were a few issues not covered in the release notes. > 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 :). > /---/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) - 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) > 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>? > During this period the system doesn't respond to ping, ssh > etc. After staying at 'loading portmap' for 15 minutes and booting up, > everything is normal. Ok, so not really an nis problem if the machine isn't responding to pings. Probably the most relevant information here is going to be anything the kernel logs while bringing up the network. > 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. > 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. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
