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

Bastian Venthur wrote: > I've written a bugreport (#403706) which was discussed for a long time > until it finally was downgraded from grave to important and became a > "documentation issue" the for release-notes. > > A questionable move especially since I know from debian-user-german that > many u

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, whil

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

On Mon, Mar 26, 2007 at 12:30:30AM -0400, Nathanael Nerode wrote: > (I would add this to the Wiki page > http://wiki.debian.org/Sarge2EtchUpgrade but someone made it immutable...) The information you posted belongs to release-notes's BTS, not to the wiki (as the wiki tries to track a sarge->etch

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

On Mon, Mar 26, 2007 at 10:45:46AM +0200, Javier Fernández-Sanguino Peña wrote: > On Mon, Mar 26, 2007 at 12:30:30AM -0400, Nathanael Nerode wrote: > > (I would add this to the Wiki page > > http://wiki.debian.org/Sarge2EtchUpgrade but someone made it immutable...) > > The information you posted

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

On 3/26/07, Nathanael Nerode <[EMAIL PROTECTED]> wrote: (I would add this to the Wiki page http://wiki.debian.org/Sarge2EtchUpgrade but someone made it immutable...) It's not immutable when you log in. -- Andrew Donnellan ajdlinuxATgmailDOTcom (primary)ajdlinuxATexemailDOTcomDOTau (secure)

Re: daylight saving time and RTC clock

> "Santiago" == Santiago Vila <[EMAIL PROTECTED]> writes: Santiago> Why don't you just keep your RTC to UTC? It worked for Santiago> me. It breaks if you need to dual boot to a competing operating system and keep track of times. Hmmm. What was it called again? I think it was this "Win

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

On Mar 26, Bastian Venthur <[EMAIL PROTECTED]> wrote: > I've written a bugreport (#403706) which was discussed for a long time > until it finally was downgraded from grave to important and became a > "documentation issue" the for release-notes. Hopefully for lenny we will switch to upstart, which

Re: daylight saving time and RTC clock

hi & thanks anyone yes, in the past I had to accomodate for dual booting into that peculiar other operating system (hereby called Windows, as by Santiago suggestion) : I developed gtkmorph in the past, and it had to run on both O.S.es ; but nowadays I dont, so I think I will switch my RTC to UTC,

Re: release update: d-i schedule, release notes, deep freeze

Holger Levsen <[EMAIL PROTECTED]> writes: > Hi, > > On Friday 23 March 2007 13:54, Goswin von Brederlow wrote: >> We still have no usable linux-source deb. The prepatched source >> currently shipped will not build vserver, xen and several archs and >> the debian patch is not compatible to make-kpk

Kernel selection in the installation system

Hello, when installing a Debian etch machine, the installation system automatically selects the kernel which is most appropriate for the CPU and installs the corresponding kernel package on the harddisk of the machine. Can anybody tell me how the installer decides which kernel to be installed? Or

Re: Kernel selection in the installation system

On Monday 26 March 2007 17:24, Christoph Pleger wrote: > Can anybody tell me how the installer decides which kernel to be > installed? Or tell me where I can find the source code of the selection > process? It is done from the /var/lib/dpkg/base-installer.postinst script, which calls an architect

Re: Kernel selection in the installation system

IIRC, the kernel udeb in the installer image runs the installer kernel during installation and the installer checks for the CPU type. You can use the 'expert' install option to be given the opportunity to manually select which kernel is installed during installation. - Lawrence On March 26, 2

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

On Mon, 26 Mar 2007, Joey Hess wrote: Nathanael Nerode wrote: [...] 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: -- #

Ethernet interface numbering in etch

Hi, I have spent the past few days trying to figure out why some of our machines seem to have ethernet interface numbers that jump around -- eth0 one day, then eth4 or eth5 another. The culprit comes down to udev. I've filed a bug #416284 against it for this. Basically, udev is trying to assign

Re: Ethernet interface numbering in etch

On Monday 26 March 2007 10:11, John Goerzen wrote: > I have spent the past few days trying to figure out why some of our > machines seem to have ethernet interface numbers that jump around -- > eth0 one day, then eth4 or eth5 another. As a corollary to this, I have machines where the disks swap de

Re: Ethernet interface numbering in etch

John Goerzen <[EMAIL PROTECTED]> writes: > I have spent the past few days trying to figure out why some of our > machines seem to have ethernet interface numbers that jump around -- > eth0 one day, then eth4 or eth5 another. > The culprit comes down to udev. I've filed a bug #416284 against it f

Re: Ethernet interface numbering in etch

* Russ Allbery: > There's actually some stuff in udev or some related package to deal with > this, but I can't ever seem to find it when I need it. I think this is > actually a documentation bug more than a functionality bug; we just need a > better guide on how to do it. You can, somehow, assig

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

Joey Hess schrieb: > Bastian Venthur wrote: >> I've written a bugreport (#403706) which was discussed for a long time >> until it finally was downgraded from grave to important and became a >> "documentation issue" the for release-notes. >> >> A questionable move especially since I know from debian

Re: Ethernet interface numbering in etch

On Mar 26, John Goerzen <[EMAIL PROTECTED]> wrote: > I think that the right thing to do is to assign the persistent names to > network devices that still exist in the system, but to do nothing with > any other network devices. That will allow systems to still boot and > come up properly in the fa

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 07:35:39PM +0200, Marco d'Itri wrote: > On Mar 26, John Goerzen <[EMAIL PROTECTED]> wrote: > > > I think that the right thing to do is to assign the persistent names to > > network devices that still exist in the system, but to do nothing with > > any other network devices.

Re: racoon and bug 372665

Hello Milan, Milan P. Stanic <[EMAIL PROTECTED]> wrote: > On Sun, Mar 04, 2007 at 06:36:34PM +0530, Ganesan Rajagopal wrote: >> > Milan P Stanic <[EMAIL PROTECTED]> writes: >> >> > I'd like to discuss problem with regards to bug #372665. >> > Why the racoon should be started in the rcS when e

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 12:42:54 -0500, John Goerzen wrote: > On Mon, Mar 26, 2007 at 07:35:39PM +0200, Marco d'Itri wrote: > > On Mar 26, John Goerzen <[EMAIL PROTECTED]> wrote: > > > > > I think that the right thing to do is to assign the persistent names to > > > network devices that still exi

Re: Problems packaging a kernel using cdbs

I tried building using make-kpkg with --initrd binary options, and ended up with a cpio archive. Why? I have no idea. I looked at the output of the make-kpkg command and was unable to determine which tool it was using to make the initramfs. I suggest some output be generated that shows not only

Re: Ethernet interface numbering in etch

Am Montag 26 März 2007 19:26 schrieb Florian Weimer: > * Russ Allbery: > > There's actually some stuff in udev or some related package to deal with > > this, but I can't ever seem to find it when I need it. I think this is > > actually a documentation bug more than a functionality bug; we just nee

Re: Ethernet interface numbering in etch

* Julien Cristau: > I think the problem is that you can't know in advance whether the device > still exists or not, and whether it will be plugged in later (because > everything runs asynchronously). Sure, but hotpluggable PCI(e) interfaces are the exception, not the norm. It seems wrong to opti

Re: Problems packaging a kernel using cdbs

On Monday 26 March 2007 12:09, Alan Ezust wrote: > I tried building using make-kpkg with  --initrd binary options, and ended > up with a cpio archive. Why? I have no idea. An initramfs is a cpio archive. I am assuming that are you referring to the file created after the kernel is installed. Is t

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 08:15:30PM +0200, Florian Weimer wrote: > Sure, but hotpluggable PCI(e) interfaces are the exception, not the > norm. It seems wrong to optimize for this case. udev sees network devices, not pci devices. and hotpluggable network devices are common. Bastian -- A woman sh

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 08:28:02PM +0200, Bastian Blank wrote: > On Mon, Mar 26, 2007 at 08:15:30PM +0200, Florian Weimer wrote: > > Sure, but hotpluggable PCI(e) interfaces are the exception, not the > > norm. It seems wrong to optimize for this case. > > udev sees network devices, not pci devic

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 07:54:45PM +0200, Hendrik Sattler wrote: > > The trouble is that nowadays, the kernel does not assign predictable > > interface names, and an increasing number of systems has got more than > > one Ethernet interface. The downside is that typical Debian > > installations are

Re: Problems packaging a kernel using cdbs

Yes, I'm referring to the initrd.img-2.6.16.XX-bla-di-blah file that is installed by dpkg when I install the generated kernel-image .deb file that I created using make-kpkg (--initrd binary).. On 3/26/07, Warren Turkal <[EMAIL PROTECTED]> wrote: On Monday 26 March 2007 12:09, Alan Ezust wrote:

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 01:41:26PM -0500, John Goerzen wrote: > On Mon, Mar 26, 2007 at 07:54:45PM +0200, Hendrik Sattler wrote: > > You only need to delete /etc/udev/rules.d/z25_persistent*.rules before udev > > runs. That should be doable and could be a configuration option. The > > default >

Re: Ethernet interface numbering in etch

* Bastian Blank: > On Mon, Mar 26, 2007 at 08:15:30PM +0200, Florian Weimer wrote: >> Sure, but hotpluggable PCI(e) interfaces are the exception, not the >> norm. It seems wrong to optimize for this case. > > udev sees network devices, not pci devices. and hotpluggable network > devices are commo

Re: Ethernet interface numbering in etch

Il giorno 26/mar/07, alle ore 21:29, Mark Brown ha scritto: The use cases where users are likely to notice are relatively limited - you need to either be trying to do some sort of system imaging or doing hardware replacement where you need to do a like for like swap. The latter case tends to

Re: fakechroot - anyone using it, should I consider hijacking it?

On Mon, 2007-03-26 at 00:04 -0400, Mark Eichin wrote: > I certainly have seen lots of packages build correctly with fakechroot > as-shipped - and these fixes should significantly raise that number. The more people that use fakechroot the better, but I suppose the thing that scares me a little is "

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 11:11:32PM +0200, Luigi Gangitano wrote: > 1. Some ethernet cards like Sun QuadFE share the same MAC address > (even if global OpenFirmware option is set to different MAC-address) > and PCI id and udev blocks while renaming them, leaving with an > unusable systema eac

Re: Problems packaging a kernel using cdbs

Ah, I see. the initrd is created at install time, not at .deb package building time. I inspected the generated .deb file and indeed, there is no initrd.img in the .deb file - the initrd is created when you actually install the package on the target system, which means it's the target system that

Re: Ethernet interface numbering in etch

Hi John! On Mon, 26 Mar 2007, John Goerzen wrote: > On Mon, Mar 26, 2007 at 08:28:02PM +0200, Bastian Blank wrote: > > On Mon, Mar 26, 2007 at 08:15:30PM +0200, Florian Weimer wrote: > > > Sure, but hotpluggable PCI(e) interfaces are the exception, not the > > > norm. It seems wrong to optimize

Re: Ethernet interface numbering in etch

Florian Weimer <[EMAIL PROTECTED]> writes: > * Russ Allbery: >> There's actually some stuff in udev or some related package to deal >> with this, but I can't ever seem to find it when I need it. I think >> this is actually a documentation bug more than a functionality bug; we >> just need a bette

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 11:11:32PM +0200, Luigi Gangitano wrote: > BTW, there's no easy way to recover from a badly renamed ethernet interface. > Once you have something like 'eth5_rename' how are you supposed to recover? As you would do for a "normal" interface rename: ip link set eth5_

Re: Ethernet interface numbering in etch

Heya, > As a corollary to this, I have machines where the disks swap device files on > each boot. It's pretty annoying when my nfs volumes switch which device name > is used to mount them. > you could mount them by UUID instead of the device name. Bernd -- Bernd Zeimetz <[EMAIL PROTECTED]>

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 01:40:14PM -0500, John Goerzen wrote: > Still the exception, not the norm. No, ever since distros started using modular kernels, hotplug _is_ the norm. You can get rid of it only by building your own kernel image with all hardware drivers statically built in and module sup

Re: Ethernet interface numbering in etch

On Tue, Mar 27, 2007 at 12:00:05AM +0200, Bernd Zeimetz wrote: > you could mount them by UUID instead of the device name. Btw. do Debian initrds already support specifying the root fs with LABEL= like Fedora/RedHat? Gabor -- - M

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 01:41:26PM -0500, John Goerzen wrote: > On Mon, Mar 26, 2007 at 07:54:45PM +0200, Hendrik Sattler wrote: > > > The trouble is that nowadays, the kernel does not assign predictable > > > interface names, and an increasing number of systems has got more than > > > one Ethernet

Re: Ethernet interface numbering in etch

On Mon, Mar 26, 2007 at 11:11:04AM -0500, John Goerzen wrote: > * dmesg output still mentions hardware using eth0, even if you can't >talk to it at eth0 but must instead use eth5. dmesg doesn't >mention this fact, making it difficult to track down problems. It's nothing new, this is the

Re: racoon and bug 372665

On Mon, Mar 26, 2007 at 05:05:53PM +, Jörg Sommer wrote: > Milan P. Stanic <[EMAIL PROTECTED]> wrote: > > README says that in the /etc/rcS.d/ should go scripts which are > > executed once during boot. In debian policy manual rcS.d is > > mentioned only once in section 9.3.4, but from short desc

Re: Ethernet interface numbering in etch

> Btw. do Debian initrds already support specifying the root fs with > LABEL= like Fedora/RedHat? > Didn't try it, but according to [1] they do. Cheers, Bernd [1] http://wiki.debian.org/InitrdReplacementOptions -- Bernd Zeimetz <[EMAIL PROTECTED]>

Re: Ethernet interface numbering in etch

I demand that Luigi Gangitano may or may not have written... [snip] > 1. Some ethernet cards like Sun QuadFE share the same MAC address (even if > global OpenFirmware option is set to different MAC-address) and PCI id and > udev blocks while renaming them, leaving with an unusable systema each tim

Re: racoon and bug 372665

Hello Milan, Milan P. Stanic <[EMAIL PROTECTED]> wrote: > On Mon, Mar 26, 2007 at 05:05:53PM +, Jörg Sommer wrote: >> Milan P. Stanic <[EMAIL PROTECTED]> wrote: >> > README says that in the /etc/rcS.d/ should go scripts which are >> > executed once during boot. In debian policy manual rcS.d is

Attempted summary and thoughts (was Re: On maintainers not responding to bugs)

I've been reading the discussion and trying to thresh something out of it. Four points and one proposal. Point 1. --- Contrary to some assumptions, answering "I got your bug report but I can't deal with it right now" is *very* useful, particularly in encouraging people to help. I've reported

Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)

On Mon, Mar 26, 2007 at 09:12:32PM -0400, Nathanael Nerode wrote: > > > If a package has a bug with a *patch* attached, where the *patch* has not > been reviewed on by the maintainer(s) within six months, the package will > be orphaned immediately; the maintainer will not be allowed to adopt

Re: Attempted summary and thoughts

Nathanael Nerode <[EMAIL PROTECTED]> writes: > Actually, after describing the worst-case scenario, I am going to make a > new tentative proposal: > > If a package has a bug with a *patch* attached, where the *patch* has > not been reviewed on by the maintainer(s) within six months, the packa

Re: Attempted summary and thoughts

Nathanael Nerode <[EMAIL PROTECTED]> writes: > I've been reading the discussion and trying to thresh something out > of it. Thanks very much for taking the time to do this. A summary of a long thread is useful. > Four points and one proposal. I agree with all the points. I won't comment on the

Re: Attempted summary and thoughts

Russ Allbery <[EMAIL PROTECTED]> writes: > If no one has time to work on a package, orphaning the package > doesn't make it better. In that case, orphaning the package doesn't make it better. I think Nathaniel was describing the case where people *do* have the time, and indeed are proposing fixe

Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)

Roberto C. Sánchez <[EMAIL PROTECTED]> wrote: >Out of curiousity, what is the algorithm for determining whether a patch >has been reviewed? If it is not an algorithm, per se, then what is the >heuristic? If the maintainer has sent a message to the bug trail mentioning the patch sometime after th

Re: Attempted summary and thoughts

Ben Finney <[EMAIL PROTECTED]> writes: > Russ Allbery <[EMAIL PROTECTED]> writes: >> If that person has showed up and is being blocked from helping for some >> reason, *then* we can talk. > I think that's what the proposal is suggesting. Do you think the metric > used is bad, or is there some oth

Re: racoon and bug 372665

> "Jörg" == Jörg Sommer <[EMAIL PROTECTED]> writes: > Can't raccon be started like wpa_supplicant by an ifup command? You can > start the wpa_supplicant by bringing up the interface: > ,[ /etc/network/interfaces ]--- > | iface eth1 inet manual > | wpa_roam /etc/wpa_supplicant.conf

Re: Ethernet interface numbering in etch

After writing a very long message, I realize that there was a much simpler solution, so if you want to cut to the chase, skip to the end! Steve Langasek wrote: >Which do you think is the common case -- a system with more than one network >interface where it's necessary to preserve interface order

Re: Ethernet interface numbering in etch

On Tue, Mar 27, 2007 at 12:01:13AM +0200, Gabor Gombas wrote: > No, ever since distros started using modular kernels, hotplug _is_ the > norm. debian (and other distros) used modular kernels (2.4.18 in woody) without hotplug or the like. > You can get rid of it only by building your own kernel im

Re: Ethernet interface numbering in etch

On Tue, Mar 27, 2007 at 12:06:09AM -0400, Nathanael Nerode wrote: > After writing a very long message, I realize that there was a much simpler > solution, so if you want to cut to the chase, skip to the end! > Steve Langasek wrote: > >Which do you think is the common case -- a system with more th

Re: Ethernet interface numbering in etch

On Tue, Mar 27, 2007 at 06:39:55AM +0200, NN_il_Confusionario wrote: > On Tue, Mar 27, 2007 at 12:01:13AM +0200, Gabor Gombas wrote: > > No, ever since distros started using modular kernels, hotplug _is_ the > > norm. > debian (and other distros) used modular kernels (2.4.18 in woody) > without ho

Re: Ethernet interface numbering in etch

On Tue, Mar 27, 2007 at 12:06:09AM -0400, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > After writing a very long message, I realize that there was a much simpler > solution, so if you want to cut to the chase, skip to the end! > > Steve Langasek wrote: > >Which do you think is the common case -

Re: Attempted summary and thoughts (was Re: On maintainers not responding to bugs)

On Mon, Mar 26, 2007 at 09:38:24PM -0400, Roberto C. Sánchez <[EMAIL PROTECTED]> wrote: > > People should be given assistance and encouragement in > > doing it. I actually like doing it, but I have unfortunately relatively > > little time (sick family members). > > > I like doing bug triage as w

Re: Ethernet interface numbering in etch

On 3/27/07, Steve Langasek <[EMAIL PROTECTED]> wrote: Which means that your network interface wouldn't come up automatically when you changed hardware either, so that's not exactly better than the udev solution in that respect. :) Seems to me udev is only tangentially related to this discussio