| 2018-01-03 16:27:49 |
Richard Laager |
bug |
|
|
added bug |
| 2018-01-03 16:28:23 |
Richard Laager |
description |
I just noticed on my test VM of artful that zfs-import-cache.service does not have a ConditionPathExists=/etc/zfs/zpool.cache. Because of that, it fails on startup, since the cache file does not exist.
This line is being deleted by debian/patches/ubuntu-load-zfs-unconditionally.patch. This patch seems to exist per:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1672749
This patch still exists in bionic, so I assume it will be similarly broken.
If the goal of the patch is to load the module (and only that), I think it should create a third unit instead:
zfs-load-module.service
^^ runs modprobe-zfs
zfs-import-cache.service & zfs-import-scan.service
^^ per upstream minus modprobe plus Requires=zfs-load-module.service
I have tested this manually and it works. I can submit a package patch if this is the desired solution.
Interestingly, zfs-import-scan.service doesn't seem to have run at all. If run manually, it works. I had to give it a `systemctl enable zfs-import-scan.service` to create the Wants symlinks. Looking at the zfsutils-linux.postinst, I see the correct boilerplate from dh_systemd, so I'm not sure why this wasn't already done. Can anyone confirm or deny whether zfs-import-scan.service is enabled out-of-the-box on their system? |
I just noticed on my test VM of artful that zfs-import-cache.service does not have a ConditionPathExists=/etc/zfs/zpool.cache. Because of that, it fails on startup, since the cache file does not exist.
This line is being deleted by debian/patches/ubuntu-load-zfs-unconditionally.patch. This patch seems to exist per:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1672749
This patch still exists in bionic, so I assume it will be similarly broken.
If the goal of the patch is to load the module (and only that), I think it should create a third unit instead:
zfs-load-module.service
^^ runs modprobe zfs
zfs-import-cache.service & zfs-import-scan.service
^^ per upstream minus modprobe plus Requires=zfs-load-module.service
I have tested this manually and it works. I can submit a package patch if this is the desired solution.
Interestingly, zfs-import-scan.service doesn't seem to have run at all. If run manually, it works. I had to give it a `systemctl enable zfs-import-scan.service` to create the Wants symlinks. Looking at the zfsutils-linux.postinst, I see the correct boilerplate from dh_systemd, so I'm not sure why this wasn't already done. Can anyone confirm or deny whether zfs-import-scan.service is enabled out-of-the-box on their system? |
|
| 2018-01-03 16:28:52 |
Richard Laager |
description |
I just noticed on my test VM of artful that zfs-import-cache.service does not have a ConditionPathExists=/etc/zfs/zpool.cache. Because of that, it fails on startup, since the cache file does not exist.
This line is being deleted by debian/patches/ubuntu-load-zfs-unconditionally.patch. This patch seems to exist per:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1672749
This patch still exists in bionic, so I assume it will be similarly broken.
If the goal of the patch is to load the module (and only that), I think it should create a third unit instead:
zfs-load-module.service
^^ runs modprobe zfs
zfs-import-cache.service & zfs-import-scan.service
^^ per upstream minus modprobe plus Requires=zfs-load-module.service
I have tested this manually and it works. I can submit a package patch if this is the desired solution.
Interestingly, zfs-import-scan.service doesn't seem to have run at all. If run manually, it works. I had to give it a `systemctl enable zfs-import-scan.service` to create the Wants symlinks. Looking at the zfsutils-linux.postinst, I see the correct boilerplate from dh_systemd, so I'm not sure why this wasn't already done. Can anyone confirm or deny whether zfs-import-scan.service is enabled out-of-the-box on their system? |
I just noticed on my test VM of artful that zfs-import-cache.service does not have a ConditionPathExists=/etc/zfs/zpool.cache. Because of that, it fails on startup, since the cache file does not exist.
This line is being deleted by debian/patches/ubuntu-load-zfs-unconditionally.patch. This patch seems to exist per:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1672749
This patch still exists in bionic, so I assume it will be similarly broken.
If the goal of the patch is to load the module (and only that), I think it should create a third unit instead:
zfs-load-module.service
^^ runs modprobe zfs
zfs-import-cache.service & zfs-import-scan.service
^^ per upstream minus modprobe plus Requires=zfs-load-module.service
I have tested this manually and it works. I can submit a package patch if this is the desired solution.
Interestingly, before this change, zfs-import-scan.service wasn't starting. If started manually, it worked. I had to give it a `systemctl enable zfs-import-scan.service` to create the Wants symlinks. Looking at the zfsutils-linux.postinst, I see the correct boilerplate from dh_systemd, so I'm not sure why this wasn't already done. Can anyone confirm or deny whether zfs-import-scan.service is enabled out-of-the-box on their system? |
|
| 2018-01-03 16:31:07 |
Richard Laager |
description |
I just noticed on my test VM of artful that zfs-import-cache.service does not have a ConditionPathExists=/etc/zfs/zpool.cache. Because of that, it fails on startup, since the cache file does not exist.
This line is being deleted by debian/patches/ubuntu-load-zfs-unconditionally.patch. This patch seems to exist per:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1672749
This patch still exists in bionic, so I assume it will be similarly broken.
If the goal of the patch is to load the module (and only that), I think it should create a third unit instead:
zfs-load-module.service
^^ runs modprobe zfs
zfs-import-cache.service & zfs-import-scan.service
^^ per upstream minus modprobe plus Requires=zfs-load-module.service
I have tested this manually and it works. I can submit a package patch if this is the desired solution.
Interestingly, before this change, zfs-import-scan.service wasn't starting. If started manually, it worked. I had to give it a `systemctl enable zfs-import-scan.service` to create the Wants symlinks. Looking at the zfsutils-linux.postinst, I see the correct boilerplate from dh_systemd, so I'm not sure why this wasn't already done. Can anyone confirm or deny whether zfs-import-scan.service is enabled out-of-the-box on their system? |
I just noticed on my test VM of artful that zfs-import-cache.service does not have a ConditionPathExists=/etc/zfs/zpool.cache. Because of that, it fails on startup, since the cache file does not exist.
This line is being deleted by debian/patches/ubuntu-load-zfs-unconditionally.patch. This patch seems to exist per:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1672749
This patch still exists in bionic, so I assume it will be similarly broken.
If the goal of the patch is to load the module (and only that), I think it should create a third unit instead:
zfs-load-module.service
^^ runs modprobe zfs
zfs-import-cache.service & zfs-import-scan.service
^^ per upstream minus modprobe plus Requires=zfs-load-module.service
I have tested this manually and it works. I can submit a package patch if this is the desired solution.
Interestingly, before this change, zfs-import-scan.service wasn't starting. If started manually, it worked. I had to give it a `systemctl enable zfs-import-scan.service` to create the Wants symlinks. Looking at the zfsutils-linux.postinst, I see the correct boilerplate from dh_systemd, so I'm not sure why this wasn't already done. Can anyone confirm or deny whether zfs-import-scan.service is enabled out-of-the-box on their system?
Is the zfs-import-scan.service not starting actually the cause of the original bug? The design is that *either* zfs-import-cache.service or zfs-import-scan.service starts. They both call modprobe zfs. |
|
| 2018-01-23 17:55:01 |
Launchpad Janitor |
zfs-linux (Ubuntu): status |
New |
Confirmed |
|
| 2018-01-23 17:59:01 |
Scott Emmons |
tags |
|
artful bionic |
|
| 2018-02-28 21:57:15 |
Colin Ian King |
zfs-linux (Ubuntu): status |
Confirmed |
In Progress |
|
| 2018-02-28 21:57:16 |
Colin Ian King |
zfs-linux (Ubuntu): importance |
Undecided |
High |
|
| 2018-02-28 21:57:18 |
Colin Ian King |
zfs-linux (Ubuntu): assignee |
|
Colin Ian King (colin-king) |
|
| 2018-03-01 17:46:47 |
Scott Emmons |
bug |
|
|
added subscriber Netflix Engineering |
| 2018-03-02 13:22:00 |
Colin Ian King |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-03-02 13:22:00 |
Colin Ian King |
bug task added |
|
zfs-linux (Ubuntu Bionic) |
|
| 2018-03-02 13:22:00 |
Colin Ian King |
nominated for series |
|
Ubuntu Artful |
|
| 2018-03-02 13:22:00 |
Colin Ian King |
bug task added |
|
zfs-linux (Ubuntu Artful) |
|
| 2018-03-02 13:22:09 |
Colin Ian King |
zfs-linux (Ubuntu Artful): assignee |
|
Colin Ian King (colin-king) |
|
| 2018-03-02 13:22:11 |
Colin Ian King |
zfs-linux (Ubuntu Artful): importance |
Undecided |
High |
|
| 2018-03-02 13:22:13 |
Colin Ian King |
zfs-linux (Ubuntu Artful): status |
New |
In Progress |
|
| 2018-03-02 15:00:08 |
Launchpad Janitor |
zfs-linux (Ubuntu Bionic): status |
In Progress |
Fix Released |
|
| 2018-03-02 15:32:35 |
Colin Ian King |
description |
I just noticed on my test VM of artful that zfs-import-cache.service does not have a ConditionPathExists=/etc/zfs/zpool.cache. Because of that, it fails on startup, since the cache file does not exist.
This line is being deleted by debian/patches/ubuntu-load-zfs-unconditionally.patch. This patch seems to exist per:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1672749
This patch still exists in bionic, so I assume it will be similarly broken.
If the goal of the patch is to load the module (and only that), I think it should create a third unit instead:
zfs-load-module.service
^^ runs modprobe zfs
zfs-import-cache.service & zfs-import-scan.service
^^ per upstream minus modprobe plus Requires=zfs-load-module.service
I have tested this manually and it works. I can submit a package patch if this is the desired solution.
Interestingly, before this change, zfs-import-scan.service wasn't starting. If started manually, it worked. I had to give it a `systemctl enable zfs-import-scan.service` to create the Wants symlinks. Looking at the zfsutils-linux.postinst, I see the correct boilerplate from dh_systemd, so I'm not sure why this wasn't already done. Can anyone confirm or deny whether zfs-import-scan.service is enabled out-of-the-box on their system?
Is the zfs-import-scan.service not starting actually the cause of the original bug? The design is that *either* zfs-import-cache.service or zfs-import-scan.service starts. They both call modprobe zfs. |
== SRU Request, Artful ==
Enable ZFS module to be loaded without the broken ubuntu-load-zfs-unconditionally.patch.
== Fix ==
Add a new zfs-load-module.service script that modprobes the ZFS module and remove any hard coded module loading from zfs-import-cache.service & zfs-import-scan.service and make these latter scripts require the new zfs-load-module.service script. Also remove the now defunct ubuntu-load-zfs-unconditionally.patch as this will no longer be required.
== Testcase ==
On a clean VM, install with the fixed package, zfs should load automatically.
== Regression potential ==
ZFS module may not load if the changes are broken. However, testing proves this not to be the case.
--------------------
I just noticed on my test VM of artful that zfs-import-cache.service does not have a ConditionPathExists=/etc/zfs/zpool.cache. Because of that, it fails on startup, since the cache file does not exist.
This line is being deleted by debian/patches/ubuntu-load-zfs-unconditionally.patch. This patch seems to exist per:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1672749
This patch still exists in bionic, so I assume it will be similarly broken.
If the goal of the patch is to load the module (and only that), I think it should create a third unit instead:
zfs-load-module.service
^^ runs modprobe zfs
zfs-import-cache.service & zfs-import-scan.service
^^ per upstream minus modprobe plus Requires=zfs-load-module.service
I have tested this manually and it works. I can submit a package patch if this is the desired solution.
Interestingly, before this change, zfs-import-scan.service wasn't starting. If started manually, it worked. I had to give it a `systemctl enable zfs-import-scan.service` to create the Wants symlinks. Looking at the zfsutils-linux.postinst, I see the correct boilerplate from dh_systemd, so I'm not sure why this wasn't already done. Can anyone confirm or deny whether zfs-import-scan.service is enabled out-of-the-box on their system?
Is the zfs-import-scan.service not starting actually the cause of the original bug? The design is that *either* zfs-import-cache.service or zfs-import-scan.service starts. They both call modprobe zfs. |
|
| 2018-03-02 15:45:13 |
Colin Ian King |
bug |
|
|
added subscriber Canonical Kernel SRU Team |
| 2018-03-02 15:45:16 |
Colin Ian King |
removed subscriber Canonical Kernel SRU Team |
|
|
|
| 2018-03-02 15:45:28 |
Colin Ian King |
bug |
|
|
added subscriber Ubuntu SRU developers |
| 2018-03-12 13:55:55 |
Colin Ian King |
zfs-linux (Ubuntu Artful): status |
In Progress |
Fix Committed |
|
| 2018-03-12 17:01:13 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-03-12 17:01:16 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2018-03-12 22:06:26 |
Richard Laager |
tags |
artful bionic |
artful bionic verification-done-artful |
|
| 2018-03-21 01:01:39 |
Launchpad Janitor |
zfs-linux (Ubuntu Artful): status |
Fix Committed |
Fix Released |
|
| 2018-03-21 01:01:44 |
Chris Halse Rogers |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
