Join Log in
Score:0
avatar Ubuntu

20.04.3 ISCSI failure during boot to log in

pk flag
Walt Corey

Starting maybe a month ago I started having iscsi errors and failures to mount. This roughly coincided with the update of 20.04.3. Trying to cut to the chase I issued the following commands:

root@cor8910:~# iscsiadm -m discovery -t sendtargets -p readynas2 172.16.7.2:3260,1 iqn.2011-09.nas-8B-3E-60:thunderbird 172.16.7.2:3260,1 iqn.2011-09.nas-8B-3E-60:vmguests

root@cor8910:~# iscsiadm -m discovery -t sendtargets -p readynas1 172.16.0.2:3260,1 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5

The above output is correct However when issuing iscsiadm -m node -o show I get 4 records BEGIN RECORD 2.0-874

node.name = iqn.2011-09.nas-8B-3E-60:thunderbird . . . node.conn[0].address = 172.16.7.2 node.conn[0].port = 3260

#end record #Begin record 2.0-874 node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . node.conn[0].address = readyNAS1 #END RECORD That one is BAD as connection addr is readyNAS2 not 1, and should be dotted decimal BEGIN RECORD 2.0-874

node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . . node.conn[0].address = 172.16.7.2< br/> node.conn[0].port = 3260

#END RECORD This one is correct but why is the address dotted decimal and why was previous hosts synomym? BEGIN RECORD 2.0-874

node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = 172.16.0.2 END RECORD BEGIN RECORD 2.0-874

node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = readynas1 #end record Last one is fine as well. I cannot get rid of that bad node record Doc I have googled indicates a /var/lib/iscsi which ubuntu does not have.

root@cor8910:~# ls -al /etc/iscsi/nodes/ total 20

drw------- 4 root root 4096 Oct 9 15:31 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 drw------- 3 root root 4096 Oct 9 15:31 iqn.2011-09.nas-8B-3E-60:thunderbird

drw------- 4 root root 4096 Oct 9 15:31 iqn.2011-09.nas-8B-3E-60:vmguests

I think the problem may have been in defaults subfolder which I moved to a safer place. However, the thunderbird folder still does not get logged in and mounted via fstab. the others do. Once booted I can issue an iscsiadm to login all and manually mount the thunderbird lun where the Thunderbird profile is pointing to it.

I'd like to be able to correct whatever is wrong but in the absence of discovering what is wrong if I purged open-iscsi and re-installed it would that resolve the problem? How does the configuration know in the case of 'readyNAS2' Netgear's ultra 4 NAS unit to refer to it by dotted decimal where 'readyNAS1' Netgear's 214 NAS is picking up the host file synonym for it's address?

After having thought through the pros/cons I purged iscsiadm and re installed it. This actually worked fine, static targets were found and login proceeded speedily. However, upon reboot, post reinstall, the problem reoccurred and I discovered there is something in the startup that creates the static nodes incorrectly. According to man iscsiadm the only type of discovery is sendtarget, isns. NO STATIC, yet it appears to build and use and fail.

