On Wed, 2021-08-18 at 19:35 +0530, Ritesh Raj Sarraf wrote: > On Wed, 2021-08-18 at 13:32 +0100, Jose M Calhariz wrote: > > I was expecting to be easy to collect the info in one or 2 files, but > > I am wrong. I have 3 targets with multipath for 2 of them and I am > > not certain what is active. I have multipath active, I am certain of > > that, because of the device I am mouting: > > /dev/mapper/mpath-XXXXX-part1 > > > > So I am expecting you need all files inside /etc/iscsi and some > > run-time info? > > I am asking this information just for the sake of this task, to > ascertain why it failed in the first 30 seconds. > > Since this worked for you, later, when you increased the timeout to 120 > seconds; there's not much to do I suppose. But yes, from this bug > report's sake, having that information clarified will be good.
Given this bug report, I validated the upgrade on my local box. It is a
fairly complex configuration pulling in all bits: iSCSI, Multipath,
Root on Multipath (iSCSI) etc.
I can confirm that the upgrade went proper without any glitch. Relevant
snippets below:
Preparing to unpack .../20-libisns0_0.100-3_amd64.deb ...
Unpacking libisns0:amd64 (0.100-3) over (0.100-2) ...
Preparing to unpack .../21-libopeniscsiusr_2.1.3-5_amd64.deb ...
Unpacking libopeniscsiusr (2.1.3-5) over (2.1.2-1) ...
Preparing to unpack .../22-open-iscsi_2.1.3-5_amd64.deb ...
Unpacking open-iscsi (2.1.3-5) over (2.1.2-1) ...
Preparing to unpack .../23-pigz_2.6-1_amd64.deb ...
Unpacking pigz (2.6-1) over (2.4-1+b1) ...
Preparing to unpack .../24-popularity-contest_1.71_all.deb ...
Setting up vim-tiny (2:8.2.2434-3) ...
Setting up man-db (2.9.4-2) ...
Updating database of manual pages ...
man-db.service is a disabled or a static unit not running, not starting
it.
Setting up open-iscsi (2.1.3-5) ...
open-iscsi postinst: since the check in preinst some iSCSI sessions
have
failed. -> will wait 30s for automatic recovery
Setting up usbutils (1:013-3) ...
Setting up fdisk (2.36.1-8) ...
Setting up grub-common (2.04-20) ...
Installing new version of config file /etc/grub.d/30_uefi-firmware ...
and
root@debian-sanboot:~# multipath -ll
sanroot (3600140561d8bb00b25143b38318ce2c0) dm-0 LIO-ORG,debsanboot
size=8.0G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 2:0:0:0 sda 8:0 active ready running
|-+- policy='service-time 0' prio=50 status=enabled
| `- 3:0:0:0 sdb 8:16 active ready running
|-+- policy='service-time 0' prio=50 status=enabled
| `- 4:0:0:0 sdc 8:32 active ready running
`-+- policy='service-time 0' prio=50 status=enabled
`- 5:0:0:0 sdd 8:48 active ready running
root@debian-sanboot:~# iscsiadm -m session
tcp: [1] 172.16.20.40:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)
tcp: [2] 172.16.20.41:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)
tcp: [3] 172.16.20.43:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)
tcp: [4] 172.16.20.42:3260,1 iqn.2003-01.org.linux-iscsi.debian.sanboot
(non-flash)
So from the information I have, my suspicion was correct. The oddity
must be in your setup. The defaults must have been overridden for a
good reason. There's also the possibility that your network may have a
glitch. It is not easy for me to guess.
And with limited volunteer time, there's only a subset of the default
settings/combinations I can test at my end.
I suggest this bug be done as I don't see any issue. But I'll let you
make that call.
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
signature.asc
Description: This is a digitally signed message part
