On 10/27/23 07:06, Lennart Poettering wrote:
On Do, 26.10.23 19:03, Tony Rodriguez (unixpro1...@gmail.com) wrote:
Experiencing this same issue with iSCSI and systemd-239 for RH8/Rocky8 and
RH9/Rocky9 system-252. Nothing was done on my end to create this issue. In
other words, no custom mount
Experiencing this same issue with iSCSI and systemd-239 for RH8/Rocky8
and RH9/Rocky9 system-252. Nothing was done on my end to create this
issue. In other words, no custom mount/unit files or services, just
your typical ISO install and rpm updates.
An ordering cycle occurs, when "_netdev"
Experiencing this same issue with iSCSI and systemd-239 for RH8/Rocky8
and RH9/Rocky9 system-252. Nothing was done on my end to create this
issue. In other words, no custom mount/unit files or services, just
your typical ISO install and rpm updates.
An ordering cycle occurs, when "_netdev"
Believe I found a solution after some extra debugging. However, I
appreciate materials/links you provided. It is definitely good stuff to
know.
Regards,
Tony
Created a service that invokes a "systemctl daemon-reload". Goal is for
a reload to occur early in the boot process, before other user made
services are invoked. During additional testing, sometimes it is
correct and other times it is out of order (incorrect - See steps C).
It may work for
Valgrind is reporting "still reachable" memory leak (2 blocks) when
calling find_device() and FOREACH_DEVICE_DEVLINK against "systemd-249".
In my case, they are both called within fstab-generator.c on
"systemd-249". Only code modifications, on my end, are within
fstab-generator.c
A) Block 1
From my understanding, it is frowned by systemd developers to
"automatically" reload systemd via "systemctl daemon-reload" when
/etc/fstab is modified. Guessing this is why such functionality hasn't
already been incorporated into systemd. However, I would like to send a
simple text message.
suggestions and tried to help. Thanks again.
Tony
On 8/27/19 11:06 AM, Andrei Borzenkov wrote:
27.08.2019 18:55, Tony Rodriguez пишет:
Interesting that you mentioned the following. I actually added logic to
do something like this early yesterday. Will discuss with my team to
see if this is good
My team mentioned adding _netdev is now acceptable (thank goodness) but
wondering if there is a way to limit the timeout when using _netdev?
On 8/27/19 8:55 AM, Tony Rodriguez wrote:
Interesting that you mentioned the following. I actually added logic
to do something like this early yesterday
ou're
stuck with stupid fstab requirements why not just bypass them with
altogether with drop-in:
# path-to-mountpoint.mount.d/20-Options.conf
[Mount]
Options=_netdev"
On 8/27/19 2:33 AM, Michael Chapman wrote:
On Tue, 27 Aug 2019, Tony Rodriguez wrote:
Managed to detect/m
Managed to detect/mount iscsi devices without using _netdev keyword in
/etc/fstab. Made changes within src/fstab-generator/ftstab-generator.c
and it seems to work. The only problem is during shutdown/reboot, my
iscsi xfs filesystem does not unmount cleanly before the network/iscs
ay instead of trying to implement points
(1) or (2)
Tony
On 8/20/19 3:33 PM, Rick Beldin wrote:
This might be problematic. What will you do with iscsi devices that support
iscsi offload? Those are typically completely invisible to the OS and just
appear as another HBA.
On 8/20/19 3:26 PM, T
I modified systemd-219 functionality to meet a custom requirement for
detecting filesystems/devices that use iscsi without using the _netdev
keyword in /etc/fstab. It is a strict requirement regarding not using
_netdev that I have no control over. However, I am stuck.
From my
I modified systemd-219 functionality to meet a custom requirement for
detecting filesystems/devices that use iscsi without using the _netdev
keyword in /etc/fstab. It is a strict requirement regarding not using
_netdev that I have no control over. However, I am stuck.
From my
14 matches
Mail list logo
