Bug#417822: upgrade-reports: network not working properly after sarge --> etch
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
Reply to: