Re: IMPORTANT: Do live Debian images have a future?
On 06/27/2017 11:53 PM, Michael . wrote: > Charles, let me clear up a couple of misconceptions for you. Debian Live > (made with Live Wrapper) is an official Debian project. Live Build (the > old Debian Live) apparently wasn't official but was recognised by Debian > for its official images. Live Build is now officially part of Debian Hum... You also have some misunderstanding here. Live-build has been packaged in Debian, and fully part of Debian for *years* (well before Raphael worked on it). What changed is that, since Daniel Baumann doesn't build the live images anymore (let's not go into details why this happened), Steve does it at the same time as other Debian images. It's now included in a single process of building images. Cheers, Thomas Goirand (zigo)
Re: IMPORTANT: Do live Debian images have a future?
On 07/05/2017 07:00 AM, Michael . wrote: > Thomas it is all fine and good to say "(lets not go into details why > this happened)" but the details support the reality of the situation. > Please read (https://lists.debian.org/debian-live/2015/11/msg8.html) > and see where Iain says > >>>It is worth noting that live-build is not a Debian project, it is an > external project that claims to be an official Debian project. This is > something that needs to be fixed. > > My understanding come from the people who initiated the take over of > building live images. If I am wrong then so was Iain and you should have > been a part of the discussion back in November 2015 to clear it all up > for us. > > I want Live-Wrapper to succeed (only because it is the official Debian > Live system) and I support it through testing it and reporting on things > I have found which would limit the audience who could use it but I also > want Live-Build to continue (because Live-Build is more suitable for a > roll your own images that derivatives would create). > > I must admit I am concerned about this reluctance "to go into details". > This type of thing keeps people in the dark and that is something I do > not support. There is no need to go over all the details but at least > provide proof as I have done. > > On 5 July 2017 at 08:34, Thomas Goirand <mailto:tho...@goirand.fr>> wrote: > > On 06/27/2017 11:53 PM, Michael . wrote: > > Charles, let me clear up a couple of misconceptions for you. Debian Live > > (made with Live Wrapper) is an official Debian project. Live Build (the > > old Debian Live) apparently wasn't official but was recognised by Debian > > for its official images. Live Build is now officially part of Debian > > Hum... You also have some misunderstanding here. Live-build has been > packaged in Debian, and fully part of Debian for *years* (well before > Raphael worked on it). > > What changed is that, since Daniel Baumann doesn't build the live images > anymore (let's not go into details why this happened), Steve does it at > the same time as other Debian images. It's now included in a single > process of building images. > > Cheers, > > Thomas Goirand (zigo) Please don't top-post. No need to rehash. What you wrote was that live-build wasn't part of Debian, which was wrong. That's different from the produced live images (what you wrote above is right). In other words: live-build != live images. Cheers, Thomas Goirand (zigo)
Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory
Package: live-boot-initramfs-tools Version: 1:20170623 Severity: serious Hi, After booting a Stretch live image, I tried to upgrade it to Sid, and it fails with this error: update-initramfs: deferring update (trigger activated) cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory Removing the package live-boot-initramfs-tools before the upgrade isn't even a workaround, it continues to crash. I need this to be fixed ASAP, as I'm using Live to test OpenStack, and this is a major blocker to me. I probably will attempt to fix it myself and NMU the package with no delay if you're fine with that, however, I'd appreciate help here. Cheers, Thomas Goirand (zigo)
Bug#882769: More investigation
After some investigation, it appears that if I upgrade the Linux kernel package first, then the upgrade works, like this: sed -i s/stretch/sid/ /etc/apt/sources.list apt-get update apt-get install linux-image-amd64 apt-get dist-upgrade If I just do apt-get dist-upgrade, then the bug is triggered. So my idea is that probably, adding a versionned breaks: somewhere will fix the upgrade problem. Let's see if I can find out... Cheers, Thomas Goirand (zigo)
Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory
On 11/28/2017 10:07 AM, Raphael Hertzog wrote: > update-initramfs -u -v Here's the (end of) the output of the above command: Calling hook live live-boot: core filesystems devicesCopying module directory kernel/drivers/net (excluding appletalk arcnet bonding can dummy.ko hamradio hippi ifb.ko irda macvlan.ko macvtap.ko pcmcia sb1000.ko team tokenring tun.ko usb veth.ko wan wimax wireless xen-netback.ko) utils udev wget blockdev dns. Calling hook klibc-utils /usr/share/initramfs-tools/scripts/local-premount/ORDER ignored: not executable /usr/share/initramfs-tools/scripts/init-top/ORDER ignored: not executable /usr/share/initramfs-tools/scripts/init-bottom/ORDER ignored: not executable Building cpio /boot/initrd.img-4.9.0-4-amd64.new initramfs cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory I still don't see where to search... :/ Cheers, Thomas Goirand (zigo)
Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory
On 12/04/2017 10:50 AM, intrigeri wrote: > Hi, > > Thomas Goirand: >> After booting a Stretch live image, I tried to upgrade it to Sid, and >> it fails with this error: > > Upgrading a *Live* system from one version of Debian to the other is > arguably a corner case and this bug does not affect the usability of > live-boot in the vast majority of cases. My use case is to use live for the OpenStack CI, when I want to test with Sid and not stable. Probably not a lot of people do that, but it's still a use case. Do you know if it's possible to generate a Sid live system? > Besides, I would feel wrong > to see live-boot automatically removed from testing merely because of > this bug. So perhaps this could be demoted to severity:important? I don't mind much the severity, but I'd very much prefer if we found out how to fix! Currently, I still don't understand which script is the problem. Do you have any idea? Cheers, Thomas Goirand (zigo)
Re: Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory
On 12/04/2017 02:41 PM, Raphael Hertzog wrote: > Control: reassign -1 live-tools > > On Wed, 29 Nov 2017, Thomas Goirand wrote: >> Building cpio /boot/initrd.img-4.9.0-4-amd64.new initramfs >> cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory >> >> I still don't see where to search... :/ > > I guess that you have live-tools installed? > > I don't really know the purpose of this package but it does divert > update-initramfs and contains the problematic "cp" that generates > the message seen above. > > The live-tools package is a Recommends of live-config. Not sure > if it's get pulled automatically by live-build or not due to this. > > Cheers, Right, I see it now. In bin/live-update-initramfs line 76 (at least in the git), we can read: cp /boot/vmlinuz-* /lib/live/mount/medium/live/vmlinuz.new cp /boot/initrd.img-* /lib/live/mount/medium/live/initrd.img.new mv /lib/live/mount/medium/live/vmlinuz.new \ /lib/live/mount/medium/live/vmlinuz mv /lib/live/mount/medium/live/initrd.img.new \ /lib/live/mount/medium/live/initrd.img So that's the problematic code. Now, the shell script is supposed to handle multiple kernels, but it just fails to detect there's more than one: it just looks for the number of files matching /boot/initrd.img-*, and expects the same amount of /boot/vmlinuz-*. Though when upgrading the kernel, there's at some point more than one vmlinuz-* file, but only a single /boot/initrd.img-*, because the 2nd one hasn't been generated just yet. I'm currently writing a patch, and will send it to this bug report for review from you guys. Cheers, Thomas Goirand (zigo)
Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory
Hi,
Here's 2 patches to apply to the Git. The first one ACK the last NMU (I
did a debdiff and just applied the result), and the 2nd one is the
actual fix for this bug.
Could you please review the patch and let me know if you think it's ok,
apply to the git, and allow me to upload?
Cheers,
Thomas Goirand (zigo)
>From d8b192c4fee504c0334ee632bc0a631ae26ca0ec Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Mon, 4 Dec 2017 15:34:35 +0100
Subject: [PATCH 1/2] ACK nmu: 20151214+nmu1
---
debian/changelog | 16
debian/control| 2 ++
debian/live-tools.init| 6 --
debian/live-tools.service | 14 ++
debian/rules | 2 +-
5 files changed, 37 insertions(+), 3 deletions(-)
create mode 100644 debian/live-tools.service
diff --git a/debian/changelog b/debian/changelog
index cd25a7c..69a1b46 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+live-tools (1:20151214+nmu1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add a native live-tools.service unit (Closes: #796627)
+ * Add dh-systemd build-dependency and use "--with systemd" for above.
+ * Source /lib/lsb/init-functions in init script
+- fixes lintian warning: init.d-script-does-not-source-init-functions
+ which means if someone directly invokes the init script under
+ systemd then the systemd LSB hooks will redirect to systemctl.
+ * Add lsb-base dependency because of the above.
+ * Fix up path in init script to make it actually do something
+(/bin/live-media-eject -> /bin/live-medium-eject)
+Thanks to Felipe Sateler for spotting this.
+
+ -- Andreas Henriksson Thu, 09 Jun 2016 16:07:07 +0200
+
live-tools (1:20151214) unstable; urgency=medium
[ Carlos Zuferri ]
diff --git a/debian/control b/debian/control
index ea8d408..03983c6 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: Live Systems Maintainers
Uploaders: Iain R. Learmonth
Build-Depends:
debhelper (>= 9),
+ dh-systemd (>= 1.5),
Standards-Version: 3.9.6
Homepage: https://debian-live.alioth.debian.org/live-tools/
Vcs-Browser: http://anonscm.debian.org/cgit/debian-live/live-tools.git
@@ -13,6 +14,7 @@ Vcs-Git: http://anonscm.debian.org/git/debian-live/live-tools.git
Package: live-tools
Architecture: all
Depends:
+ lsb-base,
initramfs-tools,
${misc:Depends},
Suggests:
diff --git a/debian/live-tools.init b/debian/live-tools.init
index 1b22e35..3afc682 100644
--- a/debian/live-tools.init
+++ b/debian/live-tools.init
@@ -16,11 +16,13 @@
# X-Interactive: true
### END INIT INFO
+. /lib/lsb/init-functions
+
case "${1}" in
stop)
- if [ -e /bin/live-media-eject ]
+ if [ -e /bin/live-medium-eject ]
then
- /bin/live-media-eject ${@}
+ /bin/live-medium-eject ${@}
fi
;;
diff --git a/debian/live-tools.service b/debian/live-tools.service
new file mode 100644
index 000..53499b7
--- /dev/null
+++ b/debian/live-tools.service
@@ -0,0 +1,14 @@
+[Unit]
+Documentation=man:live-tools(7)
+Description=live-tools - System Support Scripts
+DefaultDependencies=no
+Before=shutdown.target
+Conflicts=shutdown.target
+
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStop=/bin/live-medium-eject
+
+[Install]
+WantedBy=multi-user.target
diff --git a/debian/rules b/debian/rules
index 1ef2425..5761e15 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,7 @@
#!/usr/bin/make -f
%:
- dh ${@} --parallel
+ dh ${@} --parallel --with systemd
override_dh_auto_install:
dh_auto_install
--
2.11.0
>From 47e1efc42f15f2ade829e7f84a12fe2cbf8eb669 Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Mon, 4 Dec 2017 15:34:08 +0100
Subject: [PATCH 2/2] Fix crashing update-initramfs when upgrading the live
system. (Closes: #882769).
---
bin/live-update-initramfs | 22 +++---
debian/changelog | 8
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/bin/live-update-initramfs b/bin/live-update-initramfs
index 3cdbed3..93dfdbd 100755
--- a/bin/live-update-initramfs
+++ b/bin/live-update-initramfs
@@ -63,21 +63,29 @@ case "${_READ_WRITE}" in
for _INITRD in /boot/initrd.img-*
do
_VERSION="$(basename ${_INITRD} | sed -e 's|initrd.img-||')"
-
-cp /boot/vmlinuz-${_VERSION} /lib/live/mount/medium/live/vmlinuz${_NUMBER}.new
cp /boot/initrd.img-${_VERSION} /lib/live/mount/medium/live/initrd${_NUMBER}.img.new
-
-mv /lib/live/mount/medium/live/vmlinuz${_NUMBER}.new /lib/live/mount/medium/live/vmlinuz${_NUMBER}
mv /lib/live/mount/medium/live/initrd${_NUMBER}.img.new /lib/live/mount/medium/live/initrd${_NUMBER}.img
-
_NUMBER="$((${_NUMBER} + 1))"
done
else
- cp /boot/vmlinuz-* /lib/live/mount/medium/live/vmlinuz.new
cp /boot/initrd.img-* /lib/live/mount/medium/live/initrd.img.new
+ mv /lib/live/mount/medium/live/initrd.img.new /lib/live/mount/medium/live/init
Bug#882769: Cannot upgrade from Stretch: cp: target '/lib/live/mount/medium/live/vmlinuz.new' is not a directory
On 12/05/2017 09:58 AM, Raphael Hertzog wrote: > On Mon, 04 Dec 2017, Thomas Goirand wrote: >> Could you please review the patch and let me know if you think it's ok, >> apply to the git, and allow me to upload? > > I think it's wrong because it handles vmlinuz/initrd separately. I pushed > what I think is a proper fix into git. Can you test the git version and > confirm that it works for you? > > (I attach the patch applied on top of the last NMU) > > Cheers, Hi Raphael, Thanks a lot for your work. I can confirm that the new version fixes the bug. I tried installing it before the dist-upgrade using dpkg -i, and also setting-up a Debian repository holding only this new version of live-tools. In both cases, the upgraded worked. Please get this new version of live-tools uploaded to Sid. Thanks a lot for your work. Cheers, Thomas Goirand (zigo)
Bug#934787: Please switch to Python 3
Source: live-wrapper Version: 0.10 Severity: important Hi, We're trying to remove Python 2.x from Bullseye. Please switch this package to Python 3. I had a quick look into it, and it does seem Py3 ready. Is there any blocker? Cheers, Thomas Goirand (zigo)
Bug#982155: PXE network booting looks broken to me: the initramfs doesn't attempt to wget my filesystem.squashfs
Source: live-boot Version: 1:20210122 Severity: grave Hi, Since the last upload of live-build and live-boot (ie: 1:20210122) to unstable the live image my script creates cannot be booted. After the network interfaces are up, the image is supposed to wget the filesystem.squashfs, but it does nothing, sitting idle and not even giving me a timeout or something. Also, I wonder how come live-build / live-boot were uploaded 14 days from the freeze, when no other upload were done during the development cycle of Bullseye. There's clearly room for improvement here. If anything has changed in the interface of live-build (which would be breaking me), then I'd like to find out what. If you do know how to help, please do! Also, did you try doing PXE booting of a live image with this version 1:20210122 ? Maybe you should... :) Thanks for maintaining live-build, Cheers, Thomas Goirand (zigo)
Bug#982155: Found the regression
Hi, After some investigation, it looks like the regression is in this script: 9990-select-eth-device.sh Indeed, when I replace it by the old version, then things work again. I'm investigating further to try to see where is the issue in this script, and hopefully will come back with a fix... Cheers, Thomas Goirand (zigo)
Bug#982155: Found the regression
Hi Steven, Thanks for such a quick reply. Indeed, your commit fixes the problem: I've tested it by hand-patching my initrd.img. I very much would love this to be uploaded ASAP. Cheers, Thomas Goirand (zigo)
Bug#986063: live-build wrongly setups security repository for Bullseye: bullseye/updates instead of bullseye-security
Package: live-build
Version: 1:20190311
Severity: grave
Hi,
In functions/sourcelist.sh line 88, one can read:
echo "deb ${PARENT_MIRROR_SECURITY} ${PARENT_DISTRIBUTION}/updates
${LB_PARENT_ARCHIVE_AREAS}" >> "${PARENT_LIST_FILE}"
echo "deb-src ${PARENT_MIRROR_SECURITY} ${PARENT_DISTRIBUTION}/updates
${LB_PARENT_ARCHIVE_AREAS}" >> "${PARENT_LIST_FILE}"
So, effectively, this makes it bullseye/updates when it really should be
bullseye-security. So these lines must be replaced by:
echo "deb ${PARENT_MIRROR_SECURITY} ${PARENT_DISTRIBUTION}-security
${LB_PARENT_ARCHIVE_AREAS}" >> "${PARENT_LIST_FILE}"
echo "deb-src ${PARENT_MIRROR_SECURITY} ${PARENT_DISTRIBUTION}-security
${LB_PARENT_ARCHIVE_AREAS}" >> "${PARENT_LIST_FILE}"
This makes live-build not useable for me, as I do setup the security
repositories, and "lb build" just fails on me because of this problem.
Probably, what should be done is something like this:
if [ ${PARENT_DISTRIBUTION} = "buster" ] || [ ${PARENT_DISTRIBUTION} =
"stretch" ] ; then
SEC_REPO="/updates"
else
SEC_REPO="-security"
fi
to keep a bit of backward compatibility. I'll let the current maintainers of
live-build decide...
Cheers,
Thomas Goirand (zigo)
Bug#986148: live-build uses stable-security/updates instead of stable-security
Package: live-build
Version: 1:20210329
Severity: important
Hi,
In upload of version 1:20210329, the file:
functions/sourcelist.sh
has line 91/92:
echo "deb ${PARENT_MIRROR_SECURITY} ${PARENT_DISTRIBUTION}-security/updates
${LB_PARENT_ARCHIVE_AREAS}" >> "${PARENT_LIST_FILE}"
echo "deb-src ${PARENT_MIRROR_SECURITY} ${PARENT_DISTRIBUTION}-security/updates
${LB_PARENT_ARCHIVE_AREAS}" >> "${PARENT_LIST_FILE}"
This is wrong, it should be ${PARENT_DISTRIBUTION}-security without the
lasting "/updates". It still works because Debian repositories have symlinks,
but Ansgar just confirmed what I thought: we shouldn't be using a lasting
/updates at the end. Please remove it.
Cheers,
Thomas Goirand (zigo)
Bug#1058927: live-build doesn't create tftpboot under arm64 and fails
Package: live-build Version: 1:20230502 Severity: important Hi, Under Bookworm, when doing lb build after lb config this way: lb config -b netboot [...] lb build fails to create the tftpboot folder, which it cleans when starting. As a result, lb build just fails with "tftpboot: no such file or directory" (something like that). I tried under Bookworm, not sure if this is also in Unstable. Note that I've seen this behavior only under arm64, not in x86. So something must be wrong under this arch... Cheers, Thomas Goirand (zigo)
Bug#1026224: [patch] live-build: Option "-b netboot" fails on arm64 architecture
Hi!
This simple patch fixes the issue. I tried opening an MR on Salsa but it
seems Salsa has some issues currently (going to the merge request page
after the push leads to an error 500-something).
Cheers,
Thomas Goirand (zigo)
diff --git a/scripts/build/binary_netboot b/scripts/build/binary_netboot
index c88bc6296..d74a118f2 100755
--- a/scripts/build/binary_netboot
+++ b/scripts/build/binary_netboot
@@ -50,6 +50,7 @@ ROOT_DIR=${LB_MODE}-live
mv binary ${ROOT_DIR}
mkdir binary.tmp
+mkdir -p tftpboot
mv ${ROOT_DIR} tftpboot binary.tmp
cd binary.tmp
Bug#1069048: live-boot fails to DHCP on all NICs with link up
Package: live-boot
Version: 1:20230131
Severity: important
Tags: patch
Hi,
The current behavior of live-boot is to search 5 times for network
interfaces with the carrier link up. On each run, as soon as there
is one interface with link up, the script will exit, leaving no time
for other NICs to be up in any eventual subsequent run.
This only works if:
- one is lucky
- if only the interfaces with DHCP have an actual ethernet link.
For cases where there is more than one interface with the link up,
but only one is connected to a DHCPd server, it is possible that it
will fail (depending which card will have the link first).
The attached patch changes the behavior: it makes sure that all cards
with a link that is up are reported in /conf/param.conf before
exiting, so that live-boot will try to get an IP address from
all cards with link up. Each card continues to have a 15 seconds
timeout (by default) to get the IP address from DHCP.
We've tested this patch in production, with such a case where it
was failing (ie: our 25Gbits/s cards were detected first, but were not
connected to a DHCP server, while the 1Gbits/s cards that were supposed
to be holding the network boot were never tried by live-boot). And
this patch fixed things for us.
Please merge this patch if you feel like it's correct. I also would
like to have it fixed in Stable if possible (once I have the approval
from the team).
Cheers,
Thomas Goirand (zigo)
P.S: If one would like to test it, the easiest way is to build a
Debian live the normal way, then unpack the ramdisk with cpio with
something like this:
zstdcat | | cpio -idmv
Then recompress like this:
find . | cpio --create --format='newc' | zstd >
If running an older version of Debian, replacing zstdcat by zcat and
zstd by "gzip -9" also works.
>From 899aa9e8625570137fc57c4ed675bcb090119ace Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Mon, 15 Apr 2024 15:40:46 +0200
Subject: [PATCH] Do DHCP on multiple interfaces
The current behavior of live-boot is to search 5 times for network
interfaces with the carrier link up. If there is more than one
interface, but only one is found during a run, then it currently
gives-up searching for other interfaces and exits.
This works if one is lucky, or if only the interfaces with DHCP
have an actual ethernet link. For cases where there is more than
one interface with the link up, but only one is connected to a
DHCPd server, it is possible that it will fail (depending which
card will have the link first).
This patch changes the behavior: it makes sure that all cards
with a link that is up are reported in /conf/param.conf before
exiting, so that live-boot will try to get an IP address from
all cards with link up. Each card continues to have a 15 seconds
timeout (by default) to get the IP address from DHCP.
---
components/9990-select-eth-device.sh | 68
1 file changed, 39 insertions(+), 29 deletions(-)
diff --git a/components/9990-select-eth-device.sh
b/components/9990-select-eth-device.sh
index b660a3d..719a234 100755
--- a/components/9990-select-eth-device.sh
+++ b/components/9990-select-eth-device.sh
@@ -93,46 +93,56 @@ Select_eth_device ()
fi
found_eth_dev=""
- while true
+ echo -n "Looking for a connected Ethernet interface."
+
+ for interface in $l_interfaces
do
- echo -n "Looking for a connected Ethernet interface ..."
+ # ATTR{carrier} is not set if this is not done
+ echo -n " $interface ?"
+ ipconfig -c none -d $interface -t 1 >/dev/null 2>&1
+ sleep 1
+ done
+
+ echo ''
+ for step in 1 2 3 4 5
+ do
for interface in $l_interfaces
do
- # ATTR{carrier} is not set if this is not done
- echo -n " $interface ?"
- ipconfig -c none -d $interface -t 1 >/dev/null 2>&1
- sleep 1
- done
-
- echo ''
+ # Skip the interface if it's already found.
+ IN_IT=no
+ for DEV in $found_eth_dev ; do
+ if [ "${DEV}" = "$interface" ] ; then
+ IN_IT=yes
+ fi
+ done
- for step in 1 2 3 4 5
- do
- for interface in $l_interfaces
- do
+ if [ "${IN_IT}" = "no" ] ; then
ip link set $interface up
carrier=$(cat /sys/class/net/$interface/carrier
\
2>/dev/null)
# l
Bug#1069048: All NICs tried with same retries and timeouts?
Hi Narcis, The current behavior is that live-boot will attempt DHCP from the first NIC that is detected with link up. Cheers, Thomas Goirand (zigo)
Bug#1069048: All NICs tried with same retries and timeouts?
Hi, With my patch, the first NIC that gets an IP address from DHCP will be used. All NICs will be tried one by one, with the default 15 seconds timeout. The order of NICs stays the same as before, as in: the first NIC that gets a link up will be tried first. So there's no regression possible. Cheers, Thomas Goirand (zigo)
Bug#1069048: All NICs tried with same retries and timeouts?
Hi, If there's 10 NICs with a working dhcpd, only one will be configured (the first one), so that the live OS can fetch the squashfs. The fact that all 10 NICs will be configured with an IP address depends on what you put in the live image. By default, I believe all will be configured when the system is up, but *not* at the squashfs wget phase. So, what I'm fixing with this patch, is just the pre-wget phase, so that it tries all NICs. When the first one succeeds, the scripts don't attempt to get DHCP from another NIC at this stage. That's not different from the past behavior though. I hope you understood and I explained well enough this time! :) Cheers, Thomas Goirand (zigo)
Bug#1069048: All NICs tried with same retries and timeouts?
Hi, Narcis Garcia wrote: > Could you review this patch for pre-wget phase, so it considers that a > NIC succeeds whet it acquires default gateway address? Checking if a NIC has a default gateway interface is not the right way to check if that nick should be in use. There are some configurations where it's ok that there would be *NO* default gateway. This is a perfectly valid DHCP setup. The only way to check if it worked, is simply what's done right now: check if dhclient gets an IP address. This part isn't even in the patch itself, the only thing that this patch does, is listing the cards with the link up, to pass it to the next step (ie: dhcp), which this patch doesn't touch (it's written properly already, and works with multiple network interface in the DEVICES= variable in /conf/param.conf). So there's IMO nothing more to do in this patch. Cheers, Thomas Goirand (zigo)
Bug#1069048: live-boot fails to DHCP on all NICs with link up
ping? If nobody really cares about this bug, would it be ok to NMU the fix to Unstable, so that I can later backport it to Bookworm? Cheers, Thomas Goirand (zigo)
Re: Comments on live-build, vmdebootstrap, bootstrap-vz, and live-wrapper
ure it's possible to do things with "lb build". It's also worse nothing that Ubuntu was (or still is?) using live-build for its official images. > Do EC2 eimages really need to be built in an EBS volume? Would it be > good enough to copy them there after, building in a loop file like > everything else until that moment? Well, it's been about a year I'm asking that someone tests the openstack images on EC2: http://cdimage.debian.org/cdimage/openstack/ IMO, they should "just work" out of the box. The jessie one though should only work on HVM though. Could someone really take the time to test? Cheers, Thomas Goirand (zigo)
Bug#1088638: bookworm-pu: package live-boot/1:20230131
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: live-b...@packages.debian.org
Control: affects -1 + src:live-boot
Dear stable release team,
[ Reason ]
I'd like to update live-boot to fix its PXE-booting process where,
currently in Bookworm, live-boot, when it reaches the phase where
it should do DHCP and fetch its squashfs over network, only attemps
DHCP on the first NIC that it detect has a link up.
[ Impact ]
tl;dr: my patch makes live-boot tries DHCP on each and every NIC
that has a link. Before the patch, live-boot instead miserably fails
to do DHCP. So if 2 NICs are connected, but only one has DHCP, it
may just fail if the one without DHCP is discovered first.
More in details with my production system example:
Let me describe our current use case where live-boot currently fails
in Bookworm.
We use a live Debian distribution (custom live image) that is booted
over PXE to install Debian. DHCP / PXE is only available only in the
first NIC (for us, a 1Gbits/s NIC, most of the time). The other 2
NICs (they are 25Gbits/s) are to be used in production. We do things
this way for security, to segretate networking for boot and production.
Unfortunately, if live-boot "sees" the 2x 25Gbits/s NIC first, before
the 1Gbits/s, it will attempt to do DHCP on them (well, in fact, one
of them), as they are connected (ie: they have a "link up"), and then
since they have no DHCP offer, live-boot will fail. It will never
attempt to do DHCP request on the 1Gbits/s NIC.
The patch that I'm proposing, we already use it in production. What
it does, is that with it, live-boot attempts to do DHCP on each and
every NIC that has a link, one by one. So in the above scenario, it
tries on the 2x25Gbits/s NICs (since they are discovered first), but
as it fails on them, live-boot will continue and try on the 1Gbits/s
NIC as well.
[ Tests ]
We've been patching our live systems ramdisk with the modified
components/9990-select-eth-device.sh script (uncompress the ramdisk,
replace the script with the new version, and recompress). This made
our servers magically boot-up, trying all NICs.
Doing this is painful, and has to be done manually after live-boot
builds its initrd. One cannot simply use a modified live-boot package
as live-boot is downloaded by live-build (from the provided URL in
the config file) when the live image is created. So it would be very
useful to have this fixed in stable, rather than pointing our users
how to fix...
[ Risks ]
The code is trivial and easy to understand (a simple bash script).
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
See attached diff file.
>From b3469874e91b0facdbf292e41c92bcec3d842dbb Mon Sep 17 00:00:00 2001
From: Thomas Goirand
Date: Thu, 28 Nov 2024 22:14:21 +0100
Subject: [PATCH] Do DHCP on multiple interfaces
---
components/9990-select-eth-device.sh | 68
debian/changelog | 7 +++
2 files changed, 46 insertions(+), 29 deletions(-)
diff --git a/components/9990-select-eth-device.sh
b/components/9990-select-eth-device.sh
index b660a3d..719a234 100755
--- a/components/9990-select-eth-device.sh
+++ b/components/9990-select-eth-device.sh
@@ -93,46 +93,56 @@ Select_eth_device ()
fi
found_eth_dev=""
- while true
+ echo -n "Looking for a connected Ethernet interface."
+
+ for interface in $l_interfaces
do
- echo -n "Looking for a connected Ethernet interface ..."
+ # ATTR{carrier} is not set if this is not done
+ echo -n " $interface ?"
+ ipconfig -c none -d $interface -t 1 >/dev/null 2>&1
+ sleep 1
+ done
+
+ echo ''
+ for step in 1 2 3 4 5
+ do
for interface in $l_interfaces
do
- # ATTR{carrier} is not set if this is not done
- echo -n " $interface ?"
- ipconfig -c none -d $interface -t 1 >/dev/null 2>&1
- sleep 1
- done
-
- echo ''
+ # Skip the interface if it's already found.
+ IN_IT=no
+ for DEV in $found_eth_dev ; do
+ if [ "${DEV}" = "$interface" ] ; then
+ IN_IT=yes
+ fi
+ done
- for step in 1 2 3 4 5
- do
- for interface in $l_interfaces
- do
+ if [ &qu
