IPs are not assigned for Hipersockets in DHCP mode

The usage of Hipersockets with DHCP is not very common (at least I only came across static hipersocket environments so far).
Please make sure that your system is in L2 mode, you may check the hipersocket NIC with lsqeth.
What is the underlying system - which Z or LinuxONE model is in use?
And which mode does the HMC run in (classic aka PR/SM or DPM)?
Which dhcp server is in use?
And do you have more logs to share (syslog / journalctl and nw services logs)?

------- Comment From <email address hidden> 2021-02-11 08:44 EDT-------
Thanks for the information Asha.
Can you append any logs? dmesg, journalctl or any DHCP related logs?
Do you have any information from the DHCP server? Logs? Network setup?
Do you have tcpdump data?

------- Comment From <email address hidden> 2021-02-12 07:04 EDT-------
I have set up an DHCP server and DHCP client over HiperSockets, both on Ubuntu 20.04.1 and it works just fine.

Please provide your config files for dhcp and netplan on server and client side.
Is the dhcp server also running on Ubuntu?

------- Comment From <email address hidden> 2021-02-16 11:49 EDT-------
This morning we had a debug session with Asha and team.

The first issues were configuration problems. For documentation purposes:
- By default HiperSockets channels (CHPIDs) are isolated network segments, you cannot communicate between devices on different CHPIDs
- By default HiperSockets cannot be used for communications between different CECs
Network planning needs to be done accordingly, a simple way is e.g. : 1 IP subnet <-> 1 HiperSockets channel

Then we reproduced the following issue:
DHCP server and DHCP client both connected to the same HS channel via Layer 3 interfaces.
Requests are sent out via broadcast (tcpdump on client),
server sends responses (seen in journalctl on server)
responses never reach the client (tcpdump on client).

Sankar will attach detailed debug information.

As mentioned, last Friday I was successfully running DHCP between Ubunut 20.04 server and client
via Layer 2 HiperSockets.

Today I reproduced with Layer3 HiperSockets and it failed.

Remember that for HiperSockets Layer3 needs to be used on all participating interfaces!! (OSA is different)

Analysis:
See the "Device Drivers, Features, and Commands" https://www.ibm.com/developerworks/linux/linux390/documentation_dev.html
Chapter "Required options for using dhcpcd with layer3"

There it states "Run the DHCP client with an option that instructs the DHCP server to broadcast its response to the
client." Unfortunately I did not find such an option for netplan dhcp.
Deprecated workaround: add "always-broadcast on;" to /etc/dhcp/dhcpd.conf on the server side
(I tried this with my LPARs and it worked.)

Recommended solution: Use layer2 HiperSockets, if you want to use DHCP on HiperSockets and have only Linux'es connected.
(By default z/OS only supports layer3 HiperSockets, so all endpoints need to be Layer 3 HiperSockets, if a z/OS is
attached to this network segment)

------- Comment (attachment only) From <email address hidden> 2021-02-17 01:15 EDT-------

------- Comment From <email address hidden> 2021-02-17 01:19 EDT-------
Comment on attachment 148055
DHCP client debug information

Yesterday SSC team had a debug session with Alexandra. I have attached the debug info of both server and client here.

Each file contains the debug information from M96 and S209B machines.

------- Comment From <email address hidden> 2021-02-17 03:43 EDT-------
For documentation: 'dhclient -B' is a way to turn on the required flag for Layer3 DHCP at the client side.

My Ubuntu 20.04.2 contains only isc-dhclient-4.4.1
Seems that isc-dhclient-4.4.2 is required for this option.

Using 'bootp-broadcast-always;' in a dhclient.conf file may be another option.

However: as mentioned above, I strongly recommend to use Layer2 interfaces for DHCP, if possible.

Thx Alexandra and Asha for digging deeply into that issue with the hipersocket environment.
So the initial reason was to use L3 because of potentially connecting to z/OS instances?

And yes, isc-dhcp-client is Ubuntu's (and I think also Debian's) preference (for quite some time).

I think using "bootp-broadcast-always" is a conf option that works at least down to 4.2.x (but possibly even earlier).
I understand that an arg for the client would be nicer.
Well, you mentioned that isc-dhclient-4.4.2 will probably ship with such an option that allows to instruct the DHCP server to broadcast the response back to the client?
May I ask where you've read that?
I'm asking because I found that 4.4.2 got just released end of January: https://www.isc.org/dhcp/
And the 21.04 feature freeze is on the 25th Feb, so there is a little chance to get that in.
But I couldn't find anything in the 4.4.2 tar ball about such an option (well, maybe it got simply delayed or so ...)

Btw. I guess the Device Drivers guides were recently moved to a new location (since the URL you pointed to didn't had the Ubuntu 20.04.1 version, that puzzled me a bit).
I think it's now at the 'IBM Knowledge Center' (and no longer on devWorks):
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaaf/lnz_r_ubuntu.html
the Ubuntu 20.04.1 flavor of the Device Drivers guide here:
https://www.ibm.com/support/knowledgecenter/linuxonibm/liaaf/lnz_r_u2004.html

And I totally agree to use interfaces in L2 mode whereever possible, especially when it comes to DHCP. And so far I only saw DHCP environments on Z in L2 mode, hence my surprise at the very beginning about the combination of DHCP / Hipersockets / L3.

------- Comment From <email address hidden> 2021-02-18 02:39 EDT-------
Hi Frank,
As for dhclient: Fedora33 ships isc-dhclient-4.4.2b1, and that has the option as part of the binary and described in the man page.

------- Comment From <email address hidden> 2021-02-18 02:54 EDT-------
(In reply to comment #18)
> Thx Alexandra and Asha for digging deeply into that issue with the
> hipersocket environment.
> So the initial reason was to use L3 because of potentially connecting to
> z/OS instances?
>
Yes, that is the one scenario where L3 HiperSockets with DHCP would be neccessary.
The other thing is that HiperSockets Linux interfaces default to L3, so they can potentially connect to z/OS. So even if no z/OS is around, people may use L3 HiperSockets just because it is the default.

@Asha, do you have a need to use L3 in your scenario? Will you ever connect to z/OS?

>
> And I totally agree to use interfaces in L2 mode whereever possible,
> especially when it comes to DHCP. And so far I only saw DHCP environments on
> Z in L2 mode, hence my surprise at the very beginning about the combination
> of DHCP / Hipersockets / L3.

Note that OSA L3 interfaces do have the same issue with DHCP. But there is no reason to use OSA L3 interfaces at all and they default to L2. So hopefully nobody cares about that.

Hi,
as [1] didn't list anything that sounds like the -B option that was discussed here I was wondering if this is really a case of our dhclient being not up to date.
I've found the option that Stephan referred to in Fedora, but it isn't from a recent upstream version.
It seems to be non-upstreamed Fedora Delta for quite a while [2][3][4].
Why it isn't upstreamed, I have no idea, but I wanted to share the links if anyone wants to give it a try for a Ubuntu package as it isn't too easy to find.

[1]: https://downloads.isc.org/isc/dhcp/4.4.2/dhcp-4.4.2-RELNOTES
[2]: https://src.fedoraproject.org/rpms/dhcp/blob/rawhide/f/0002-additional-dhclient-options.patch
[3]: https://src.fedoraproject.org/rpms/dhcp/blob/rawhide/f/0006-Various-man-page-only-fixes.patch
[4]: https://src.fedoraproject.org/rpms/dhcp/blob/rawhide/f/0026-Add-dhclient-5-B-option-description.patch

systemd-networkd has this option in systemd.network

RequestBroadcast=
           Request the server to use broadcast messages before the IP address has been
           configured. This is necessary for devices that cannot receive RAW packets, or
           that cannot receive packets at all before an IP address has been configured. On
           the other hand, this must not be enabled on networks where broadcasts are
           filtered out.

I wonder if in addition to netplan.yaml, one could manually create /etc/systemd/network/NETPLAN_GENERATED_NETWORK_NAME.network.d/ directory
and drop in there 30-request-broadcast.conf

[DHCPv4]
RequestBroadcast=yes

I wonder if that will make "everything work"

Note that indeed this will only work for installed systems to communicate with each other. This will not work from the initrd to netboot the installer (aka ip=dhcp url=http://url/to/server-live.iso).

I am slightly perplexed about this option. Is it possible to detect that interface is a hypersocket in L3? Shouldn't systemd-networkd default to RequestBroadcast=yes for such interfaces? Imho it would be not neat that one has to manually specify request-broadcast: true in netplan yaml.

For netplan yaml of:

network:
    version: 2
    ethernets:
        enc8f00:
            dhcp4: yes

It would be interesting to see if L3 dhcp starts to work if one does:

$ sudo mkdir -p /etc/systemd/network/10-netplan-enc8f00.network.d
$ cat <<EOF | sudo tee -a /etc/systemd/network/10-netplan-enc8f00.network.d/30-request-broadcast.conf
[DHCPv4]
RequestBroadcast=yes
EOF

$ sudo networkctl reconfigure enc8f00

(or chzdev -d 0.0.8f00; chzdev -e 0.0.8f00 or reboot, whatever is easier to make networkd force renew).

My preference would be to fix networkd, if that fails netplan, and isc-dhcp only if there is syntax to online the device in the right l2/l3 state via kernel cmdline and that one needs to complete install over it.

For example, does automatic chzdev device enablement provides autoconfiguration for hipersockets in l3? in that case it would be neat for ip=dhcp to just do the right thing.

Would turning on RequestBroadcast=yes for ID_NET_DRIVER=qeth_l3 interfaces be good enough in networkd?

------- Comment From <email address hidden> 2021-02-25 10:28 EDT-------
(In reply to comment #25)
> For netplan yaml of:
>
> network:
> version: 2
> ethernets:
> enc8f00:
> dhcp4: yes
>
> It would be interesting to see if L3 dhcp starts to work if one does:
>
> $ sudo mkdir -p /etc/systemd/network/10-netplan-enc8f00.network.d
> $ cat <<EOF | sudo tee -a
> /etc/systemd/network/10-netplan-enc8f00.network.d/30-request-broadcast.conf
> [DHCPv4]
> RequestBroadcast=yes
> EOF
>
> $ sudo networkctl reconfigure enc8f00
>
> (or chzdev -d 0.0.8f00; chzdev -e 0.0.8f00 or reboot, whatever is easier to
> make networkd force renew).

Thank you xnox. I confirm that this works with chzdev -d/-e and with reboot.
@Asha, this is a better solution for you.

------- Comment From <email address hidden> 2021-02-25 10:36 EDT-------
(In reply to comment #26)
> My preference would be to fix networkd, if that fails netplan, and isc-dhcp
> only if there is syntax to online the device in the right l2/l3 state via
> kernel cmdline and that one needs to complete install over it.
>
> For example, does automatic chzdev device enablement provides
> autoconfiguration for hipersockets in l3? in that case it would be neat for
> ip=dhcp to just do the right thing.
>
Yes, 'chzdev -e' defaults to Layer3 unless you explicitely specify 'chzdev -e layer2=1'. Note that chzdev creates a udev rule to make this setting persistent.

> Would turning on RequestBroadcast=yes for ID_NET_DRIVER=qeth_l3 interfaces
> be good enough in networkd?
Yes, that sounds good.

I've started drafting this patch.

I want to prepare a PPA for you to try, can you please let me know which Ubuntu release is best / easiest for you to test? Hirsute? Focal? Bionic?

Looking at the tags that were added by the BZ bridge (targetmilestone-inin2004), it's focal.

------- Comment From <email address hidden> 2021-03-01 02:53 EDT-------
This is the setup I use as DHCP client:
root@s83lp72:~# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

So if you can provide a fix for focal fossa (plus instructions how to install it), I can give it a try.

Default Comment by Bridge

I have made this PPA

https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4477

It has packages for focal versioned above current focal-updates version, but lower than the next SRU.

sudo add-apt-repository ppa:ci-train-ppa-service/4477
sudo apt install systemd

Should be enough to upgrade networkd. After that if you have installed network.d snippets you should remove them, and then reboot and things should just work. If reboot is too much doing chzdev -d / -e on the hipersocket interfaces that are in l3 should do the trick as well.

After testing you can downgrade / remove those packages with ppa-purge, or just leave them until next SRU update arrives.

If you can't use add-apt-repository (needs http(s) access to api.launchpad.net and ppa.launchpad.net) you can also download the .deb files from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4477/+build/21099271 and install them with $ sudo apt ./*.deb => do not it has to "absolute path names, or paths prefixed with ./" for apt to recognise them to install from local files instead of trying to fetch things from the mirror.

https://github.com/systemd/systemd/pull/18829

------- Comment From <email address hidden> 2021-03-01 12:00 EDT-------
Works like a charm, thank you xnox!

I tested L2 and L3 HiperSockets during reboot.
L2 got the IP@ via unicast reply
L3 got its IP@ via broadcast reply.

------- Comment From <email address hidden> 2021-03-17 08:12 EDT-------
IBM bugzilla status-> closed, workaround available, upstream activitiy by Canonical.

Since #18829 is now closed upstream:
https://github.com/systemd/systemd/pull/18829
this should be SRUed (at least to focal).

Hello bugproxy, or anyone else affected,

Accepted systemd into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/247.3-3ubuntu3.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted systemd (247.3-3ubuntu3.5) for hirsute have finished running.
The following regressions have been reported in tests triggered by the package:

systemd/247.3-3ubuntu3.5 (armhf)
munin/2.0.57-1ubuntu1 (amd64)
udisks2/2.9.2-1ubuntu1 (arm64)
initramfs-tools/0.139ubuntu3 (amd64)
swupdate/2020.11-2 (s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

So seeing comment #27, should we set Impish to 'Fix Released'?

Hello bugproxy, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.12 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Committed, but not released yet. The fix is in upstream v249, and cherry-picked in the version currently in -proposed, but I believe it got stuck because of the glibc transition?

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.12) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

flatpak/1.6.5-0ubuntu0.3 (amd64)
gvfs/1.44.1-1ubuntu1 (amd64, arm64)
munin/2.0.56-1ubuntu1 (s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Hello bugproxy, or anyone else affected,

Accepted systemd into hirsute-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/247.3-3ubuntu3.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-hirsute to verification-done-hirsute. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-hirsute. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Hello bugproxy, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.13 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted systemd (247.3-3ubuntu3.6) for hirsute have finished running.
The following regressions have been reported in tests triggered by the package:

udisks2/2.9.2-1ubuntu1 (arm64)
apt/2.2.4ubuntu0.1 (amd64)
systemd/247.3-3ubuntu3.6 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/hirsute/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.13) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.44.1-1ubuntu1 (amd64, ppc64el)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

I was able to verify this on focal in a little z/VM env. that I've setup (it's a little bit different to the setup that was used by the initial reporter, but close enough).
So I'm updating the focal tag.
(will then upgrade to hirsute and redo - sorry this way it's less work for me)

After upgrading my systems to hirsute I was able to successfully validate on hirsute, too.
Adjusting the tags accordingly ...

The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

This bug was fixed in the package systemd - 245.4-4ubuntu3.13

---------------
systemd (245.4-4ubuntu3.13) focal; urgency=medium

  * d/p/dell-clamshell-accel-location-base-with-sku.patch:
    Revert incorrect patch (LP: #1942899)

systemd (245.4-4ubuntu3.12) focal; urgency=medium

  [ Yao Wei ]
  * d/p/dell-clamshell-accel-location-base.patch:
    Add ACCEL_LOCATION=base property for Dell clamshell models (LP: #1938259)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=5c1be33900edee94da0dc9a4ade8edcd079b4c85

  [ Lukas Märdian ]
  * Add d/p/lp1934221-resolved-disable-event-sources-before-unreffing-them.patch
    - Fix segfault in systemd-resolve (LP: #1934221)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=6c401900c70962052f56c7108fdc02fe7f84c9bf

  [ Simon Chopin ]
  * d/p/lp1914740-network-enable-DHCP-broadcast-flag-if-required-by-in.patch:
    - Apply upstream patch to fix Hipersocket DHCP mode (LP: #1914740)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=326ae43b7966d9e7c5f7124027185a79a07fa276

  [ Dan Streetman ]
  * d/p/lp1934981-correct-suspend-then-sleep-string.patch:
    Fix sleep verb used by logind during suspend-then-hibernate
    (LP: #1934981)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=997f3a7da3d5db22e3c63626c3f7dc3dff0830b0
  * d/p/lp1937238-util-return-the-correct-correct-wd-from-inotify-help.patch:
    Fix watch for time sync (LP: #1937238)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=dbabff8a03eb232c19174eff1335cd7cb7d7860c
  * d/extra/dhclient-enter-resolved-hook:
    Reset start limit counter for systemd-resolved in dhclient hook
    (LP: #1939255)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=9d3a91a0b70a4b2bcc166f366cd0a880fd494812
  * d/p/lp1935051-shared-unit-file-make-sure-the-old-hashmaps-and-sets.patch:
    Fix memory leak in path cache (LP: #1935051)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=12d6bdeb35f309158fe8d4242c6dd9be4d067604
  * d/p/lp1934147/0001-cgroup-do-catchup-for-unit-cgroup-inotify-watch-file.patch,
    d/p/lp1934147/0002-core-Make-sure-cgroup_oom_queue-is-flushed-on-manage.patch:
    Catchup cgroup inotify watch after reexec/reload (LP: #1934147)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=63eabc88b8e0005eb40b15b543538ce35377bdbd

 -- Dan Streetman <email address hidden> Tue, 07 Sep 2021 14:37:22 -0400

This bug was fixed in the package systemd - 247.3-3ubuntu3.6

---------------
systemd (247.3-3ubuntu3.6) hirsute; urgency=medium

  * d/p/dell-clamshell-accel-location-base-with-sku.patch:
    Revert incorrect patch (LP: #1942899)

systemd (247.3-3ubuntu3.5) hirsute; urgency=medium

  [ Yao Wei ]
  * d/p/dell-clamshell-accel-location-base-with-sku.patch:
    Use SKU to identify Dell clamshell models for accelerometer properties
    (LP: #1938259)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a21edd743408b5603b0177e9c230c6d6b919e589

  [ Lukas Märdian ]
  * Add d/p/lp1934221-resolved-disable-event-sources-before-unreffing-them.patch
    - Fix segfault in systemd-resolve (LP: #1934221)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=55906c32bdfd862e454c0fce80c4e023de6c3b19

  [ Simon Chopin ]
  * d/p/lp1914740-network-enable-DHCP-broadcast-flag-if-required-by-in.patch:
    - Apply upstream patch to fix Hipersocket DHCP mode (LP: #1914740)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=c7559785d7d4efaaa899009bceeb9498e53342e5

  [ Dan Streetman ]
  * d/p/lp1934981-correct-suspend-then-sleep-string.patch:
    Fix sleep verb used by logind during suspend-then-hibernate
    (LP: #1934981)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=cf75bbb01a6e7e2516e2bbf541c8e84d0548359c
  * d/p/lp1934147/0001-cgroup-do-catchup-for-unit-cgroup-inotify-watch-file.patch,
    d/p/lp1934147/0002-core-Make-sure-cgroup_oom_queue-is-flushed-on-manage.patch:
    Catchup cgroup inotify watch after reexec/reload (LP: #1934147)
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=d34d104339065665fa64ccda72d07ba8e2b7e10f

 -- Dan Streetman <email address hidden> Tue, 07 Sep 2021 14:34:22 -0400

This bug was fixed in the package systemd - 248.3-1ubuntu7

---------------
systemd (248.3-1ubuntu7) impish; urgency=medium

  * d/tests/tests-in-lxd: suppress the cgroups v2 warning on stderr from
    lxd/lxc even more comprehensively until the snapd change required to
    do it nicely gets into a release.

 -- Michael Hudson-Doyle <email address hidden> Wed, 01 Sep 2021 19:21:58 +1200