158
0 + 0
guiverc avatar
cn flag
guiverc
If this is related to 20.04.3 & *likely* HWE kernel as you suggest (mid-August-2021 update so longer than your *month ago*; https://fridge.ubuntu.com/2021/08/27/ubuntu-20-04-3-lts-released/ *shows ISO release date but that's more than a week after installed machines upgraded to it*), have you tried using the GA kernel? Ubuntu has two kernel stack options - GA which remains stable the life of the LTS release, and HWE which upgrades to later stacks over the first ~two years of the product.
1
Reply
pk flag
Walt Corey
I am not familiar with hardware enablement. I'll look at that more closely tomorrow. Also, not familiar with a choice between two versions of the kernel. By that, do you mean not applying .3? I'm definitely not on new hardware. This machine is several years old, Dell 8910. I upgraded to full 64GB me and added NVM 1G drive. This machine is WAY faster now and I didn't have to drop another $2500 to Dell. Please see comment I added earlier on AskUbuntu question. It's at the bottom. And thanks. https://answers.launchpad.net/ubuntu/+source/open-iscsi/+question/699043
0
Reply
pk flag
Walt Corey
The other thing is I only upgraded when it arrived via the asynchronous software update notification, which seems to arrive long after the updates are available.
0
Reply
guiverc avatar
cn flag
guiverc
No (it has nothing to do with .3; 20.04.2 & 20.04.3 using the GA stack will be using the 5.4 kernel, 20.04.3 using HWE is 5.11 where 20.04.2 using HWE used 5.8). The installation media (ISO) used has a default kernel stack choice; some even allow you to select your stack at install time (eg. ISOs using `subiquity` installer), see https://wiki.ubuntu.com/Kernel/LTSEnablementStack & like wiki pages, but the .3 upgrade was mid-August with the change in HWE stack the key difference, which causes a new ISO re-spun with the newer stack installed, upgrades existing users got a week+ before new ISO)
0
Reply
pk flag
Walt Corey
Decades ago I was told, and learned the hard way, in place upgrades, while attractive, sometimes work great, sometimes fail miserably. This is what prompted me to put the thunderbird email repository to an iscsi. I tried to share my 18.04.7? home directory with 20.04. I'm trying to nuance out the difference between what you are describing and just telling the software update/upgrade applet (this is a desktop env) and I simply depressed the apply update | upgrade push button and at the end it said it needed to reboot so I did. I don't recall any option to select kernel. It's 5.11.0.37-generic.
0
Reply
guiverc avatar
cn flag
guiverc
ISOs using the `ubiquity` or `calamares` installer do not offer an kernel choice - the ISO itself (ie. what you downloaded & wrote to your install media) itself controls that choice (ie. you decide at download time if using an ISO using those installers).
0
Reply
pk flag
Walt Corey
Oh, wait, were you referring to the every 2 yrs LTS vs, in this current case, 20.10, 21.4, 21.10? I have an early morning and need to get to bed now...agn thanks! Let me research this when I get back tomorrow.
0
Reply
guiverc avatar
cn flag
guiverc
No, Ubuntu 20.04, 20.04.1, 20.04.2, 20.04.3, which are available for desktop, server, *flavors* and more. eg. https://releases.ubuntu.com/20.04/ etc various ISOs are offered for each release; most users just grab the default - but alternate ISOs are available. For *flavors* (like Lubuntu) the 20.04 & 20.04.1 media defaulted to GA kernel, 20.04.2 & later defaults to HWE; Ubuntu Desktop 20.04 LTS default ISO uses HWE for all, Ubuntu Server 20.04 LTS defaults to GA for all.
0
Reply
pk flag
Walt Corey
I've caught up. On this particular boot image, nvme drive, I did do a native install. I am pretty sure everything was fine then. It was after or about when it updated to 20.04.3 that the problem arose. The machine boots fine w/o iscsi, as it originally did on nvme. I'm thinking the kernel issue is interesting but not the issue here as the desktop version upgraded to 20.04.3. When I installed from the USB I don't recall being asked which kernel. I think the issue is in iscsid, in generating the iscsi subdir under /etc/ specifically static.
0
Reply
Score:0
avatar Ubuntu
pk flag
Walt Corey

Apparently open-iscsi is very sensitive to what commands are issued and what order they are issued in. The key to figuring this out is getting a 'virgin' environment to test in. I created a VM of the latest 20.04.3 iso and proceeded to configure open-iscsi. As I did not have a redefined /etc/hosts file in the VM there were no synonyms for dotted decimal addresses. I think this may well have been part of the problem.

I tried the sequence of commands depicted above to no avail. It did not fail, it did not even try. I then happened on this URL. It's important to read it slowly and carefully and follow it meticulously. https://www.hiroom2.com/2018/05/05/ubuntu-1804-open-iscsi-en/ While this was written for 18.04 it worked perfectly in the VM. I reproduced those results in my 'production' desktop with identical results.

Pay particular attention in the instruction sequence to

If you have connected to iSCSI target before changing node.startup to automatic, you need to connect to iSCSI target again after changing node.startup to automatic.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.