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

Re: More stuff the installer does which isn't done on upgrade

Nathanael Nerode wrote:
> (I would add this to the Wiki page 
> http://wiki.debian.org/Sarge2EtchUpgrade but someone made it immutable...)

Seems editable here..
> #1.
> Just noticed that /etc/network/interfaces is set up differently on new installs;
> it uses udev/hotplug now by default, while it didn't before.
> On old installs it looks like this:
> ------------
> # The first network card - this entry was created during the Debian installation
> auto eth0
> iface eth0 inet dhcp
> ---------
> While on new installs it looks like this:
> ----------
> # This is a list of hotpluggable network interfaces.
> # They will be activated automatically by the hotplug subsystem.
> mapping eth0
>         script grep
>         map eth0

We haven't used the "script grep" hack in quite some time, this
entire stanza is not present in new installs, though it might be present
on some oldish ones.

> # The primary network interface
> allow-hotplug eth0
> iface eth0 inet dhcp

Yes, it writes "allow-hotplug" instead of "auto" if the interface seems
to be hotpluggable. (Most interfaces appear that way with udev.)

An old system that has "auto eth0" here will work fine though, unless
eth0 is in fact a hotpluggable interface, in which case hotplugging it
will not work. Is there a case where hotplugging would have worked in
sarge and won't in etch, with the old config? That would be one for the
release notes.

> ------------
> #2. 
> Also noticed that on my old system /etc/network/run is a symlink to 
> /dev/shm/network.  This was set up in the past by ifupdown.
> Yet earlier installations will have it as a symlink to /etc/network.
> However, new installations make it a directory.  I'm not entirely sure
> why, but it's probably some interaction between udev and initscripts.postinst
> and whatnot.

Perhaps ifupdown.postinst's tests for /dev/shm fail when run in the d-i
environment? Sounds like a likely bug, since d-i does not set up a

> #3.
> On new installs, the contents of /etc/default/rcS have changed.  It appears 
> that this file didn't always belong to a package, or something, because it 
> doesn't trigger the expected notice from dpkg for upgraded configuration files.
> Notably DELAYLOGIN has changed value (from yes to no) and EDITMOTD has become 
> obsolete.

/etc/default/rcS is not modified or created by the installer, it is a
configuration file that is maintained by initscripts's postinst. Currently
initscripts only puts the file in place if it does not yet exist, and never
updates it.

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: