Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #70075 > unrolled thread

Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

Back to article view | Back to linux.debian.kernel

Contents

  Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Josh Triplett <josh@joshtriplett.org> - 2021-04-10 23:20 +0200
    Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Bastian Blank <waldi@debian.org> - 2021-04-10 23:30 +0200
      Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Josh Triplett <josh@joshtriplett.org> - 2021-04-11 01:00 +0200
        Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Ben Hutchings <ben@decadent.org.uk> - 2021-04-11 22:50 +0200
          Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Josh Triplett <josh@joshtriplett.org> - 2021-04-12 03:50 +0200
            Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Vincent Bernat <bernat@debian.org> - 2021-04-12 07:10 +0200
              Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Josh Triplett <josh@joshtriplett.org> - 2021-04-12 07:10 +0200
            Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Ben Hutchings <ben@decadent.org.uk> - 2021-04-12 23:30 +0200
              Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Josh Triplett <josh@joshtriplett.org> - 2021-04-13 00:10 +0200
              Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Bastian Blank <waldi@debian.org> - 2021-04-13 06:50 +0200
                Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Josh Triplett <josh@joshtriplett.org> - 2021-04-13 07:40 +0200
                  Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Bastian Blank <waldi@debian.org> - 2021-04-13 11:40 +0200
                    Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image Noah Meyerhans <noahm@debian.org> - 2021-04-13 21:20 +0200
    Processed: Re: Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in  cloud image "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-04-10 23:30 +0200
    Processed: Re: Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in  cloud image "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-04-11 22:50 +0200

#70075 — Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

Package: linux-image-cloud-amd64
Severity: wishlist
X-Debbugs-Cc: josh@joshtriplett.org

For cloud instances and VMs, it's helpful to be able to use ip=dhcp as a
minimal network configuration. Enabling this option will do nothing
unless the kernel command line includes ip=dhcp.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-cloud-amd64 depends on:
pn  linux-image-5.10.0-5-cloud-amd64  <none>

linux-image-cloud-amd64 recommends no packages.

linux-image-cloud-amd64 suggests no packages.

[toc] | [next] | [standalone]

#70076

Control: tag -1 wontfix

Hi

On Sat, Apr 10, 2021 at 02:11:06PM -0700, Josh Triplett wrote:
> For cloud instances and VMs, it's helpful to be able to use ip=dhcp as a
> minimal network configuration. Enabling this option will do nothing
> unless the kernel command line includes ip=dhcp.

We don't support initramfs-less boot.  So network configuration is done
by the initramfs.

Bastian

-- 
The best diplomat I know is a fully activated phaser bank.
		-- Scotty

[toc] | [prev] | [next] | [standalone]

#70078

On Sat, Apr 10, 2021 at 11:23:53PM +0200, Bastian Blank wrote:
> On Sat, Apr 10, 2021 at 02:11:06PM -0700, Josh Triplett wrote:
> > For cloud instances and VMs, it's helpful to be able to use ip=dhcp as a
> > minimal network configuration. Enabling this option will do nothing
> > unless the kernel command line includes ip=dhcp.
> 
> We don't support initramfs-less boot.

Whether you have an initramfs or not is orthogonal to DHCP
configuration. The kernel's built-in DHCP configuration works even if
you're not using a network filesystem as the root filesystem.

[toc] | [prev] | [next] | [standalone]

#70080

[Multipart message — attachments visible in raw view] — view raw

Control: reassign -1 initramfs-tools
Control: tag -1 - wontfix
Control: forcemerge 789067 -1

On Sat, 2021-04-10 at 15:36 -0700, Josh Triplett wrote:
> On Sat, Apr 10, 2021 at 11:23:53PM +0200, Bastian Blank wrote:
> > On Sat, Apr 10, 2021 at 02:11:06PM -0700, Josh Triplett wrote:
> > > For cloud instances and VMs, it's helpful to be able to use ip=dhcp as a
> > > minimal network configuration. Enabling this option will do nothing
> > > unless the kernel command line includes ip=dhcp.
> > 
> > We don't support initramfs-less boot.
> 
> Whether you have an initramfs or not is orthogonal to DHCP
> configuration. The kernel's built-in DHCP configuration works even if
> you're not using a network filesystem as the root filesystem.

The initramfs is supposed to take responsibility for handling all of
the legacy boot parameters.  Moving this to initramfs-tools and merging
it with the existing bug there.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.

[toc] | [prev] | [next] | [standalone]

#70081

On Sun, Apr 11, 2021 at 10:45:27PM +0200, Ben Hutchings wrote:
> Control: reassign -1 initramfs-tools
> Control: tag -1 - wontfix
> Control: forcemerge 789067 -1
> 
> On Sat, 2021-04-10 at 15:36 -0700, Josh Triplett wrote:
> > On Sat, Apr 10, 2021 at 11:23:53PM +0200, Bastian Blank wrote:
> > > On Sat, Apr 10, 2021 at 02:11:06PM -0700, Josh Triplett wrote:
> > > > For cloud instances and VMs, it's helpful to be able to use ip=dhcp as a
> > > > minimal network configuration. Enabling this option will do nothing
> > > > unless the kernel command line includes ip=dhcp.
> > > 
> > > We don't support initramfs-less boot.
> > 
> > Whether you have an initramfs or not is orthogonal to DHCP
> > configuration. The kernel's built-in DHCP configuration works even if
> > you're not using a network filesystem as the root filesystem.
> 
> The initramfs is supposed to take responsibility for handling all of
> the legacy boot parameters.  Moving this to initramfs-tools and merging
> it with the existing bug there.

That wouldn't actually solve the issue as reported. I was hoping
specifically for the in-kernel support.

I'd like to use this on a cloud instance that uses ext4 on NVMe, and
thus doesn't currently need an initramfs.

[toc] | [prev] | [next] | [standalone]

#70082

 ❦ 11 avril 2021 18:44 -07, Josh Triplett:

>> > Whether you have an initramfs or not is orthogonal to DHCP
>> > configuration. The kernel's built-in DHCP configuration works even if
>> > you're not using a network filesystem as the root filesystem.
>> 
>> The initramfs is supposed to take responsibility for handling all of
>> the legacy boot parameters.  Moving this to initramfs-tools and merging
>> it with the existing bug there.
>
> That wouldn't actually solve the issue as reported. I was hoping
> specifically for the in-kernel support.
>
> I'd like to use this on a cloud instance that uses ext4 on NVMe, and
> thus doesn't currently need an initramfs.

I think your concern is around making VM boot fast. I don't want to put
words in your mouth, but if I am correct, this may help your argument.
-- 
Water, taken in moderation cannot hurt anybody.
		-- Mark Twain

[toc] | [prev] | [next] | [standalone]

#70083

On Mon, Apr 12, 2021 at 07:00:31AM +0200, Vincent Bernat wrote:
>  ❦ 11 avril 2021 18:44 -07, Josh Triplett:
> 
> >> > Whether you have an initramfs or not is orthogonal to DHCP
> >> > configuration. The kernel's built-in DHCP configuration works even if
> >> > you're not using a network filesystem as the root filesystem.
> >> 
> >> The initramfs is supposed to take responsibility for handling all of
> >> the legacy boot parameters.  Moving this to initramfs-tools and merging
> >> it with the existing bug there.
> >
> > That wouldn't actually solve the issue as reported. I was hoping
> > specifically for the in-kernel support.
> >
> > I'd like to use this on a cloud instance that uses ext4 on NVMe, and
> > thus doesn't currently need an initramfs.
> 
> I think your concern is around making VM boot fast. I don't want to put
> words in your mouth, but if I am correct, this may help your argument.

That's true, yes. I'm currently booting cloud instances in a fraction of
a second, and this will help with that.

[toc] | [prev] | [next] | [standalone]

#70101

[Multipart message — attachments visible in raw view] — view raw

[Added Noah to cc.]

On Sun, 2021-04-11 at 18:44 -0700, Josh Triplett wrote:
> On Sun, Apr 11, 2021 at 10:45:27PM +0200, Ben Hutchings wrote:
> > Control: reassign -1 initramfs-tools
> > Control: tag -1 - wontfix
> > Control: forcemerge 789067 -1
> > 
> > On Sat, 2021-04-10 at 15:36 -0700, Josh Triplett wrote:
> > > On Sat, Apr 10, 2021 at 11:23:53PM +0200, Bastian Blank wrote:
> > > > On Sat, Apr 10, 2021 at 02:11:06PM -0700, Josh Triplett wrote:
> > > > > For cloud instances and VMs, it's helpful to be able to use
> > > > > ip=dhcp as a
> > > > > minimal network configuration. Enabling this option will do
> > > > > nothing
> > > > > unless the kernel command line includes ip=dhcp.
> > > > 
> > > > We don't support initramfs-less boot.
> > > 
> > > Whether you have an initramfs or not is orthogonal to DHCP
> > > configuration. The kernel's built-in DHCP configuration works
> > > even if
> > > you're not using a network filesystem as the root filesystem.
> > 
> > The initramfs is supposed to take responsibility for handling all
> > of
> > the legacy boot parameters.  Moving this to initramfs-tools and
> > merging
> > it with the existing bug there.
> 
> That wouldn't actually solve the issue as reported. I was hoping
> specifically for the in-kernel support.
> 
> I'd like to use this on a cloud instance that uses ext4 on NVMe, and
> thus doesn't currently need an initramfs.

I think I missed or forgot about that change when it happened.  I'm not
super happy about it, to be honest.  It's been half-assed in that the
cloud flavours still have a dependency on an initramfs builder, that
should be a Recommends if we really want to support non-initramfs
booting.  There's no documentation that explains when that should work.

Have you tried using tiny-initramfs?  Does that still significantly
slow down boot relative to not using an initramfs image?  If not,
perhaps we could consider making that the first alternative initramfs
builder for cloud images.  (Not before bullseye, of course.)

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed
                                                    - Carolyn Scheppner

[toc] | [prev] | [next] | [standalone]

#70102

On Mon, Apr 12, 2021 at 11:18:43PM +0200, Ben Hutchings wrote:
> On Sun, 2021-04-11 at 18:44 -0700, Josh Triplett wrote:
> > On Sun, Apr 11, 2021 at 10:45:27PM +0200, Ben Hutchings wrote:
> > That wouldn't actually solve the issue as reported. I was hoping
> > specifically for the in-kernel support.
> > 
> > I'd like to use this on a cloud instance that uses ext4 on NVMe, and
> > thus doesn't currently need an initramfs.
> 
> I think I missed or forgot about that change when it happened.  I'm not
> super happy about it, to be honest.  It's been half-assed in that the
> cloud flavours still have a dependency on an initramfs builder, that
> should be a Recommends if we really want to support non-initramfs
> booting.  There's no documentation that explains when that should work.

I didn't realize this would be an issue, and I *definitely* didn't
intend for this change to be a surprise. In this context, I was much
more concerned about boot speed than disk usage, and I was willing to
take what I could get.

I would be willing (after the release) to do more work to make this a
supported configuration, if you'd be willing to consider that. I'd love
to see initramfs-tools in Recommends, and I'd be happy to write
documentation for the Description that explains when it's required.

Something like this:

"""
This kernel package Recommends initramfs-tools. On cloud systems meeting
all of the following requirements, you can skip installing
initramfs-tools and boot without an initramfs:

- The root filesystem lives on an NVMe drive (no RAID, LVM, dm-crypt, or
  similar).
- The root filesystem uses ext4.
- The root filesystem is identified by PARTUUID or by device name.
- Required system components such as /usr are part of the root
  filesystem.
"""

Does that sound potentially reasonable?

> Have you tried using tiny-initramfs?  Does that still significantly
> slow down boot relative to not using an initramfs image?

This is the first time I've heard of tiny-initramfs.

I'm currently counting the milliseconds, and loading any initramfs at
all does substantially add to boot time, compared to not requiring an
initramfs; the kernel has to extract it into memory and mount it, and
the bootloader has to load it from disk.

- Josh Triplett

[toc] | [prev] | [next] | [standalone]

#70106

Hi

On Mon, Apr 12, 2021 at 11:18:43PM +0200, Ben Hutchings wrote:
> I think I missed or forgot about that change when it happened.  I'm not
> super happy about it, to be honest.  It's been half-assed in that the
> cloud flavours still have a dependency on an initramfs builder, that
> should be a Recommends if we really want to support non-initramfs
> booting.  There's no documentation that explains when that should work.

WTF?  Where was that discussed?

Bastian

-- 
There is an order of things in this universe.
		-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

[toc] | [prev] | [next] | [standalone]

#70107

On Tue, Apr 13, 2021 at 06:39:26AM +0200, Bastian Blank wrote:
> Where was that discussed?

It was discussed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947759
, with responses from both Ben and Noah.

[toc] | [prev] | [next] | [standalone]

#70110

On Mon, Apr 12, 2021 at 10:30:49PM -0700, Josh Triplett wrote:
> On Tue, Apr 13, 2021 at 06:39:26AM +0200, Bastian Blank wrote:
> > Where was that discussed?
> It was discussed in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947759
> , with responses from both Ben and Noah.

As this is incomplete at best, I intend to revert that change.

Otherwise it at least needs in addition:
- hyperv pci support (for nvme),
- hyperv block and
- virtio-scsi.

However this bug is about dhcp support.  If there is no network device
support available, how does it do dhcp?

Bastian

-- 
You can't evaluate a man by logic alone.
		-- McCoy, "I, Mudd", stardate 4513.3

[toc] | [prev] | [next] | [standalone]

#70125

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 13, 2021 at 11:36:11AM +0200, Bastian Blank wrote:
> > > Where was that discussed?
> > It was discussed in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947759
> > , with responses from both Ben and Noah.
> 
> As this is incomplete at best, I intend to revert that change.
> 
> Otherwise it at least needs in addition:
> - hyperv pci support (for nvme),
> - hyperv block and
> - virtio-scsi.

This should probably be discussed in depth outside of this bug, but I do
not think this is the right approach.  The kernel config changes have
been in place for over a year, and were merged only after discussion
both on salsa and the BTS.  They accomplish the desired effect, which is
to allow the cloud kernel to boot without an initrd on common cloud
instance types (specifically AWS Nitro instance types).  While this is
not the default behavior for any of our cloud images, it is simple for
users to enable it on derivative images if they can benefit from the
reduced boot time.

If we want to support initrd-less booting on instances aside from Nitro
instance types, that's great, and we should consider doing that.  That
would be much more beneficial to our users than reverting the change.

> However this bug is about dhcp support.  If there is no network device
> support available, how does it do dhcp?

I'd also argue that NIC drivers (in particular ena.ko, used on Nitro
instances) should be left configured as modules, even if we do want to
support initrd-less booting.  AWS publishes an out-of-tree variant of
the ENA driver that may be ahead of what's in the stable kernel tree,
and some users may have a need to run that.

noah

[toc] | [prev] | [next] | [standalone]

#70077 — Processed: Re: Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

Processing control commands:

> tag -1 wontfix
Bug #986741 [linux-image-cloud-amd64] Please enable CONFIG_IP_PNP_DHCP=y in cloud image
Added tag(s) wontfix.

-- 
986741: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986741
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#70079 — Processed: Re: Bug#986741: Please enable CONFIG_IP_PNP_DHCP=y in cloud image

Processing control commands:

> reassign -1 initramfs-tools
Bug #986741 [linux-image-cloud-amd64] Please enable CONFIG_IP_PNP_DHCP=y in cloud image
Bug reassigned from package 'linux-image-cloud-amd64' to 'initramfs-tools'.
Ignoring request to alter found versions of bug #986741 to the same values previously set
Ignoring request to alter fixed versions of bug #986741 to the same values previously set
> tag -1 - wontfix
Bug #986741 [initramfs-tools] Please enable CONFIG_IP_PNP_DHCP=y in cloud image
Removed tag(s) wontfix.
> forcemerge 789067 -1
Bug #789067 [initramfs-tools] initramfs-tools: if ip is specified on cmdline, networking should be brought up in initramfs
Bug #986741 [initramfs-tools] Please enable CONFIG_IP_PNP_DHCP=y in cloud image
Severity set to 'normal' from 'wishlist'
There is no source info for the package 'initramfs-tools' at version '0.103ubuntu15' with architecture ''
Unable to make a source version for version '0.103ubuntu15'
Marked as found in versions 0.103ubuntu15.
Merged 789067 986741

-- 
789067: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789067
986741: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986741
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web