[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#417822: marked as done (upgrade-reports: network not working properly after sarge --> etch)



Your message dated Sun, 8 Apr 2007 17:55:23 -0700
with message-id <20070409005523.GD22542@dario.dodds.net>
and subject line Bug#417822: upgrade-reports: network not working properly after sarge --> etch
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: upgrade-reports
Severity: important

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. 

/---/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
\-----------------------------------

/---/etc/fstab----------------------
/dev/hda1       /               ext3    defaults,errors=remount-ro 0       1
/dev/md0        /merkur         ext3    defaults        0       2
/dev/hdb2       none            swap                    0       2
/dev/hda2       none            swap                    0       2
/dev/hdb1       /merkur1         ext3    defaults        0       2
/dev/hdc        /media/cdrom0   iso9660 ro,user,noauto  0       0
/dev/hdd        /media/cdrom1   iso9660 ro,user,noauto  0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto  0       0
192.168.0.n:/home  /home       nfs     suid,dev,exec   0       0
192.168.0.n:/atheneraid /atheneraid nfs suid,dev,exec  0       0
/dev/sda1       /media/sda1    auto      user,noauto,defaults 0 0
192.168.0.n:/atheneraid/tausch         /tausch           nfs     exec,suid,dev  0       0
\-----------------------------------

In the past this very files have always worked ok with our nis and nfs-server. Not any more. System takes ages to boot, after this is 
complete, network shares are mounted and nis is working. Probably portmap and/or nis try to access 192. adresses before they are 
initialized. 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. 

Note that this behaviour is *not* perculiar to the upgrade, it is observed for 'new' installs of etch as well. Network setup is as 
described in the third example of etch's /usr/share/doc/ifupdown/examples/network-interfaces.gz 

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 

This includes those marked as 'manually 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. 



I am happy to provide log-files or a 'script'-transcript of the upgrade, if it would be useful. 

I would really like to get networking working in less than 15 minutes! 

Thanks for the good work! Etch is great!

Johannes

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


--- End Message ---
--- Begin Message ---
clone 417822 -1
reopen -1
reassign -1 ifupdown
found -1 0.6.8
retitle -1 ifup -a returns before alias interfaces are brought up
thanks

On Thu, Apr 05, 2007 at 04:48:29PM +0200, Johannes Wiedersich wrote:
> > - 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.

Hmm, very peculiar.  I seem to be able to confirm this; if I have an alias
for eth0, on reboot the address on the interface alias is *not* brought up
synchronously in spite of being listed as 'auto' in /etc/network/interfaces,
and as a result NFS mounting fails immediately after bringing the interface
up if the route to the NFS server depends on the interface alias.

> 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.

Well, changing it back would require first understanding why it broke.

Anyway, since this is the only unresolved issue in your upgrade report, I'm
cloning this bug over to ifupdown and closing the upgrade report.

> >> 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'...

> 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 ;-)

Happy Easter. :)

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/

--- End Message ---

Reply to: