1:46 p.m.
siosm reported a new issue against the project: `atomic-wg` that you are following:
``
When installing Fedora Atomic using the ISO, Anaconda will set the resume=... kernel
parameter if swap is available (most probably since
https://github.com/poncovka/anaconda/commit/07c8591b107c34f3825dfa2d2b20c...).
Booting such an install in QEMU/KVM will result in delays/timeouts. I will try to
reproduce this on bare metal.
Disabling this kernel parameter using "rpm-ostree ex kargs --delete=resume=..."
works as workaround.
Should we keep hibernation support enabled for atomic hosts?
I will try to look further into the specific reason those timeouts occur.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
2:08 p.m.
dustymabe added a new comment to an issue you are following:
``
hey @siosm - since f29 is almost out, can you try with f29 silverblue and see if the
problem is resolved?
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-29-20181016.n....
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
3:29 p.m.
walters added a new comment to an issue you are following:
``
I can reproduce this with F29AH using default partitioning.
(Also I notice we regressed to using ext4 for / - seems like we lost the installclass?)
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
3:31 p.m.
walters added a new comment to an issue you are following:
``
This is filed against atomic-wg so let's leave Silverblue out of this.
What Anaconda is doing here in hardcoding the `resume=` argument seems pretty broken to
me. Why would I want to enable hibernation on my servers?
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
4:25 p.m.
dustymabe added a new comment to an issue you are following:
``
This is filed against atomic-wg so let's leave Silverblue out of
this.
oops. I confused this with "atomic workstation", my fault.
What Anaconda is doing here in hardcoding the resume= argument seems
pretty broken to me. Why would I want to enable hibernation on my servers?
agree.. let's see what rabbit hole this leads me down.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
8:55 p.m.
dustymabe added a new comment to an issue you are following:
``
# installclass issue
(Also I notice we regressed to using ext4 for / - seems like we lost
the installclass?)
Yep that's definitely true. I see differing behavior (i.e. xfs by default on rootfs)
if I force the installclass by using the following in a kickstart:
```
%anaconda
installclass --name="Atomic Host"
%end
```
I opened https://pagure.io/atomic-wg/issue/514 for the installclass issue.
# resume= issue
however that doesn't fix the `resume=` issue. I suspect that is done for all fedora
now (related bz: [1206936](https://bugzilla.redhat.com/show_bug.cgi?id=1206936).
I'll test to see what happens on fedora-server.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
10:24 p.m.
dustymabe added a new comment to an issue you are following:
``
@walters
What Anaconda is doing here in hardcoding the resume= argument seems pretty broken to me.
Why would I want to enable hibernation on my servers?
I don't disagree, but I just checked and this was enabled in f28 too. So the
"timing out" is new functionality in f29. We don't see this issue on our
cloud images because we don't have swap on them so no `resume=/path/to/swap` gets
added by default.
I just checked and on fedora server we do get the `resume=` option on the kernel command
line (i.e it gets added for all fedora) but I don't notice the delay timeout that I do
on Atomic Host:
Atomic Host
```
[root@localhost ~]# journalctl | grep swap
Oct 17 23:04:11 localhost kernel: Command line:
BOOT_IMAGE=/ostree/fedora-atomic-8f228e830fca568a137305e295ef96bafa0d08b0e27aa8c133a3bd24fff07280/vmlinuz-4.18.12-300.fc29.x86_64
resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap
root=/dev/mapper/fedora-root
ostree=/ostree/boot.0/fedora-atomic/8f228e830fca568a137305e295ef96bafa0d08b0e27aa8c133a3bd24fff07280/0
Oct 17 23:04:11 localhost kernel: Kernel command line:
BOOT_IMAGE=/ostree/fedora-atomic-8f228e830fca568a137305e295ef96bafa0d08b0e27aa8c133a3bd24fff07280/vmlinuz-4.18.12-300.fc29.x86_64
resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap
root=/dev/mapper/fedora-root
ostree=/ostree/boot.0/fedora-atomic/8f228e830fca568a137305e295ef96bafa0d08b0e27aa8c133a3bd24fff07280/0
Oct 17 23:04:11 localhost kernel: zswap: loaded using pool lzo/zbud
Oct 17 23:04:11 localhost dracut-cmdline[204]: Using kernel command line parameters:
BOOT_IMAGE=/ostree/fedora-atomic-8f228e830fca568a137305e295ef96bafa0d08b0e27aa8c133a3bd24fff07280/vmlinuz-4.18.12-300.fc29.x86_64
resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap
root=/dev/mapper/fedora-root
ostree=/ostree/boot.0/fedora-atomic/8f228e830fca568a137305e295ef96bafa0d08b0e27aa8c133a3bd24fff07280/0
Oct 17 23:05:41 localhost systemd[1]: dev-mapper-fedora\x2dswap.device: Job
dev-mapper-fedora\x2dswap.device/start timed out.
Oct 17 23:05:41 localhost systemd[1]: Timed out waiting for device
dev-mapper-fedora\x2dswap.device.
Oct 17 23:05:41 localhost systemd[1]: Dependency failed for Resume from hibernation using
device /dev/mapper/fedora-swap.
Oct 17 23:05:41 localhost systemd[1]:
systemd-hibernate-resume(a)dev-mapper-fedora\x2dswap.service: Job
systemd-hibernate-resume(a)dev-mapper-fedora\x2dswap.service/start failed with result
'dependency'.
Oct 17 23:05:41 localhost systemd[1]: dev-mapper-fedora\x2dswap.device: Job
dev-mapper-fedora\x2dswap.device/start failed with result 'timeout'.
Oct 17 23:05:41 localhost dracut-initqueue[484]: Scanning devices sda2 for LVM logical
volumes fedora/root fedora/swap
Oct 17 23:05:41 localhost dracut-initqueue[484]: inactive '/dev/fedora/swap' [1.50
GiB] inherit
Oct 17 23:05:43 localhost.localdomain kernel: Adding 1572860k swap on
/dev/mapper/fedora-swap. Priority:-2 extents:1 across:1572860k FS
```
Fedora Server
```
[root@localhost ~]# journalctl | grep swap
Oct 17 22:46:45 localhost.localdomain kernel: Command line:
BOOT_IMAGE=/vmlinuz-4.18.14-300.fc29.x86_64 root=/dev/mapper/fedora-root ro
resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet
LANG=en_US.UTF-8
Oct 17 22:46:45 localhost.localdomain kernel: Kernel command line:
BOOT_IMAGE=/vmlinuz-4.18.14-300.fc29.x86_64 root=/dev/mapper/fedora-root ro
resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet
LANG=en_US.UTF-8
Oct 17 22:46:45 localhost.localdomain kernel: zswap: loaded using pool lzo/zbud
Oct 17 22:46:45 localhost.localdomain dracut-cmdline[199]: Using kernel command line
parameters: BOOT_IMAGE=/vmlinuz-4.18.14-300.fc29.x86_64 root=/dev/mapper/fedora-root ro
resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet
LANG=en_US.UTF-8
Oct 17 22:46:45 localhost.localdomain dracut-initqueue[298]: Scanning devices vda2 for
LVM logical volumes fedora/root fedora/swap
Oct 17 22:46:45 localhost.localdomain dracut-initqueue[298]: inactive
'/dev/fedora/swap' [1.50 GiB] inherit
Oct 17 22:46:46 localhost.localdomain systemd[1]: Found device /dev/mapper/fedora-swap.
Oct 17 22:46:46 localhost.localdomain systemd[1]: Starting Resume from hibernation using
device /dev/mapper/fedora-swap...
Oct 17 22:46:46 localhost.localdomain systemd-hibernate-resume[395]: Could not resume from
'/dev/mapper/fedora-swap' (253:1).
Oct 17 22:46:46 localhost.localdomain systemd[1]: Started Resume from hibernation using
device /dev/mapper/fedora-swap.
Oct 17 22:46:46 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel
msg='unit=systemd-hibernate-resume@dev-mapper-fedora\x2dswap comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 17 22:46:46 localhost.localdomain audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295
ses=4294967295 subj=kernel
msg='unit=systemd-hibernate-resume@dev-mapper-fedora\x2dswap comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 17 22:46:47 localhost.localdomain kernel: Adding 1572860k swap on
/dev/mapper/fedora-swap. Priority:-2 extents:1 across:1572860k FS
```
On Atomic Host I'll highlight the dracut-initqueue message and also the timeout
error:
```
Oct 17 23:05:41 localhost systemd[1]: dev-mapper-fedora\x2dswap.device: Job
dev-mapper-fedora\x2dswap.device/start timed out.
Oct 17 23:05:41 localhost systemd[1]: Timed out waiting for device
dev-mapper-fedora\x2dswap.device.
Oct 17 23:05:41 localhost systemd[1]: Dependency failed for Resume from hibernation using
device /dev/mapper/fedora-swap.
...
...
Oct 17 23:05:41 localhost dracut-initqueue[484]: Scanning devices sda2 for LVM logical
volumes fedora/root fedora/swap
Oct 17 23:05:41 localhost dracut-initqueue[484]: inactive '/dev/fedora/swap' [1.50
GiB] inherit
```
And the same for Fedora Server
```
Oct 17 22:46:45 localhost.localdomain dracut-initqueue[298]: Scanning devices vda2 for
LVM logical volumes fedora/root fedora/swap
Oct 17 22:46:45 localhost.localdomain dracut-initqueue[298]: inactive
'/dev/fedora/swap' [1.50 GiB] inherit
Oct 17 22:47:55 localhost.localdomain systemd[1]: Found device /dev/mapper/fedora-swap.
Oct 17 22:47:55 localhost.localdomain systemd[1]: Starting Resume from hibernation using
device /dev/mapper/fedora-swap...
```
so it looks like something in dracut is causing LVM to get scanned early on Fedora Server,
but not on Atomic Host.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
10:30 p.m.
dustymabe added a new comment to an issue you are following:
``
@walters
What Anaconda is doing here in hardcoding the resume= argument seems pretty broken to me.
Why would I want to enable hibernation on my servers?
started a [devel list
discussion](https://lists.fedoraproject.org/archives/list/devel@lists.fed...
about this topic
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
1:04 p.m.
walters added a new comment to an issue you are following:
``
What changed in 29 might be the systemd hibernation implementation?
This also might be a server-side vs client-side initramfs thing. On classic systems,
/etc/fstab will end up in the initramfs. That's not true for ostree-based ones by
default.
That said Anaconda should be injecting the rd.lvm.lv bits on the kernel commandline and
wait till they're probed.
Ahh...I have an idea; ordinarily nothing else in the initramfs is waiting for devices; the
systemd fstab generator will handle /etc/fstab in the initramfs and make proper
device/mount units for them. But now the resume generator is going out and running before
dracut waits for devices or so?
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
1:35 p.m.
walters added a new comment to an issue you are following:
``
OK so I can definitely reproduce this if I tweak the current FCOS config/`image.ks` to use
LVM and have a swap partition.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
1:45 p.m.
dustymabe added a new comment to an issue you are following:
``
That said Anaconda should be injecting the rd.lvm.lv bits on the
kernel commandline and wait till they're probed.
I definitely see them on the command line
```
Oct 17 23:04:11 localhost kernel: Command line:
BOOT_IMAGE=/ostree/fedora-atomic-8f228e830fca568a137305e295ef96bafa0d08b0e27aa8c133a3bd24fff07280/vmlinuz-4.18.12-300.fc29.x86_64
resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap
root=/dev/mapper/fedora-root
ostree=/ostree/boot.0/fedora-atomic/8f228e830fca568a137305e295ef96bafa0d08b0e27aa8c133a3bd24fff07280/0
```
Ahh...I have an idea; ordinarily nothing else in the initramfs is
waiting for devices; the systemd fstab generator will handle /etc/fstab in the initramfs
and make proper device/mount units for them. But now the resume generator is going out
and running before dracut waits for devices or so?
yeah that seems to be the case at least from my log output in
https://pagure.io/atomic-wg/issue/513#comment-536727
OK so I can definitely reproduce this if I tweak the current FCOS
config/image.ks to use LVM and have a swap partition.
+1.. I'll dig into dracut a bit. Maybe we just disable
`systemd-hibernate-resume.service` on ostree systems for now, but there might be some
people on silverblue that want it. Not sure.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
2:30 p.m.
walters added a new comment to an issue you are following:
``
My attempts to remove the systemd generator weren't enough; I eventually discovered
there's also a `/usr/lib/dracut/modules.d/95resume` that parses the `resume=` kernel
command line. But nuking that still doesn't seem to be enough.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
2:59 p.m.
walters added a new comment to an issue you are following:
``
Here's what I have now, but it still times out. Removing the `resume=` kernel command
line argument fixes it. I can't figure out what else is parsing it.
```
diff --git a/fedora-coreos-base.yaml b/fedora-coreos-base.yaml
index db3e42c..89bc4f8 100644
--- a/fedora-coreos-base.yaml
+++ b/fedora-coreos-base.yaml
@@ -106,6 +106,14 @@ postprocess:
enable coreos-growpart.service
EOF
+ # https://pagure.io/atomic-wg/issue/513
+ sed -i '/ConditionKernelCommandLine.*resume/d'
/usr/lib/dracut/modules.d/98dracut-systemd/dracut-cmdline.service
+ rm -rf /usr/lib/dracut/modules.d/95resume
+ rm -vf /usr/lib/systemd/system/systemd-hibernate*.service \
+ /usr/lib/systemd/system/systemd-hibernate \
+ /usr/lib/systemd/systemd-hibernate-resume \
+ /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator
+
# Let's have a non-boring motd, just like CL (although theirs is more subdued
# nowadays compared to early versions with ASCII art). One thing we do here
# is add --- as a "separator"; the idea is that any "dynamic"
information should
diff --git a/image.ks b/image.ks
index 34df026..3efc9cc 100644
--- a/image.ks
+++ b/image.ks
@@ -11,7 +11,7 @@
# coreos-assembler.
# This line is interpreted by coreos-virt-install
-#--coreos-virt-install-disk-size-gb: 8
+#--coreos-virt-install-disk-size-gb: 40
# We use this because Kickstart doesn't have a way to specify
# the *total* size of the disk.
text
@@ -32,6 +32,7 @@ network --bootproto=dhcp --onboot=on
zerombr
clearpart --initlabel --all
+
# Add the following to kernel boot args:
# - ip=dhcp # how to get network
# - rd.neednet=1 # tell dracut we need network
@@ -42,9 +43,12 @@ bootloader --timeout=1 --append="no_timer_check
console=ttyS0,115200n8 console=t
# See also coreos-growpart.service defined in fedora-coreos-base.yaml
# You can change this partition layout, but note that the `boot` and `root`
# filesystem labels are currently mandatory (they're interpreted by
coreos-assembler).
+part pv.01 --grow
+volgroup coreos pv.01
part /boot --size=300 --fstype="xfs" --label=boot
+logvol swap --name=swap --size=9000 --label=swap --vgname=coreos
# Note no reflinks for /boot since the bootloader may not understand them
-part / --size=3000 --fstype="xfs" --label=root --grow --mkfsoptions="-m
reflink=1"
+logvol / --name=root --size=3000 --fstype="xfs" --label=root --grow
--mkfsoptions="-m reflink=1" --vgname=coreos
reboot
diff --git a/fedora-coreos-base.yaml b/fedora-coreos-base.yaml
index db3e42c..89bc4f8 100644
--- a/fedora-coreos-base.yaml
+++ b/fedora-coreos-base.yaml
@@ -106,6 +106,14 @@ postprocess:
enable coreos-growpart.service
EOF
+ # https://pagure.io/atomic-wg/issue/513
+ sed -i '/ConditionKernelCommandLine.*resume/d'
/usr/lib/dracut/modules.d/98dracut-systemd/dracut-cmdline.service
+ rm -rf /usr/lib/dracut/modules.d/95resume
+ rm -vf /usr/lib/systemd/system/systemd-hibernate*.service \
+ /usr/lib/systemd/system/systemd-hibernate \
+ /usr/lib/systemd/systemd-hibernate-resume \
+ /usr/lib/systemd/system-generators/systemd-hibernate-resume-generator
+
# Let's have a non-boring motd, just like CL (although theirs is more subdued
# nowadays compared to early versions with ASCII art). One thing we do here
# is add --- as a "separator"; the idea is that any "dynamic"
information should
diff --git a/image.ks b/image.ks
index 34df026..3efc9cc 100644
--- a/image.ks
+++ b/image.ks
@@ -11,7 +11,7 @@
# coreos-assembler.
# This line is interpreted by coreos-virt-install
-#--coreos-virt-install-disk-size-gb: 8
+#--coreos-virt-install-disk-size-gb: 40
# We use this because Kickstart doesn't have a way to specify
# the *total* size of the disk.
text
@@ -32,6 +32,7 @@ network --bootproto=dhcp --onboot=on
zerombr
clearpart --initlabel --all
+
# Add the following to kernel boot args:
# - ip=dhcp # how to get network
# - rd.neednet=1 # tell dracut we need network
@@ -42,9 +43,12 @@ bootloader --timeout=1 --append="no_timer_check
console=ttyS0,115200n8 console=t
# See also coreos-growpart.service defined in fedora-coreos-base.yaml
# You can change this partition layout, but note that the `boot` and `root`
# filesystem labels are currently mandatory (they're interpreted by
coreos-assembler).
+part pv.01 --grow
+volgroup coreos pv.01
part /boot --size=300 --fstype="xfs" --label=boot
+logvol swap --name=swap --size=9000 --label=swap --vgname=coreos
# Note no reflinks for /boot since the bootloader may not understand them
-part / --size=3000 --fstype="xfs" --label=root --grow --mkfsoptions="-m
reflink=1"
+logvol / --name=root --size=3000 --fstype="xfs" --label=root --grow
--mkfsoptions="-m reflink=1" --vgname=coreos
reboot
```
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
4:21 p.m.
dustymabe added a new comment to an issue you are following:
``
i'm still poking at this. it's hurting my head as well
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
9:38 a.m.
walters added a new comment to an issue you are following:
``
Perhaps the more correct thing to do here is for Anaconda to have an API to disable its
automatic injection of `resume=`. I don't think we can do it in `%post` since that
happens before the bootloader, and we don't have an API to manipulate them there.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
9:42 a.m.
walters added a new comment to an issue you are following:
``
https://github.com/rhinstaller/anaconda/issues/1667
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
10:23 a.m.
dustymabe added a new comment to an issue you are following:
``
interestingly I just downloaded a [rawhide silverblue
image](https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-...
to test out https://pagure.io/pungi-fedora/pull-request/665 and noticed I did not hit this
issue. I then tried rawhide Atomic Host and did see the issue. So it doesn't appear to
affect silverblue (at least in rawhide).
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
10:46 a.m.
dustymabe added a new comment to an issue you are following:
``
and.. just confirmed I do not see this issue on f29 silverblue.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
1:29 p.m.
dustymabe added a new comment to an issue you are following:
``
ok i've managed to be able to convert the f29 silverblue system (the one that was not
showing the issue) into one that does show the issue.. here are my rough notes right
now:
```
rpm-ostree install dracut-network iscsi-initiator-utils
rpm-ostree initramfs --enable
reboot
```
I need to eat lunch. will pick this up after
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
4:07 p.m.
dustymabe added a new comment to an issue you are following:
``
ok since this problem was introduced in the f28 stream I decided to run an [rpm-ostree
bisect]() to see where it first started happening. The results probably won't surprise
you:
```
Starting RPM-OSTree Bisect Testing...
: Using data file at: /var/lib/rpm-ostree-bisect.json
: Did not find device timeout. Test Passes
: Removed /etc/systemd/system/multi-user.target.wants/rpm-ostree-bisect.service.
: BISECT TEST RESULTS:
: Last known good commit:
: 5736e83 : 28.20180708.0 : 2018-07-08T20:03:31Z
: First known bad commit:
: bc3aa17 : 28.20180711.0 : 2018-07-11T18:26:22Z
: libostree pull from 'fedora-atomic' for fedora/28/x86_64/atomic-host complete
security: GPG: commit http: TLS
non-delta: meta: 270 content: 0
transfer: secs: 43 size: 2.7 MB
: ostree diff commit old:
5736e832b1fd59208465458265136fbe2aa4ba89517d8bdcc91bc84724f40a8e
: ostree diff commit new:
bc3aa17a5ad6c04103563bd93c4c668996ef786ec04f989a3209a9887c8e982c
: Upgraded:
: acl 2.2.52-20.fc28 -> 2.2.53-1.fc28
: attr 2.4.47-23.fc28 -> 2.4.48-1.fc28
: dracut 047-8.git20180305.fc28 -> 048-1.fc28
: dracut-config-generic 047-8.git20180305.fc28 -> 048-1.fc28
: dracut-network 047-8.git20180305.fc28 -> 048-1.fc28
: kernel 4.17.3-200.fc28 -> 4.17.4-200.fc28
: kernel-core 4.17.3-200.fc28 -> 4.17.4-200.fc28
: kernel-modules 4.17.3-200.fc28 -> 4.17.4-200.fc28
: libacl 2.2.52-20.fc28 -> 2.2.53-1.fc28
: libattr 2.4.47-23.fc28 -> 2.4.48-1.fc28
: openldap 2.4.46-1.fc28 -> 2.4.46-2.fc28
: podman 0.6.5-1.git9d97bd6.fc28 -> 0.7.1-1.git802d4f2.fc28
: python3-pytoml 0.1.16-1.fc28 -> 0.1.17-1.fc28
: Removed:
: grubby-8.40-11.fc28.x86_64
: Added:
: libkcapi-1.1.1-1.fc28.x86_64
: libkcapi-hmaccalc-1.1.1-1.fc28.x86_64
Started RPM-OSTree Bisect Testing.
```
So with everything we've learned so far the problem is in the code in the
dracut-network rpm and introduced in dracut `048`. Also the smoking gun seems to be
somewhere in the iscsi module because when `iscsi-initiator-utils` isn't installed we
don't have the problem.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
4:11 p.m.
walters added a new comment to an issue you are following:
``
Ah. Fun. Thanks a lot for diving into this. Hmm...let's look at the source to those
modules.
Though I am feeling that the right approach here is to turn it off in Anaconda.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
4:23 p.m.
walters added a new comment to an issue you are following:
``
On the other hand, if we are needing to change this relatively sensitive part of Anaconda
now, maybe the right thing is to just mark it as a Known Issue for FAH29? If it
doesn't affect Silverblue since it's some dracut-network/iscsi hot mess then...eh.
Let's focus on FCOS?
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
1:38 p.m.
dustymabe added a new comment to an issue you are following:
``
passing this off to the dracut team: https://bugzilla.redhat.com/show_bug.cgi?id=1641268
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
8:23 a.m.
dustymabe added a new comment to an issue you are following:
``
The fix for this is now in the updates-testing. Please test the [updates testing
ISO](https://kojipkgs.fedoraproject.org/compose/updates/Fedora-29-updates...
and add karma in the [bodhi
update](https://bodhi.fedoraproject.org/updates/FEDORA-2018-cf5015ab11).
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
5:32 a.m.
siosm added a new comment to an issue you are following:
``
LGTM for FAH 29 but I have not yet tested if this does not break iscsi support.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
8:50 a.m.
dustymabe added a new comment to an issue you are following:
``
LGTM for FAH 29 but I have not yet tested if this does not break
iscsi support.
According to harald upstream the socket activation should be sufficient to not break
things, but please do report if you find issues.
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
2:14 p.m.
The status of the issue: `Hibernation enabled with ISO based installation` of project:
`atomic-wg` has been updated to: Closed as Fixed by siosm.
https://pagure.io/atomic-wg/issue/513
2:15 p.m.
siosm added a new comment to an issue you are following:
``
Will do. Thanks!
``
To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/513
2003
days inactive
2015
days old
atomic@lists.fedoraproject.org
27 comments
3 participants
participants (3)
-
Colin Walters -
Dusty Mabe
-
Timothée Ravier