Bug#615600: BOOTIF= kernel commandline option does not work
tags 615600 pending
thanks
On Wed, Mar 23, 2011 at 08:31:56PM -0500, Dustin Kirkland wrote:
On Sun, 27 Feb 2011 16:22:28 -0400, Joey Hess wrote:
BOOTIF is a pxelinux boot parameter. It is supported by the Debian
initramfs when pxe booting, but it is not supported by the Debian
installer.
Perhaps it should be. In the meantime, you can use the documented
preseeding interface of booting with interface=eth1. I don't think
netcfg allows specifying a interface by MAC though.
Floris Bos mentioned that this is similar to an oldish bug (at least
by Ubuntu standards) in Ubuntu's bug tracker against the netcfg
package:
provide a method to use a specified MAC-address as the installation device
* https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/56679
We have a proposed solution, in the attached script, S31pxedust.
Thanks for sending this along.
I think honouring BOOTIF is the right thing to do. You can always
remove 'ipappend 2' if you don't like it, but I think the overwhelming
probability is that you want to use the same interface for installation
as you did for PXE-booting.
However, I think this implementation has two problems:
* It's at too high a priority: it overrides any other setting of
netcfg/choose_interface. If you have 'ipappend 2' but also for some
reason have (say) interface=eth1 in your boot parameters, then the
latter is a more explicit instruction to d-i and therefore should
win. (Andrew noted this in
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/56679/comments/13.)
* It runs too early. Network interfaces may not necessarily be
available when debian-installer-startup runs; this isn't too likely
in a netboot image, granted, but it's possible if you're adding
drivers later by way of a USB stick or something.
I think Andrew's script was expedient for him - it's a lot simpler to
drop a shell script into d-i's initramfs than it is to modify C programs
there - but a better long-term solution for us would be to do this in
netcfg itself. I have put my money where my mouth is and implemented
this. My patch overrides the results of link detection with the
interface that matches BOOTIF, but preseeding an interface name
overrides both of those. This feels right to me. I've done some
testing in a qemu instance with multiple network interfaces and it's
behaving exactly as I'd expect.
I've committed the following patch, and I plan to release netcfg 1.63
with it shortly.
commit 33aeb7186837a6d7fa4762d72455e70672501cbe
Author: Colin Watson cjwat...@debian.org
Date: Thu Jun 16 18:00:44 2011 +0100
If BOOTIF= is set on the Linux command line, look for an interface with
that address and use it by default (closes: #615600, LP: #56679).
diff --git a/debian/changelog b/debian/changelog
index 61df533..1bcd302 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+netcfg (1.63) UNRELEASED; urgency=low
+
+ * If BOOTIF= is set on the Linux command line, look for an interface with
+that address and use it by default (closes: #615600, LP: #56679).
+
+ -- Colin Watson cjwat...@debian.org Thu, 16 Jun 2011 14:20:04 +0100
+
netcfg (1.62) unstable; urgency=low
[ Updated translations ]
diff --git a/netcfg-common.c b/netcfg-common.c
index 972ce86..7e5a3fa 100644
--- a/netcfg-common.c
+++ b/netcfg-common.c
@@ -46,6 +46,10 @@
#include ifaddrs.h
+#ifdef __linux__
+#define SYSCLASSNET /sys/class/net/
+#endif /* __linux__ */
+
#ifdef __FreeBSD_kernel__
#define LO_IF lo0
#else
@@ -128,8 +132,6 @@ void open_sockets (void)
#ifdef __linux__
-#define SYSCLASSNET /sys/class/net/
-
/* Returns non-zero if this interface has an enabled kill switch, otherwise
* zero.
*/
@@ -187,8 +189,6 @@ int check_kill_switch(const char *iface)
return ret;
}
-#undef SYSCLASSNET
-
#else /* !__linux__ */
int check_kill_switch(const char *iface)
{
@@ -471,6 +471,102 @@ FILE *file_open(char *path, const char *opentype)
}
}
+const char *find_bootif_iface(int num_interfaces, char **ifs)
+{
+#ifdef __linux__
+#define PROC_CMDLINE /proc/cmdline
+#define ADDRESS_LEN 17 /* aa:bb:cc:dd:ee:ff */
+
+int i;
+FILE *cmdline_file;
+char *cmdline = NULL;
+size_t dummy;
+const char *s;
+char *bootif = NULL;
+
+/* Look for BOOTIF= entry in kernel command line. */
+
+cmdline_file = file_open(PROC_CMDLINE, r);
+if (!cmdline_file) {
+di_error(Failed to open PROC_CMDLINE : %s, strerror(errno));
+return NULL;
+}
+if (getline(cmdline, dummy, cmdline_file) 0) {
+di_error(Failed to read line from PROC_CMDLINE : %s,
+ strerror(errno));
+fclose(cmdline_file);
+return NULL;
+}
+
+s = cmdline;
+while ((s = strstr(s, BOOTIF=)) != NULL) {
+if (s == cmdline || s[-1] == ' ') {
+size_t bootif_len;
+char *subst;
+
+s += sizeof(BOOTIF=) - 1;
+bootif_len = strcspn(s, );
+
Bug#615600: BOOTIF= kernel commandline option does not work
Howdy, I just came across this report in Debian's bug tracker. On Sun, 27 Feb 2011 16:22:28 -0400, Joey Hess wrote: BOOTIF is a pxelinux boot parameter. It is supported by the Debian initramfs when pxe booting, but it is not supported by the Debian installer. Perhaps it should be. In the meantime, you can use the documented preseeding interface of booting with interface=eth1. I don't think netcfg allows specifying a interface by MAC though. Floris Bos mentioned that this is similar to an oldish bug (at least by Ubuntu standards) in Ubuntu's bug tracker against the netcfg package: provide a method to use a specified MAC-address as the installation device * https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/56679 We have a proposed solution, in the attached script, S31pxedust. Adding 'ipappend 2' to the host's pxelinux config file makes PXELINUX append the mac address of that interface to the kernel options. * http://syslinux.zytor.com/wiki/index.php/SYSLINUX#IPAPPEND_flag_val_.5BPXELINUX_only.5D This allows the initrd to access to the mac address of the interface which PXE booted and is probably the interface we want to use for DHCP. Executing from the debian-installer-startup.d directory of the initrd, this script reads the value of the 'BOOTIF' kernel option and looks to see if there is an interface name with this mac address. If so, it then uses 'db_set' to change the 'netcfg/choose_interface' option to this interface name. Would you be willing to consider this approach? We'd absolutely like to avoid diverging from Debian in support of a BOOTIF kernel option for installations, and we have a great need for a supported approach. I'm willing and able to modify and test the attached boot accordingly. Please advise. Thanks, -- :-Dustin Dustin Kirkland Ubuntu Core Developer S31pxedust Description: Binary data
Bug#615600: BOOTIF= kernel commandline option does not work
On Wed, Mar 02, 2011 at 01:41:58AM +0100, Ferenc Wagner wrote:
Marc Haber mh+debian-b...@zugschlus.de writes:
On Tue, Mar 01, 2011 at 04:28:16PM +0100, Marc Haber wrote:
I guess the following changes do kind of a job:
etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
ACTION==add, SUBSYSTEM==net, IMPORT{program}=bootif $attr{address}
Unfortunately, this seems to go a little too far. My test system comes
up with the second interface being the bootif, so it's eth1 without
these additions.
This seems to be the fault of the additional rule which gives the
impression that the rule is actually doing something. Even when I
replace the bootif script with a call to true, I get multiple stanzas
per interface in 70-persistent-net.rules.
In my limited testing (with two Qemu interfaces) this didn't happen
after several
# rm 70-persistent-net.rules
# udevadm trigger --verbose --action=add --subsystem-match=net
cycles.
Did you try with a multiprocessor VM? I guess that this is some
threading/multiprocessing issue that multiple interfaces get processed
at the same time, causing races.
Actually, your rule worked perfectly well, despite that you don't
reserve the eth0 name, just try to assign it even if it's taken
already. Unless I overlook something, this should be fixed.
How do I reserve a name?
I usually assign symbolic names instead of ethX ones, like wlan, utp,
private, gb1 (chassis label) or similar; they usually work just fine,
but sometimes break assumptions of some software (like Munin plugins).
Maybe keeping the domain and the range of the mapping would help
debugging this case as well.
I do this for my personal servers as well, but for the default
install, I'd rather follow the principle of least surprise for the
other admins that will use the servers deployed by me.
So it would really be nice to have ethx, starting at eth0 being the
right interfaces, with the other interfaces being consecutively
numbered as ethx.
Do I need to say in the 69-bootif.rules that this should be treated as
a no-op rule?
I don't think so. But /lib/udev/write_net_rules activates set -x if
udev logging is set to debug level, and while the output in
/var/log/syslog is less than readable, it may prove some insight.
# udevadm control --log-priority=debug
I'll try that and report back. Thanks for helping.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: BOOTIF= kernel commandline option does not work
Marc Haber mh+debian-b...@zugschlus.de writes:
On Wed, Mar 02, 2011 at 01:41:58AM +0100, Ferenc Wagner wrote:
Marc Haber mh+debian-b...@zugschlus.de writes:
On Tue, Mar 01, 2011 at 04:28:16PM +0100, Marc Haber wrote:
I guess the following changes do kind of a job:
etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
ACTION==add, SUBSYSTEM==net, IMPORT{program}=bootif $attr{address}
Unfortunately, this seems to go a little too far. My test system comes
up with the second interface being the bootif, so it's eth1 without
these additions.
This seems to be the fault of the additional rule which gives the
impression that the rule is actually doing something. Even when I
replace the bootif script with a call to true, I get multiple stanzas
per interface in 70-persistent-net.rules.
In my limited testing (with two Qemu interfaces) this didn't happen
after several
# rm 70-persistent-net.rules
# udevadm trigger --verbose --action=add --subsystem-match=net
cycles.
Did you try with a multiprocessor VM? I guess that this is some
threading/multiprocessing issue that multiple interfaces get processed
at the same time, causing races.
Maybe, I didn't try it on SMP. write_net_rules has some locking to
prevent such issues, though.
Actually, your rule worked perfectly well, despite that you don't
reserve the eth0 name, just try to assign it even if it's taken
already. Unless I overlook something, this should be fixed.
How do I reserve a name?
By renaming eth0 to something else, unless it isn't the boot interface.
But /lib/udev/write_net_rules activates set -x if udev logging is set
to debug level, and while the output in /var/log/syslog is less than
readable, it may prove some insight.
# udevadm control --log-priority=debug
I'll try that and report back. Thanks for helping.
Hey, thanks for maintaining Exim!
--
Regards,
Feri.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: BOOTIF= kernel commandline option does not work
On Wed, Mar 02, 2011 at 04:44:07PM +0100, Ferenc Wagner wrote:
Marc Haber mh+debian-b...@zugschlus.de writes:
On Wed, Mar 02, 2011 at 01:41:58AM +0100, Ferenc Wagner wrote:
Marc Haber mh+debian-b...@zugschlus.de writes:
On Tue, Mar 01, 2011 at 04:28:16PM +0100, Marc Haber wrote:
I guess the following changes do kind of a job:
etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
ACTION==add, SUBSYSTEM==net, IMPORT{program}=bootif $attr{address}
Unfortunately, this seems to go a little too far. My test system comes
up with the second interface being the bootif, so it's eth1 without
these additions.
This seems to be the fault of the additional rule which gives the
impression that the rule is actually doing something. Even when I
replace the bootif script with a call to true, I get multiple stanzas
per interface in 70-persistent-net.rules.
In my limited testing (with two Qemu interfaces) this didn't happen
after several
# rm 70-persistent-net.rules
# udevadm trigger --verbose --action=add --subsystem-match=net
cycles.
Did you try with a multiprocessor VM? I guess that this is some
threading/multiprocessing issue that multiple interfaces get processed
at the same time, causing races.
Maybe, I didn't try it on SMP. write_net_rules has some locking to
prevent such issues, though.
My rule hasn't, but it shouldn't do anything if the script is silent,
should it?
Actually, your rule worked perfectly well, despite that you don't
reserve the eth0 name, just try to assign it even if it's taken
already. Unless I overlook something, this should be fixed.
How do I reserve a name?
By renaming eth0 to something else, unless it isn't the boot interface.
So my script should print INTERFACE_NAME=foo0 to its standard output
if invoked for an interface that is eth0 and not the boot interface?
And who is responsible to rename it back into the ethx namespace?
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: BOOTIF= kernel commandline option does not work
Marc Haber mh+debian-b...@zugschlus.de writes: On Wed, Mar 02, 2011 at 04:44:07PM +0100, Ferenc Wagner wrote: Maybe, I didn't try it on SMP. write_net_rules has some locking to prevent such issues, though. My rule hasn't, but it shouldn't do anything if the script is silent, should it? Your rule shouldn't do anything than possibly importing a property into the event environment, and the bootif script only reads constant data, so it shouldn't need any locking either. Actually, your rule worked perfectly well, despite that you don't reserve the eth0 name, just try to assign it even if it's taken already. Unless I overlook something, this should be fixed. How do I reserve a name? By renaming eth0 to something else, unless it isn't the boot interface. So my script should print INTERFACE_NAME=foo0 to its standard output if invoked for an interface that is eth0 and not the boot interface? And who is responsible to rename it back into the ethx namespace? Nobody, I'm afraid. What you want isn't particularly simple, especially that ethX devices may be appearing concurrently, so you'll have to synchronize much like write_net_rules does. You can't even guarantee that there will be an eth0 at the end! I'd probably start by modifying write_net_rules, it already has some special code handling eth0. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: BOOTIF= kernel commandline option does not work
On Sun, Feb 27, 2011 at 04:22:28PM -0400, Joey Hess wrote:
Thomas Mieslinger wrote:
I try to install a HP DL180G6 fully automated. The Server has an
addtional dualport NIC. kernel and initrd are loaded over the NIC
labeled 0 on the Box, after the kernel has initialized all NICs the
first Ethernet on the add in card is eth0.
~ # cat /proc/cmdline
initrd=/boot/DEBIAN6_x8664/initrd.gz
preseed/url=http://4.3.2.1/installation/profiles/1cc1deebab9e
BOOTIF=01-1C-C1-DE-EB-AB-9E BOOT_DEBUG=2 DEBCONF_DEBUG=5 fb=false
BOOTIF is a pxelinux boot parameter. It is supported by the Debian
initramfs when pxe booting, but it is not supported by the Debian
installer.
Perhaps it should be. In the meantime, you can use the documented
preseeding interface of booting with interface=eth1. I don't think
netcfg allows specifying a interface by MAC though.
I guess the following changes do kind of a job:
etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
ACTION==add, SUBSYSTEM==net, IMPORT{program}=bootif $attr{address}
lib/udev/bootif (inside the installer's initrd)
#!/bin/sh
bootif=$( /proc/cmdline sed 's/.*[[:space:]]BOOTIF=\([-0-9A-Fa-f]\+\).*/\1/'
| tr '[A-F-]' '[a-f:]')
if [ 01:$1 = $bootif ]; then
echo INTERFACE_NAME=eth0
fi
Unfortunately, this seems to go a little too far. My test system comes
up with the second interface being the bootif, so it's eth1 without
these additions. With my additions, the following numbering happens:
MAC Addresswithout additionswith additions
Aeth0 eth4
Beth1 eth0
Ceth2 eth3
Deth3 eth5
The /etc/udev/rules.d/70-persistent-net.rules that is being generated
has the first interface found twice:
ATTR{address} NAME with additions
Ceth2
Ceth3
Beth0
Aeth4
Deth5
I guess there may be a race going on. Is there any possibility to have
bootif honored without generating a broken 70-persistent-net.rules and
with still having the interfaces numbered consecutively?
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: BOOTIF= kernel commandline option does not work
On Tue, Mar 01, 2011 at 04:28:16PM +0100, Marc Haber wrote:
I guess the following changes do kind of a job:
etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
ACTION==add, SUBSYSTEM==net, IMPORT{program}=bootif $attr{address}
Unfortunately, this seems to go a little too far. My test system comes
up with the second interface being the bootif, so it's eth1 without
these additions.
This seems to be the fault of the additional rule which gives the
impression that the rule is actually doing something. Even when I
replace the bootif script with a call to true, I get multiple stanzas
per interface in 70-persistent-net.rules.
Do I need to say in the 69-bootif.rules that this should be treated as
a no-op rule?
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: BOOTIF= kernel commandline option does not work
Hi,
On Tuesday, March 01, 2011 04:28:16 pm Marc Haber wrote:
On Sun, Feb 27, 2011 at 04:22:28PM -0400, Joey Hess wrote:
Thomas Mieslinger wrote:
I try to install a HP DL180G6 fully automated. The Server has an
addtional dualport NIC. kernel and initrd are loaded over the NIC
labeled 0 on the Box, after the kernel has initialized all NICs the
first Ethernet on the add in card is eth0.
~ # cat /proc/cmdline
initrd=/boot/DEBIAN6_x8664/initrd.gz
preseed/url=http://4.3.2.1/installation/profiles/1cc1deebab9e
BOOTIF=01-1C-C1-DE-EB-AB-9E BOOT_DEBUG=2 DEBCONF_DEBUG=5 fb=false
BOOTIF is a pxelinux boot parameter. It is supported by the Debian
initramfs when pxe booting, but it is not supported by the Debian
installer.
Perhaps it should be. In the meantime, you can use the documented
preseeding interface of booting with interface=eth1. I don't think
netcfg allows specifying a interface by MAC though.
I guess the following changes do kind of a job:
etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
ACTION==add, SUBSYSTEM==net, IMPORT{program}=bootif $attr{address}
The related Ubuntu bug has a patch as well:
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/56679
(Matt already mentioned he doesn't like that patch, so it's not a permantent
solution.
But if you are just looking for a quick fix for now, you can use it in your own
build).
--
Yours sincerely,
Floris Bos
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: BOOTIF= kernel commandline option does not work
Marc Haber mh+debian-b...@zugschlus.de writes:
On Tue, Mar 01, 2011 at 04:28:16PM +0100, Marc Haber wrote:
I guess the following changes do kind of a job:
etc/udev/rules.d/69-bootif.rules (inside the installer's initrd)
ACTION==add, SUBSYSTEM==net, IMPORT{program}=bootif $attr{address}
Unfortunately, this seems to go a little too far. My test system comes
up with the second interface being the bootif, so it's eth1 without
these additions.
This seems to be the fault of the additional rule which gives the
impression that the rule is actually doing something. Even when I
replace the bootif script with a call to true, I get multiple stanzas
per interface in 70-persistent-net.rules.
In my limited testing (with two Qemu interfaces) this didn't happen
after several
# rm 70-persistent-net.rules
# udevadm trigger --verbose --action=add --subsystem-match=net
cycles. Actually, your rule worked perfectly well, despite that you
don't reserve the eth0 name, just try to assign it even if it's taken
already. Unless I overlook something, this should be fixed.
I usually assign symbolic names instead of ethX ones, like wlan, utp,
private, gb1 (chassis label) or similar; they usually work just fine,
but sometimes break assumptions of some software (like Munin plugins).
Maybe keeping the domain and the range of the mapping would help
debugging this case as well.
Do I need to say in the 69-bootif.rules that this should be treated as
a no-op rule?
I don't think so. But /lib/udev/write_net_rules activates set -x if
udev logging is set to debug level, and while the output in
/var/log/syslog is less than readable, it may prove some insight.
# udevadm control --log-priority=debug
--
Regards,
Feri.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: Bug#504753: Bug#615600: BOOTIF= kernel commandline option does not work
reassign 615600 netcfg retitle 615600 Please allow selecting interface by its MAC address thanks Quoting Thomas Mieslinger (thomas.mieslin...@1und1.de): To get my job done all those 5000 Machines must comply to some very very basic guidelines. After the installation, the inner interface is always eth0 if there is a public interface, it is eth1. If there are crosslinks they are eth1 and onward. I need a simple and powerful mechanism to enforce this against the quirks of udev and bioses. You may want to develop the needed support for such things in netcfg. From what I read of Joey's answer, a solution could be allowing to specify the wanted interface by its MAC address, in netcfg, through a specific boot parameter...or s specific handling of the existing interface parameter. signature.asc Description: Digital signature
Bug#615600: BOOTIF= kernel commandline option does not work
On Sun, Feb 27, 2011 at 06:20:48PM +0100, Thomas Mieslinger wrote: I try to install a HP DL180G6 fully automated. The Server has an addtional dualport NIC. kernel and initrd are loaded over the NIC labeled 0 on the Box, after the kernel has initialized all NICs the first Ethernet on the add in card is eth0. ~ # cat /proc/cmdline initrd=/boot/DEBIAN6_x8664/initrd.gz preseed/url=http://4.3.2.1/installation/profiles/1cc1deebab9e BOOTIF=01-1C-C1-DE-EB-AB-9E BOOT_DEBUG=2 DEBCONF_DEBUG=5 fb=false language=en console-setup/layoutcode=de locale=en_US netcfg/choose_interface=eth0 hostname=review-dl180g6 domain=server.lan usb_storage.blacklist=yes console-keymaps-at/keymap=de console-keymaps-usb/keymap=mac-usb-de-latin1 debian-installer/country=US console=ttyS0 BOOT_IMAGE=/boot/DEBIAN6_x8664/linux 3: eth1: BROADCAST,MULTICAST mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 1c:c1:de:eb:ab:9e brd ff:ff:ff:ff:ff:ff this is seriously twisted, because 1c:c1:de:eb:ab:9e and f are onboard igb devices and 00:15:17:cc:d0:16 and 7 are on one dualport e1000e add in Card. So you would basically want the installer to rename the interfaces so that the interface that the system booted from (as given as BOOTIF kernel command line parameter) is eth0 in the freshly installed system? Maybe it would be a good idea not to have this enabled by default, but for example by a new command line parameter eth0=macaddress with the special case of eth0=bootif which would make sure that eth0 is the PXE device? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: Bug#504753: Bug#615600: BOOTIF= kernel commandline option does not work
On Mon, Feb 28, 2011 at 06:39:48AM +0100, Christian PERRIER wrote: Quoting Thomas Mieslinger (thomas.mieslin...@1und1.de): To get my job done all those 5000 Machines must comply to some very very basic guidelines. After the installation, the inner interface is always eth0 if there is a public interface, it is eth1. If there are crosslinks they are eth1 and onward. I need a simple and powerful mechanism to enforce this against the quirks of udev and bioses. You may want to develop the needed support for such things in netcfg. Are there any docs for netcfg? After a cursory glance at the source package, it looks like the docs are contained in those nice .c and .h files with a little too little documentation about the interfaces. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: Bug#504753: Bug#615600: BOOTIF= kernel commandline option does not work
Marc Haber mh+debian-b...@zugschlus.de writes: On Mon, Feb 28, 2011 at 06:39:48AM +0100, Christian PERRIER wrote: Quoting Thomas Mieslinger (thomas.mieslin...@1und1.de): To get my job done all those 5000 Machines must comply to some very very basic guidelines. After the installation, the inner interface is always eth0 if there is a public interface, it is eth1. If there are crosslinks they are eth1 and onward. I need a simple and powerful mechanism to enforce this against the quirks of udev and bioses. You may want to develop the needed support for such things in netcfg. Are there any docs for netcfg? After a cursory glance at the source package, it looks like the docs are contained in those nice .c and .h files with a little too little documentation about the interfaces. There's no docs for netcfg, AFAIK, but it isn't that complicated. However, Matt Palmer is currently reorganizing the code, so you'd better synchronize with him before you start fiddling with it. On the other hand, the issue at hand probably doesn't belong into netcfg. Naming network interfaces is a job for udev, and netcfg can simply use eth0 after that, if I read Thomas correctly. I routinely do this by putting /etc/udev/rules.d/60-manual-net.rules into the installer initramfs AND copying it into /target at the end of the installation. One could make this fully dynamic if needed, even without remastering the initramfs, by elaborate preseed/early_command specifications. -- Regards, Feri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: BOOTIF= kernel commandline option does not work
Package: debian-installer Version: 20110106+b1 Hi, I try to install a HP DL180G6 fully automated. The Server has an addtional dualport NIC. kernel and initrd are loaded over the NIC labeled 0 on the Box, after the kernel has initialized all NICs the first Ethernet on the add in card is eth0. ~ # cat /proc/cmdline initrd=/boot/DEBIAN6_x8664/initrd.gz preseed/url=http://4.3.2.1/installation/profiles/1cc1deebab9e BOOTIF=01-1C-C1-DE-EB-AB-9E BOOT_DEBUG=2 DEBCONF_DEBUG=5 fb=false language=en console-setup/layoutcode=de locale=en_US netcfg/choose_interface=eth0 hostname=review-dl180g6 domain=server.lan usb_storage.blacklist=yes console-keymaps-at/keymap=de console-keymaps-usb/keymap=mac-usb-de-latin1 debian-installer/country=US console=ttyS0 BOOT_IMAGE=/boot/DEBIAN6_x8664/linux Booting the commandline on this machine results in this ~ # ip a 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: BROADCAST,MULTICAST mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:15:17:cc:d0:16 brd ff:ff:ff:ff:ff:ff 3: eth1: BROADCAST,MULTICAST mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 1c:c1:de:eb:ab:9e brd ff:ff:ff:ff:ff:ff 4: eth2: BROADCAST,MULTICAST mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:15:17:cc:d0:17 brd ff:ff:ff:ff:ff:ff 5: eth3: BROADCAST,MULTICAST mtu 1500 qdisc mq state DOWN qlen 1000 link/ether 1c:c1:de:eb:ab:9f brd ff:ff:ff:ff:ff:ff this is seriously twisted, because 1c:c1:de:eb:ab:9e and f are onboard igb devices and 00:15:17:cc:d0:16 and 7 are on one dualport e1000e add in Card. Please fix this. Thanks Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615600: BOOTIF= kernel commandline option does not work
Thomas Mieslinger wrote: I try to install a HP DL180G6 fully automated. The Server has an addtional dualport NIC. kernel and initrd are loaded over the NIC labeled 0 on the Box, after the kernel has initialized all NICs the first Ethernet on the add in card is eth0. ~ # cat /proc/cmdline initrd=/boot/DEBIAN6_x8664/initrd.gz preseed/url=http://4.3.2.1/installation/profiles/1cc1deebab9e BOOTIF=01-1C-C1-DE-EB-AB-9E BOOT_DEBUG=2 DEBCONF_DEBUG=5 fb=false BOOTIF is a pxelinux boot parameter. It is supported by the Debian initramfs when pxe booting, but it is not supported by the Debian installer. Perhaps it should be. In the meantime, you can use the documented preseeding interface of booting with interface=eth1. I don't think netcfg allows specifying a interface by MAC though. -- see shy jo signature.asc Description: Digital signature
Bug#615600: BOOTIF= kernel commandline option does not work
Am 27.02.2011 21:22, schrieb Joey Hess: Thomas Mieslinger wrote: BOOTIF=01-1C-C1-DE-EB-AB-9E BOOT_DEBUG=2 DEBCONF_DEBUG=5 fb=false BOOTIF is a pxelinux boot parameter. It is supported by the Debian initramfs when pxe booting, but it is not supported by the Debian installer. Understood. While googling, I found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504753. This does a half hearted job by setting automatically netcfg/choose_interface. Perhaps it should be. In the meantime, you can use the documented preseeding interface of booting with interface=eth1. I don't think netcfg allows specifying a interface by MAC though. In my reality there are lots of boxes (5k) with lots of different configurations of onboard and addin cards. To get my job done all those 5000 Machines must comply to some very very basic guidelines. After the installation, the inner interface is always eth0 if there is a public interface, it is eth1. If there are crosslinks they are eth1 and onward. I need a simple and powerful mechanism to enforce this against the quirks of udev and bioses. reagards Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
