Debian Jessie net installations broken for last months
Hi, We having been having problems with preseeded PXE network installations of Debian Jessie for the past months, while it used to work before, and other Debian editions do install properly. First of all our installation script used to be able to download the network installation files (kernel/initrd) from: http://ftp.debian.org/debian/dists/jessie/main/installer-amd64/current/ But that folder disappeared. Filled a bug report a month ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928517. But did not receive any response. Then tried the network installation files in the other folder "20150422+deb8u" that does still exist: http://ftp.debian.org/debian/dists/jessie/main/installer-amd64/20150422+deb8u5/images/netboot/debian-installer/amd64/ But that will fail to complete installation on servers do not have full Internet access. We set a custom mirror with the "d-i mirror/http/hostname" preseed option. But it also wants to download repository files from http://security.debian.org/ nevertheless, which will fail with a warning. It then complains that the (mirrored) http://ftp.debian.org/debian/dists/jessie-updates/InRelease file does not have the right entries. "Unable to find expected entry 'main/binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file)" The InRelease file for stretch and buster does have main/binary-amd64/Packages entries on the main mirror site. Any reason they are no longer there for jessie even while that release is not EOL yet? Yours sincerely, Floris Bos
Re: Jessie: network link detection problems with Intel nics
On 08/12/2014 01:15 PM, Cyril Brulebois wrote: Hi, and thanks for your report (even if the best way is filing a proper bug report in the BTS: https://www.debian.org/Bugs/). Floris Bos b...@je-eigen-domein.nl (2014-08-12): I'm having an odd problem on one of my servers in which the network link is not detected (error getting DHCP, going to console and entering ip link shows NO_CARRIER) on preseeded Jessie installations. Mainboard: http://www.supermicro.nl/products/motherboard/Xeon/C220/X10SLM_-LN4F.cfm 4x i210AT NIC on mainboard, cable connected to eth0 Problem always occurs on: - Debian Jessie when doing automated installations - Ubuntu 13.10 netinstall - Ubuntu 14.04 netinstall Problem does not occurs on: - Debian Wheezy Problem sometimes occurs on: - Interactive installations on Debian Jessie. They work most of the time, but not always. A few things that come to mind: - what if there's an extra cable plugged on to a NIC that isn't the one you PXE-booted from? There might be something going on that could be related to the boot method, like a faulty initialization somewhere because there was already some traffic on that interface. Hmm, that is strange as well. With a second cable connected to one of the other ports it does work, even when PXE booting from eth0, and telling Debian to use eth0. Which doesn't work without the second cable. It doesn't see the link on eth0 straight away, only after deactivating and activating. == Aug 12 14:49:43 netcfg[1663]: INFO: Activating interface eth0 Aug 12 14:49:44 netcfg[1663]: INFO: Waiting time set to 3 Aug 12 14:49:44 kernel: [ 12.793292] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Aug 12 14:49:44 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:44 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:45 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:45 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:45 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:45 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:46 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:46 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:46 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:46 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:47 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:47 netcfg[1663]: INFO: ethtool-lite: eth0 is disconnected. Aug 12 14:49:47 netcfg[1663]: INFO: Reached timeout for link detection on eth0 Aug 12 14:49:47 netcfg[1663]: INFO: found no link on interface eth0. Aug 12 14:49:47 netcfg[1663]: INFO: eth0 is not a wireless interface. Continuing. Aug 12 14:49:47 netcfg[1663]: INFO: Taking down interface eth0 Aug 12 14:49:47 netcfg[1663]: INFO: Taking down interface eth0 Aug 12 14:49:47 netcfg[1663]: INFO: Activating interface eth1 Aug 12 14:49:48 netcfg[1663]: INFO: Waiting time set to 3 Aug 12 14:49:48 kernel: [ 16.683201] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready Aug 12 14:49:48 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:48 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:49 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:49 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:49 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:49 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:50 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:50 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:50 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:50 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:51 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:51 netcfg[1663]: INFO: ethtool-lite: eth1 is disconnected. Aug 12 14:49:51 netcfg[1663]: INFO: Reached timeout for link detection on eth1 Aug 12 14:49:51 netcfg[1663]: INFO: found no link on interface eth1. Aug 12 14:49:51 netcfg[1663]: INFO: eth1 is not a wireless interface. Continuing. Aug 12 14:49:51 netcfg[1663]: INFO: Taking down interface eth1 Aug 12 14:49:51 netcfg[1663]: INFO: Taking down interface eth1 Aug 12 14:49:51 netcfg[1663]: INFO: Activating interface eth2 Aug 12 14:49:52 netcfg[1663]: INFO: Waiting time set to 3 Aug 12 14:49:52 kernel: [ 20.572957] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready Aug 12 14:49:52 netcfg[1663]: INFO: ethtool-lite: eth2 is disconnected. Aug 12 14:49:52 netcfg[1663]: INFO: ethtool-lite: eth2 is disconnected. Aug 12 14:49:52 netcfg[1663]: INFO: ethtool-lite: eth2 is disconnected. Aug 12 14:49:53 netcfg[1663]: INFO: ethtool-lite: eth2 is disconnected. Aug 12 14:49:53 netcfg[1663]: INFO: ethtool-lite: eth2 is disconnected. Aug 12 14:49:53 netcfg[1663]: INFO: ethtool-lite: eth2
Re: preseed installation, hostname and PTR
On 10/08/2012 05:51 PM, George Shuklin wrote: Found very strange behavior: If VM installed with preseed and new VM hostname is passed via kernel command line, installer ignores that option and use data from DNS (PTR record for IP). This is bug or feature? I found it in sqeeze/wheezy and ubuntu (12.04) installers. Deja vu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606636 To me it is still a bug, although others mentioned it is documented behavior. -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5073278f.3000...@je-eigen-domein.nl
Re: preseed installation, hostname and PTR
On 10/08/2012 11:13 PM, Philipp Kern wrote:
On Mon, Oct 08, 2012 at 09:20:47PM +0200, Floris Bos / Maxnet wrote:
Deja vu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606636
To me it is still a bug, although others mentioned it is documented
behavior.
It is. However that patch would need to be redone against Matt's changes
to netcfg.
Attached a new one, so that excuse can no longer be used.
Yours sincerely,
Floris Bos
diff -ur netcfg-1.98.orig/debian/netcfg-common.templates netcfg-1.98/debian/netcfg-common.templates
--- netcfg-1.98.orig/debian/netcfg-common.templates 2012-10-03 01:23:27.0 +0200
+++ netcfg-1.98/debian/netcfg-common.templates 2012-10-09 01:34:16.287439267 +0200
@@ -152,6 +152,12 @@
administrator. If you are setting up your own home network, you can make
something up here.
+Template: netcfg/hostname
+Type: string
+Description: Hostname that can be preseeded.
+ .
+ If specified this disables the automatic detection of the hostname by netcfg.
+
Template: netcfg/invalid_hostname
Type: error
# :sl2:
Only in netcfg-1.98/debian: netcfg.debhelper.log
Only in netcfg-1.98/debian: netcfg-static.debhelper.log
diff -ur netcfg-1.98.orig/dhcp.c netcfg-1.98/dhcp.c
--- netcfg-1.98.orig/dhcp.c 2012-09-25 02:07:24.0 +0200
+++ netcfg-1.98/dhcp.c 2012-10-09 01:57:22.055463420 +0200
@@ -559,12 +559,19 @@
{
char buf[MAXHOSTNAMELEN + 1] = { 0 };
/*
- * Default to the hostname returned via DHCP, if any,
+ * If the netcfg/hostname preseed value is set use that
+ * otherwise default to the hostname returned via DHCP, if any,
* otherwise to the requested DHCP hostname
* otherwise to the hostname found in DNS for the IP address
* of the interface
*/
-if (gethostname(buf, sizeof(buf)) == 0
+debconf_get(client, netcfg/hostname);
+if (!empty_str(client-value))
+{
+strncpy(buf, client-value, MAXHOSTNAMELEN);
+preseed_hostname_from_fqdn(client, buf);
+}
+else if (gethostname(buf, sizeof(buf)) == 0
!empty_str(buf)
strcmp(buf, (none))
) {
diff -ur netcfg-1.98.orig/static.c netcfg-1.98/static.c
--- netcfg-1.98.orig/static.c 2012-10-04 23:14:35.0 +0200
+++ netcfg-1.98/static.c 2012-10-09 01:58:14.375464370 +0200
@@ -608,8 +608,15 @@
break;
case GET_HOSTNAME:
{
-char buf[MAXHOSTNAMELEN + 1];
-if (get_hostname_from_dns(iface, buf, sizeof(buf)))
+char buf[MAXHOSTNAMELEN + 1] = { 0 };
+
+debconf_get(client, netcfg/hostname);
+if (!empty_str(client-value))
+{
+strncpy(buf, client-value, MAXHOSTNAMELEN);
+preseed_hostname_from_fqdn(client, buf);
+}
+else if (get_hostname_from_dns(iface, buf, sizeof(buf)))
preseed_hostname_from_fqdn(client, buf);
}
state = (netcfg_get_hostname(client, netcfg/get_hostname, hostname, 1)) ?
Bug#681801: Preseeding console-keymaps-at/keymap=us no longer works to select keymap
Package: console-setup-udeb Version: 1.80 We perform automated preseeded Debian installations. With Debian Squeeze we are able to use the following boot parameters to prevent Debian from prompting for country and keyboard settings: == debian-installer/locale=en_US kbd-chooser/method=us console-keymaps-at/keymap=us == However with Wheezy this no longer works, and we get prompted for keyboard map regardless (screenshot: http://s17.postimage.org/on6is922n/keymap_prompt.png ) In case a different preseed value then console-keymaps-at/keymap=us is necessary nowadays, please update the documentation ( http://d-i.alioth.debian.org/manual/en.amd64/apbs04.html#preseed-l10n ) -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5004481c.6020...@je-eigen-domein.nl
Re: preseed doesn't overwrite existing lvm partitioning
On 03/23/2012 07:51 PM, Ryan Braun [ADS] wrote: I could have sworn I had tested this previously, but it doesn't seem to be working for me. I have a preseed configured and it will install on virgin hardware without problem. But if I run the same install procedure for a second time on the same machine, I keep getting no root partition errors from the partitioner. Noticed that as well. Currently use the following ugly workaround to get the first disk (on some systems it is not /dev/sda) and remove LVM stuff: d-i partman/early_command string debconf-set partman-auto/disk $(list-devices disk | head -n1) ; pvremove -y -ff `list-devices disk | head -n1`* || true (To get it more foolproof, you might also need to check other disks in the system for the presense of lvm volume group names that might conflict with what the installer wants to use) -- Yours sincerely, Floris Bos
Re: preseed doesn't overwrite existing lvm partitioning
On 03/23/2012 09:01 PM, Ryan Braun [ADS] wrote: On March 23, 2012 07:17:17 pm Floris Bos / Maxnet wrote: Though I would like to maybe see a new partman d-i option. d-i partman/confirm_all boolean true kind of thing. Would indeed be nice. And ideally it should not just be a partman option, but a global option to assume sensible defaults for an unattended installation so that does not stop until an error is really fatal. Now you need to set about 50 preseed options to get a more or less flawless fully automated installation. While I suspect that a large number of users only want a custom root password and a custom network configuration, and could live with defaults for everything else... Yours sincerely, Floris Bos
Re: TRIM support for ext4
On 03/12/2012 07:51 AM, Joey Hess wrote: Floris Bos / Maxnet wrote: In addition to that, it would also be nice if the -E discard option is passed to mkfs.ext4, so that it TRIMs the entire disk partition prior to creating the file system structures. -E discard is the default, according to mkfs.ext4(8) Not the most clear man page... On the (Ubuntu) version I have on my desktop, it also says nodiscard is the default?! == discard Attempt to discard blocks at mkfs time (discarding blocks initially is useful on solid state devices and sparse / thin-provisioned storage). When the device advertises that dis‐ card also zeroes data (any subsequent read after the discard and before write returns zero), then mark all not-yet-zeroed inode tables as zeroed. This significantly speeds up filesystem initialization. This is set as default. nodiscard Do not attempt to discard blocks at mkfs time. This is the default. == -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f5d9ead.1040...@je-eigen-domein.nl
Re: TRIM support for ext4
On 03/12/2012 07:58 AM, Floris Bos / Maxnet wrote: On 03/12/2012 07:51 AM, Joey Hess wrote: Floris Bos / Maxnet wrote: In addition to that, it would also be nice if the -E discard option is passed to mkfs.ext4, so that it TRIMs the entire disk partition prior to creating the file system structures. -E discard is the default, according to mkfs.ext4(8) Not the most clear man page... On the (Ubuntu) version I have on my desktop, it also says nodiscard is the default?! Hmm, and to make things more complicated. The RELEASE-NOTES that come with the e2fsprogs source say that the default is what you put in mke2fs.conf == Mke2fs now understands the extended option discard and nodiscard, and the older option -K is deprecated. The default of whether discards are enabled by default can be controled by the mke2fs.conf file. == Still does not explain what behaviour you get when neither discard nor nodiscard is listed in that file... *sigh* -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f5da356.1040...@je-eigen-domein.nl
Re: TRIM support for ext4
On 03/12/2012 01:04 AM, Miguel Figueiredo wrote: Add the mount option 'discard' for ext4 filesystems so, during partitioning, TRIM can be activated for SSDs in the installed system. I assume the patch only adds discard as mount option to /etc/fstab? In addition to that, it would also be nice if the -E discard option is passed to mkfs.ext4, so that it TRIMs the entire disk partition prior to creating the file system structures. -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f5d8189.9040...@je-eigen-domein.nl
Re: About using static config with pxeboot/preseed
Hi, On 11.10.2011 17:17, Julien Escario wrote: I'm trying to configure full automated install. The server is booting over pxe, get his dhcp lease and retrieve the preseed file over http. Preseeding is working well but not for the net config : ip address, hostname, ... After reboot, dhcp is still used and hostname is 'debian'. Is this a normal behaviour ? No way to use DHCP to get the address for d-i and install the server with a static address ? Yeah, we noticed that as well. In our provisioning software (noc-ps) we simply work around that by not specifying the configuration in the preseed file, but feeding a static network configuration through kernel parameters: == netcfg/disable_dhcp=true netcfg/get_ipaddress=$ip netcfg/get_netmask=$netmask netcfg/get_gateway=$gateway == Regarding hostname: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606636 Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e36b997e4ed5237f50a929d256850...@to-the-max.net
Preseed setting to ignore valid-until in release file?
Hi, Currently, if you create a local (stale) mirror of the Debian installation files, and use that to perform PXE network installations for your local servers it will works fine initially. However after some days, new installations hang with a red Cannot access repository error. The log virtual terminal shows: in-target: E: Release file expired. So it seems to be caused by the Valid-Until line that is at http://ftp.debian.org/debian/dists/squeeze-updates/Release Is there any setting that can be used to tell the installer that I do not care that the files used are old? -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201108172211.53000@je-eigen-domein.nl
Bug#495042: debian-installer: add iscsi root installation
Hi,
Bumping an old feature request.
On Thursday, August 14, 2008 09:42:31 AM you wrote:
Add iscsi root installation feature to debian installer.
I was wondering if there were any plans to add this?
Did experiment a bit with it myself, and it's not that much work to simply
detect the iSCSI settings set in the BIOS/boot firmware, and connect to the
iSCSI target automatically, like CentOS and Windows do.
See the attached (unpolished) patches as a starting point of a way this can be
done.
In short what is necessary is:
- check for the presence of an iBFT table in memory. This can be done by
loading the iscsi_ibft kernel module and checking /sys.
Since it only scans a memory region and does not do any more agressive
probing, it's safe to load by default.
- if found, it means iSCSI is configured on the computer and the other iscsi
kernel modules should be loaded. As well as an udeb with the open-scsi
usermode tools that are responsible for setting up the connection. Calling
iscsistart -b is enough to automatically connect to the target using the
information found in the iBFT and attach the disks.
- make sure open-iscsi is added to the packages to be installed, and that a
initramfs with iscsi support is created, so that the system will start after
reboot.
--
Yours sincerely,
Floris Bos
diff -ur hw-detect-1.87.orig/debian/disk-detect.templates hw-detect-1.87/debian/disk-detect.templates
--- hw-detect-1.87.orig/debian/disk-detect.templates 2011-06-23 21:57:17.0 +0200
+++ hw-detect-1.87/debian/disk-detect.templates 2011-07-13 01:10:41.0 +0200
@@ -42,3 +42,13 @@
Description: for internal use; can be preseeded
Check for the presence of multipath devices?
+Template: disk-detect/iscsi_connect
+Type: text
+# :sl2:
+_Description: Connecting to iSCSI target
+
+Template: disk-detect/iscsi_error
+Type: error
+# :sl2:
+_Description: Error connecting to iSCSI target (using the login information found in the iBFT)
+
diff -ur hw-detect-1.87.orig/disk-detect.sh hw-detect-1.87/disk-detect.sh
--- hw-detect-1.87.orig/disk-detect.sh 2011-06-23 21:57:17.0 +0200
+++ hw-detect-1.87/disk-detect.sh 2011-07-13 01:24:09.0 +0200
@@ -120,10 +120,31 @@
fi
}
+iscsi_probe() {
+
+ log Looking for iSCSI iBFT table...
+ modprobe iscsi_ibft || true
+
+ if [ -e /sys/firmware/ibft/target0 ]; then
+ anna-install open-iscsi-udeb
+ modprobe iscsi_tcp
+ db_progress START 0 1 disk-detect/iscsi_connect
+ iscsistart -b || db_input high disk-detect/iscsi_error
+ db_progress STOP
+ apt-install open-iscsi || true
+ else
+ log No iSCSI iBFT table found, not loading iSCSI package
+ fi
+
+ return 0
+}
+
if ! hw-detect disk-detect/detect_progress_title; then
log hw-detect exited nonzero
fi
+iscsi_probe
+
while ! disk_found; do
CHOICES=
for mod in $(list_disk_modules | sort); do
diff -ur kernel-wedge-2.77.orig/modules/scsi-modules kernel-wedge-2.77/modules/scsi-modules
--- kernel-wedge-2.77.orig/modules/scsi-modules 2011-03-12 19:38:58.0 +0100
+++ kernel-wedge-2.77/modules/scsi-modules 2011-07-11 20:03:03.0 +0200
@@ -26,3 +26,5 @@
aic94xx ?
stex ?
xen-blkfront ?
+iscsi_tcp ?
+iscsi_ibft ?
diff -urN open-iscsi-2.0.871.3.orig/debian/control open-iscsi-2.0.871.3/debian/control
--- open-iscsi-2.0.871.3.orig/debian/control 2011-05-02 20:52:46.0 +0200
+++ open-iscsi-2.0.871.3/debian/control 2011-07-11 19:31:03.0 +0200
@@ -28,6 +28,15 @@
The userspace component consists of a daemon, iscsid and a management
utility, iscsiadm
+Package: open-iscsi-udeb
+Architecture: any
+Section: debian-installer
+XC-Package-Type: udeb
+Depends: ${shlibs:Depends}, ${misc:Depends}, scsi-modules, libnss-files-udeb
+Description: Open-iSCSI initiator
+ .
+ For use by debian-installer.
+
#Package: linux-iscsi-modules-source
#Architecture: all
#Depends: ${shlibs:Depends}, ${misc:Depends}, module-assistant, debhelper (= 4.0.0), bzip2
diff -urN open-iscsi-2.0.871.3.orig/debian/extra/initramfs.hook open-iscsi-2.0.871.3/debian/extra/initramfs.hook
--- open-iscsi-2.0.871.3.orig/debian/extra/initramfs.hook 2011-05-02 20:52:46.0 +0200
+++ open-iscsi-2.0.871.3/debian/extra/initramfs.hook 2011-07-13 01:02:57.0 +0200
@@ -26,6 +26,6 @@
cp /etc/iscsi/initiatorname.iscsi $DESTDIR/etc
cp /etc/iscsi/iscsi.initramfs $DESTDIR/etc
-for x in crc32c libcrc32c iscsi_tcp libiscsi scsi_transport_iscsi; do
+for x in crc32c libcrc32c iscsi_tcp iscsi_ibft libiscsi scsi_transport_iscsi; do
manual_add_modules ${x}
done
diff -urN open-iscsi-2.0.871.3.orig/debian/open-iscsi-udeb.dirs open-iscsi-2.0.871.3/debian/open-iscsi-udeb.dirs
--- open-iscsi-2.0.871.3.orig/debian/open-iscsi-udeb.dirs 1970-01-01 01:00:00.0 +0100
+++ open-iscsi-2.0.871.3/debian/open-iscsi-udeb.dirs 2011-07-11 23:20:22.0 +0200
@@ -0,0 +1,5 @@
+usr/bin
+usr/sbin
+var/lib/open-iscsi
+usr/lib/finish-install.d
+etc/iscsi
diff -urN open-iscsi-2.0.871.3.orig/debian/open-iscsi
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-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103011638.19111@je-eigen-domein.nl
Re: Link up wait timeout [was: Bug#537271: netcfg: new version of gateway reachability patch]
On Wednesday, February 09, 2011 12:00:29 pm Otavio Salvador wrote: On Wed, Feb 9, 2011 at 09:57, Matthew Palmer mpal...@debian.org wrote: Sure, there's no penalty is link-up occurs, but what about all the people for whom link-up doesn't occur -- say, because they're on a wireless link, or their chipset doesn't work right, or it's trying on a link that isn't actually up? Every delay screws them over more and more. It seems we have a trade-off here. I think the decision depends on the number of affected users: I think the decision should depend on the consequences instead. The consequence of a longer wait is just that. You have a few seconds wasted, if link detection does not work properly on your hardware. The consequence of a not long enough wait, is that Debian will simply fail to install over the network. I think the wait time may be longer on the newer generation of power efficient switches that power off ports that are not in use. Takes 3 full seconds here in practice (HP 2410G rackmount switch). -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102091237.52185.i...@je-eigen-domein.nl
Bug#537271: closed by Matthew Palmer mpal...@debian.org
On Monday, February 07, 2011 06:00:40 am Matthew Palmer wrote: Also, busybox patches should be put into a separate bug report which blocks this one, to keep things clear. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606654 - Busybox should include arping applet Regarding IPv6: I see there is already a bug for building a ndisc6-udeb: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611330 but it seems the idea is to put only rdisc6 in there: == I've now discovered that I need the rdisc6 tool as well as rdnssd, so the attached patch now builds an ndisc6-udeb containing just the rdisc6 binary. == Would it be possible to include the ndisc6 binary as well, and use that in the same way as arping? -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102071257.14763@je-eigen-domein.nl
Bug#562122: Improve preseeding of network device to use
Bumping an old bug. I've preseeded netcfg/choose_interface to auto, to try and avoid the netcfg/choose_interface question being asked. What I suspect is the problem, is the wireless interface is showing link so the question still gets asked. My thoughts on how to extend this functionality was: allow preseeding the interface to use based on: 1) vendor component of the MAC 2) PCI ID 3) some substring of the interface description because preseeding the specific interface by name is a non-starter, due to the way Linux can't consistently enumerate the interfaces. I think that at least selection of the network interface by MAC-address instead of interface name should be possible. There is currently a patch pending for Ubuntu: http://launchpadlibrarian.net/60443113/S31pxedust (belonging to bug https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/56679 ) Any chance of getting this into Debian as well? -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101301624.13189@je-eigen-domein.nl
Re: suggestion for reliable boot: disk-by-id
Hi, On Saturday, January 15, 2011 12:50:14 am Andre Felipe Machado wrote: Given the recent d-i RC announcemen snippet use of unique filesystem identifiers and labels for more reliable booting. I suggest to use disk-by-id instead of disk-label, because they give even more reliable boots at high end machines with high end storages, as explained reasons on [0]. I disagree with using disk-by-id. - It can prevent your system from booting on when you replace your disk controller/mainboard. - Causes problems when converting physical servers to virtual machines. - And is incompatible with the virtual KVM rescue systems dedicated server providers offer to their customers to diagnose boot problems. -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101151543.23034.i...@je-eigen-domein.nl
Re: suggestion for reliable boot: disk-by-id
Hi, On Sunday, January 16, 2011 01:24:15 am Andre Felipe Machado wrote: Regarding problem nr 3, we decided to use XenServer, that also uses disk by id, afaik. But for who uses kvm it could be an issue. With virtual KVM rescue systems I mean setups like: Hetzner's vKVM: http://wiki.hetzner.de/index.php/VKVM_en OVH's vKVM: http://www.ovh.co.uk/items/virtual_kvm.xml And our own software: http://www.noc-ps.com/index.php/documentation/virtual_kvm/ In which a regular dedicated server that normally does not use any virtualization, is network booted into a virtual environement temporarily, to repair boot and firewall problems, or manually install an operating system remotely. Works fine with Linux systems that mount by uuid, since that is a file system attribute, and is the same in both the virtual and real environement. Does not work with Linux distro's that use disk-by-id because in the virtual environement the disk-by-id will be /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_scsi0-hd0 instead of the hard disk name/serial that is used in the real enviroment. Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101160309.59220@je-eigen-domein.nl
Bug#542441: #542441 Re: old LVM data is not erased
Hi, This old bug is still present in Squeeze, except that I have only seen it cause issues on systems with more than one disk. If there is a LVM volume on the 2nd disk that has a group name that is the same Debian wants to use, install fails with a red Volume group name already in use To reproduce on a (virtual) system with 2 disks: - install Debian. - swap the disks cables, so that disk 1 becomes disk 2. - try to install Debian again. I think Debian should remove the labels from ALL disks if I specify partman- lvm/device_remove_lvm. Or as an alternate solution pick a random volume group name by default, so there are not any conflicts. -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012260401.08370@je-eigen-domein.nl
Bug#537271: debian-installer: network may not be usable as soon as link is up
On Thursday, July 16, 2009 05:39:24 pm you wrote: the debian-installer seems to assume that the network is usable as soon as the link comes up, which may not be the case if the 802.1d spanning tree protocol is in use, in which case it can be up to ~30 seconds before the switch port will forward ethernet frames. i've noticed that trying to preseed a network install on a machine attached to an STP-enabled switch usually fails since as soon as the network link is up, d-i attempts to perform a reverse DNS lookup and fetch the preseed.cfg file via HTTP, both of which timeout and fail before the switch port the machine is attached to enters the forwarding state. a nice strategy to detect if the network is usable might be to send ARP requests for the default gateway's IP address and consider the network up only after the default gateway is reachable. it looks like there is a busybox version of the arping utility that could help accomplish this. Quick dirty workaround if enabling arping in busybox (or implementing the same in C in netcfg itself) is not an option, may also be to simply increase the number of ARP retries. echo 60 /proc/sys/net/ipv4/neigh/eth0/mcast_solicit -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012131946.46699@je-eigen-domein.nl
Re: boot parameter interface=auto can't adaptation the correct NIC
Hi,
On Monday, December 13, 2010 04:15:46 am Qin Bo wrote:
2010/12/10 Lennart Sorensen lsore...@csclub.uwaterloo.ca
Is this another case of a driver/NIC taking longer to get link up after
being enabled than the installer is willing to wait? I seem to recall
a bnx2 user a few days ago reporting a similar problem.
How can i find the bnx2 problem? I had set netcfg/dhcp_timeout=60 as boot
parameter, the problem still reproduce.
But I still think the netcfg didn't got the correct interface, then
couldn't get the IP address from dhcp server.
Because I had read the netcfg source:netcfg.c netcfg-common.c, i can't find
where the program deal with interface=auto.
You need netcfg/choose_interface=auto
As far as the detection goes, it is this part in netcfg.c:
==
interface_up(*ifaces);
usleep(250);
if (ethtool_lite (*ifaces) == 1) /* CONNECTED */ {
di_info(found link on interface %s, making it the
default., *ifaces);
defiface = strdup(*ifaces);
interface_down(*ifaces);
break;
} else {
#ifdef WIRELESS
struct wireless_config wc;
#endif /* WIRELESS */
di_info(found no link on interface %s., *ifaces);
==
A 250 us delay is kinda short.
It takes 3 seconds for the link of my test box to get up.
(on-board Intel 82574L NIC, connected to a HP 1810G gigabit switch).
--
Yours sincerely,
Floris Bos
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201012130441.46315.i...@je-eigen-domein.nl
Bug#606515: Preseed installation does not wait for network to be ready
Hi,
Attached a patch to netcfg that waits for the link to come up before
proceeding.
It times out after 10 seconds, so if link detection is broken for some reason
it doesn't affect the install.
--
Yours sincerely,
Floris Bos
diff -ur netcfg.orig/Makefile netcfg/Makefile
--- netcfg.orig/Makefile 2009-10-28 21:37:37.0 +0100
+++ netcfg/Makefile 2010-12-11 20:51:10.362642461 +0100
@@ -26,7 +26,7 @@
all: $(TARGETS)
-netcfg-static: netcfg-static.o static.o
+netcfg-static: netcfg-static.o static.o ethtool-lite.o
netcfg: netcfg.o dhcp.o static.o ethtool-lite.o
$(TARGETS): $(COMMON_OBJS)
diff -ur netcfg.orig/netcfg.h netcfg/netcfg.h
--- netcfg.orig/netcfg.h 2010-09-06 23:53:19.0 +0200
+++ netcfg/netcfg.h 2010-12-11 20:10:50.761351395 +0100
@@ -41,6 +41,9 @@
ff02::1 ip6-allnodes\n \
ff02::2 ip6-allrouters\n
+/* Maximum number of seconds to wait for network link to come up */
+#define LINK_TIMEOUT 10
+
typedef enum { NOT_ASKED = 30, GO_BACK } response_t;
typedef enum { DHCP, STATIC, DUNNO } method_t;
typedef enum { ADHOC = 1, MANAGED = 2 } wifimode_t;
diff -ur netcfg.orig/static.c netcfg/static.c
--- netcfg.orig/static.c 2010-12-11 20:03:12.091975462 +0100
+++ netcfg/static.c 2010-12-11 20:49:30.851349894 +0100
@@ -269,10 +269,10 @@
int netcfg_activate_static(struct debconfclient *client)
{
-int rv = 0, masksize;
+int rv = 0, masksize, tries = 0;
char buf[256];
char ptr1[INET_ADDRSTRLEN];
-
+
#ifdef __GNU__
snprintf(buf, sizeof(buf),
settrans -fgap /servers/socket/2 /hurd/pfinet --interface=%s --address=%s,
@@ -381,6 +381,16 @@
debconf_capb(client, backup);
return -1;
}
+
+di_info(Waiting for the link of interface %s to come up, interface);
+
+do {
+usleep(10); /* sleep a tenth of a second */
+if (++tries LINK_TIMEOUT*10) {
+di_info(Link did not come up, but timeout expired, continuing...);
+break;
+}
+} while ( ethtool_lite(interface) == 2 /*DISCONNECTED*/ );
return 0;
}
Bug#606636: Reverse DNS takes precedence over netcfg/get_hostname
On Saturday, December 11, 2010 07:31:48 am Christian PERRIER wrote:
Correct. Apparently, though, that behaviour didn't bother anybody
enough to look at current netcfg code and propose the needed patch
Fair enough.
Attached a patch that introduces a new netcfg/hostname option that -if set-
takes precedence over the RDNS/DHCP hostname
magic.
This patch has a dependency on my other bug/patch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606515 (Preseed
installation does not wait for network to be ready)
Because if netcfg/hostname is set, the reverse DNS check is skipped, and the
chance is higher that the installer attempts to fetch
the kickstart file before the network link is up running.
--
Yours sincerely,
Floris Bos
diff -ur netcfg.orig1/debian/netcfg-common.templates netcfg/debian/netcfg-common.templates
--- netcfg.orig1/debian/netcfg-common.templates 2009-09-12 16:13:23.0 +0200
+++ netcfg/debian/netcfg-common.templates 2010-12-11 17:20:01.361351304 +0100
@@ -105,6 +105,12 @@
administrator. If you are setting up your own home network, you can make
something up here.
+Template: netcfg/hostname
+Type: string
+Description: Hostname that can be preseeded.
+ .
+ If specified this disables the automatic detection of the hostname by netcfg.
+
Template: netcfg/invalid_hostname
Type: error
# :sl2:
diff -ur netcfg.orig1/dhcp.c netcfg/dhcp.c
--- netcfg.orig1/dhcp.c 2010-08-06 23:49:44.0 +0200
+++ netcfg/dhcp.c 2010-12-11 23:18:25.841977721 +0100
@@ -473,12 +473,19 @@
}
/*
- * Default to the hostname returned via DHCP, if any,
+ * If the netcfg/hostname preseed value is set use that
+ * Otherwise default to the hostname returned via DHCP, if any,
* otherwise to the requested DHCP hostname
* otherwise to the hostname found in DNS for the IP address
* of the interface
*/
-if (gethostname(buf, sizeof(buf)) == 0
+debconf_get(client, netcfg/hostname);
+if (!empty_str(client-value))
+{
+strncpy(buf, client-value, sizeof(buf));
+debconf_set(client, netcfg/get_hostname, buf);
+}
+else if (gethostname(buf, sizeof(buf)) == 0
!empty_str(buf)
strcmp(buf, (none))
verify_hostname(buf) == 0
diff -ur netcfg.orig1/static.c netcfg/static.c
--- netcfg.orig1/static.c 2010-08-06 06:32:41.0 +0200
+++ netcfg/static.c 2010-12-12 00:12:44.691551386 +0100
@@ -454,9 +464,28 @@
GET_GATEWAY : CONFIRM;
break;
case GET_HOSTNAME:
-seed_hostname_from_dns(client, ipaddress);
-state = (netcfg_get_hostname(client, netcfg/get_hostname, hostname, 1)) ?
-GET_NAMESERVERS : GET_DOMAIN;
+debconf_get(client, netcfg/hostname);
+if (!empty_str(client-value)) {
+/* Copy preseeded netcfg/hostname to hostname variable and netcfg/get_hostname */
+hostname = strdup(client-value);
+debconf_set(client, netcfg/get_hostname, hostname);
+
+/* FQDN? Then set domain */
+char *s = strchr(hostname, '.');
+if (s s[1] != '\0') {
+domain = strdup(s + 1);
+debconf_set(client, netcfg/get_domain, domain);
+have_domain = 1;
+*s = '\0';
+}
+state = GET_DOMAIN;
+
+} else {
+seed_hostname_from_dns(client, ipaddress);
+state = (netcfg_get_hostname(client, netcfg/get_hostname, hostname, 1)) ?
+GET_NAMESERVERS : GET_DOMAIN;
+}
+
break;
case GET_DOMAIN:
if (!have_domain) {
Bug#606636: Reverse DNS takes precedence over netcfg/get_hostname
Package: netcfg Version: 1.46 The value specified using netcfg/get_hostname seems to be ignored, if a reverse DNS entry is present for the IP-address of the server being installed. Seems to be a bit similar to this bug: http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=544513 (dhcp returned hostname take precedence on netcfg/get_hostname) Except in my case it seems the reverse DNS hostname is used, instead of the DHCP hostname. I think netcfg/get_hostname should take precendence over everything else. Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012101513.32125@je-eigen-domein.nl
Bug#606654: Busybox should include arping applet
Package: busybox-udeb Version: 1.10.2-2 I think the arping applet should be enabled in the Busybox build. It helps a great deal in debugging general network issues and could be helpful to create a solution for some other bugs like: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537271 (network may not be usable as soon as link is up) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606515 (Preseed installation does not wait for network to be ready) Yours sincerely, Floris Bos --- busybox-1.10.2/debian/config/config.udeb.orig 2010-12-10 16:13:59.0 +0100 +++ busybox-1.10.2/debian/config/config.udeb 2010-12-10 16:14:28.0 +0100 @@ -589,7 +589,7 @@ # CONFIG_FEATURE_PREFER_IPV4_ADDRESS is not set # CONFIG_VERBOSE_RESOLUTION_ERRORS is not set # CONFIG_ARP is not set -# CONFIG_ARPING is not set +CONFIG_ARPING=y # CONFIG_BRCTL is not set # CONFIG_FEATURE_BRCTL_FANCY is not set # CONFIG_DNSD is not set
Bug#606654: Busybox should include arping applet
Hi, On Friday, December 10, 2010 05:12:39 pm Ferenc Wagner wrote: Floris Bos b...@je-eigen-domein.nl writes: I think the arping applet should be enabled in the Busybox build. It helps a great deal in debugging general network issues and could be helpful to create a solution for some other bugs like: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537271 (network may not be usable as soon as link is up) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606515 (Preseed installation does not wait for network to be ready) Please read http://wiki.debian.org/DebianInstaller/FAQ#Q.3AWhyispingnotavailableinthede bugshell Roughly the same applies to arping. After all, you can cat /proc/net/arp to check whether the gateway has a complete entry. But wouldn't you need to initiate network communication before an entry in /proc/net/arp for the gateway appears? Right now PXE preseed installations are broken, making Debian unsuitable for use by dedicated server providers. The Debian installer does not wait for the network link to come up (can take about 3 seconds on some NICs connected to a standard Gigabit switch), nor does it take into account that it can take 30 seconds before network activity is possible in spanning tree configurations. A simply 1-line fix if we had arping might be executing between netcfg and network-preseed: arping -f -c 35 $GATEWAY_IP (wait until you get an ARP reply from the gateway, timeout after 35 seconds/tries). I don't think calling wget 35 times, and grepping /proc/net/arp is a clean alternative, just to save 4 KB of space. -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012101856.07223@je-eigen-domein.nl
Bug#606636: Reverse DNS takes precedence over netcfg/get_hostname
Hi, On Friday, December 10, 2010 05:17:15 pm Ferenc Wagner wrote: Floris Bos b...@je-eigen-domein.nl writes: The value specified using netcfg/get_hostname seems to be ignored, if a reverse DNS entry is present for the IP-address of the server being installed. [...] I think netcfg/get_hostname should take precendence over everything else. Half of the current behaviour is documented in http://d-i.alioth.debian.org/manual/en.i386/apbs04.html#preseed-network Maybe the idea was to enable skipping the question without specifying a fixed name. Well, if you think people rely on the current behavior because it's partial documented, then treat my bug report as a feature request for a preseed option to override this behavior. Not everyone has the power to change their own reverse DNS entries, or it might take time to process (send a request to the upstream provider that is responsible for the IP block, wait for them to process it, and reload the nameserver zonefile). And people like to be able to choose their own hostname. -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012102042.37085@je-eigen-domein.nl
Bug#606636: Reverse DNS takes precedence over netcfg/get_hostname
On Friday, December 10, 2010 09:53:42 pm Ferenc Wagner wrote: Not everyone has the power to change their own reverse DNS entries, or it might take time to process (send a request to the upstream provider that is responsible for the IP block, wait for them to process it, and reload the nameserver zonefile). And people like to be able to choose their own hostname. Yeah. Currently they can either 1. not preseed it but type in during installation, or 2. set it in the DNS records. Looks like it worked good enough till now. Guess it wasn't good enough 5 years ago either. :-) Seems my bug is a duplicate of: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343269 -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012102333.04654@je-eigen-domein.nl
Bug#606515: Preseed installation does not wait for network to be ready
Package: network-preseed Version: 1.41 We are experiencing problems automatically installing Debian Lenny on a number of dedicated servers using PXE and preseed. Our setup works correctly with some hardware configurations, while others give a Failed to retrieve the preconfiguration file error message. If we manually press Continue and tell Debian installer to fetch the preconfiguration file a second time from the menu, installation does work properly. I suspect the reason it does not work the first time is that Debian installer does not bother to wait before the network link is ready, before attempting to fetch the preconfiguration file. When I press alt-F4 and look at the messages it shows: == 23:15:29 main-menu[1624]: INFO: menu item 'network-preseed' selected 23:15:32 kernel: eth0: Link is up 1000 Mbps Full Duplex Flow control: none == So if I understand the messages correctly the network-preseed routine is executed 3 seconds before the link is actually up? We assign a static network configuration to the servers using boot parameters like this: == kernel http://INSTALL-SERVER/main/installer- amd64/current/images/netboot/debian-installer/amd64/linux netcfg/choose_interface=auto debian-installer/locale=en_US kbd- chooser/method=us console-keymaps-at/keymap=us netcfg/disable_dhcp=true netcfg/get_ipaddress=$ip netcfg/get_netmask=$netmask netcfg/get_gateway=$gateway netcfg/get_nameservers=127.0.0.1 netcfg/get_hostname=$hostname netcfg/get_domain= preseed/url=http://INSTALL- SERVER/kickstart.php/debian-preseed (where $ip $netmask $gateway and $hostname is filled in with the information of the server being provisioned) == KVM over IP screenshot of the error message: http://image.bayimg.com/gabigaade.jpg Screenshot of the messages: http://image.bayimg.com/gabihaade.jpg Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101209.10536@je-eigen-domein.nl
