Public bug reported:

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.

** Affects: initramfs-tools (Ubuntu)
     Importance: Undecided
         Status: New

** Affects: open-iscsi (Ubuntu)
     Importance: Undecided
         Status: New

** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
       Status: New

** Description changed:

  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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2091904

Title:
  IPv6 iBFT boot runs into a timeout

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2091904/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to