I've tested the Noble and Oracular from -proposed and my feedback is
positive.
Oracular with initramfs-tools 0.142ubuntu34.1:
ubuntu@fabio-oracular-amd-vanilla:~$ sudo dpkg -l | grep initramfs-tools
ii initramfs-tools 0.142ubuntu34.1
all generic modular initramfs generator (automation)
ii initramfs-tools-bin 0.142ubuntu34.1
amd64 binaries used by initramfs-tools
ii initramfs-tools-core 0.142ubuntu34.1
all generic modular initramfs generator (core tools)
Results: After a long time attempting to boot, it fails to identify the
root disk (iscsi) and breaks into a initramfs shell
Full console output: https://pastebin.ubuntu.com/p/G5cHPdkjDb/
--
Noble with initramfs-tools 0.142ubuntu25.4:
ubuntu@fabio-noble-amd-vanilla:~$ sudo dpkg -l | grep initramfs-tools
ii initramfs-tools 0.142ubuntu25.4
all generic modular initramfs generator (automation)
ii initramfs-tools-bin 0.142ubuntu25.4
amd64 binaries used by initramfs-tools
ii initramfs-tools-core 0.142ubuntu25.4
all generic modular initramfs generator (core tools)
Results: After a long time attempting to boot, it fails to identify the
root disk (iscsi) and breaks into a initramfs shell
Full console output: https://pastebin.ubuntu.com/p/JCBqMq8hNZ/
--
Oracular with initramfs-tools 0.142ubuntu34.2:
ubuntu@fabio-oracular-amd-proposed-native-ipv6singlestack:~$ sudo dpkg -l |
grep initramfs-tools
ii initramfs-tools 0.142ubuntu34.2
all generic modular initramfs generator (automation)
ii initramfs-tools-bin 0.142ubuntu34.2
amd64 binaries used by initramfs-tools
ii initramfs-tools-core 0.142ubuntu34.2
all generic modular initramfs generator (core tools)
Results: Boots fine and quickly
Full console output: https://pastebin.ubuntu.com/p/QqC3nKXZb4/
--
Noble with initramfs-tools 0.142ubuntu25.5:
ubuntu@fabio-noble-amd-proposed-native-ipv6singlestack:~$ sudo dpkg -l | grep
initramfs-tools
ii initramfs-tools 0.142ubuntu25.5
all generic modular initramfs generator (automation)
ii initramfs-tools-bin 0.142ubuntu25.5
amd64 binaries used by initramfs-tools
ii initramfs-tools-core 0.142ubuntu25.5
all generic modular initramfs generator (core tools)
Results: Boots fine and quickly
https://pastebin.ubuntu.com/p/dkRpDxXqRb/
--
PS: The "UBSAN: shift-out-of-bounds" call trace (seen even in the
successful boots), is something completely unrelated and being addressed
by:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2097824
So it can be safely ignored.
I'm marking verification-done.
** Tags removed: verification-needed verification-needed-noble
verification-needed-oracular
** Tags added: verification-done verification-done-noble
verification-done-oracular
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/2091904
Title:
IPv6 iBFT boot runs into a timeout
Status in initramfs-tools package in Ubuntu:
Fix Released
Status in initramfs-tools source package in Noble:
Fix Committed
Status in initramfs-tools source package in Oracular:
Fix Committed
Bug description:
[ Impact ]
This bug affects IPv6 only networks in combination with booting from
iSCSI Boot Firmware Table (iBFT). In those setups, there is no DHCPv4
available. The initramfs will only try DHCPv4 and run into a timeout.
[ Test Plan ]
This setup was distilled down to test cases and the new qemu-net-iscsi
autopkgtest was added.
The test plan is to check that all autopkgtest were successful. In
addition testing this version in a cloud environment is possible.
[ Where problems could occur ]
The newly added code only increases the initrd by some bytes. The
changed code is around the network configuration in the initrd and can
influence network boot with iSCSI. Users with IPv6 in iBFT might still
want to have IPv4 configured. That should be done by the network
daemon of the installed system.
[ Original report ]
iSCSI Boot Firmware Table (iBFT) can provide the network configuration
that is needed to boot over iSCSI. The iBFT can contain IPv4 or IPv6
addresses. local-top/iscsi calls `configure_networking`. The default
behaviour of `configure_networking` is DHCPv4 on all available
interfaces (if ip= and ip6= are not set). If iBFT provides IPv6
addresses and no DHCPv4 server are running, `configure_networking`
will only try DHCPv4 and run into a timeout.
Placing the single line "ISCSI_AUTO=true" into
/etc/iscsi/iscsi.initramfs, or use the kernel boot line option
"iscsi_auto" will configure the network devices based on iBFT, but the
code in `local-top/iscsi` will assume that the addresses are IPv4.
dracut on the other hand has the kernel boot line parameters
`rd.iscsi.firmware=1` and `rd.iscsi.ibft` and `ibft` as option for the
`ip` parameter. The `ibft` option is a bit under documented.
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/installation_guide/chap-
anaconda-boot-options mentions `ip=ibft` and dracut.cmdline mentions
it.
There are multiple ways to address the timeout with IPv6 iBFT:
1) Extend `local-top/iscsi` to differentiate between IPv4 and IPv6
when "iscsi_auto" is used. This information needs to be passed to
`configure_networking` to only try to bring up that device and
protocol.
2) Use `ip=ibft` as indicator to use ibft as source for the network
configuration. If no ip= parameter is set, local-top/iscsi should
default to ip=ibft when calling configure_networking.
Both solutions require passing data to configure_networking.
Requiring the user to set `ip=off ip6=on` is not a good user
experience and not a solution in my opinion.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2091904/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
