Project

General

Profile

Actions

action #124221

closed

coordination #121720: [saga][epic] Migration to QE setup in PRG2+NUE3 while ensuring availability

coordination #129280: [epic] Move from SUSE NUE1 (Maxtorhof) to new NBG Datacenters

Repurpose quake.qe.nue2.suse.org (formerly known as cloud4) as employee-workstation replacement size:M

Added by okurz about 1 year ago. Updated 8 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2023-02-09
Due date:
% Done:

0%

Estimated time:
Tags:

Description

Motivation

cloud4.qa.suse.de According to mgriessmeier and nsinger the machine is not used by cloud team anymore and we can repurpose. Idea: As the machine is basically 8 individual computers we can assign each for employees replacing their workstations and they can do with it what they want.

Acceptance criteria

  • AC1: We have documentation how to provide individual blades to other users reserved for them
  • AC2: The documentation includes the mandatory creation of a user specific IPMI password

Suggestions

  • DONE Provide complete cabling mgmt+production ethernet to all 8 nodes
  • DONE Understand how to get access in general
  • Provide IPMI access to single blades
  • Ensure proper operation of a single blade (e.g. valid DHCP config, DNS name, PXE capabilities)

Related issues 4 (1 open3 closed)

Related to QA - action #125204: Move QA labs NUE-2.2.14-B to Frankencampus labs - non-bare-metal machines size:MResolvedokurz2022-10-28

Actions
Related to openQA Project - action #80382: Provide installation recipes for automatic installations of openQA worker machinesWorkable2020-11-25

Actions
Copied to QA - action #130796: Use free blades on quake.qe.nue2.suse.org and unreal.qe.nue2.suse.org as openQA OSD bare-metal test machinesResolvedokurz2023-02-09

Actions
Copied to QA - action #137144: Ensure that we have less or no workstation left clogging our FC Basement space size:MResolvedokurz

Actions
Actions #1

Updated by okurz about 1 year ago

  • Related to action #125204: Move QA labs NUE-2.2.14-B to Frankencampus labs - non-bare-metal machines size:M added
Actions #2

Updated by okurz about 1 year ago

With #125204#note-5 all hosts from qa4-cloud1 through qa4-cloud8 have been connected to the switch with what dheider and okurz thought are the management and production ethernet ports. We unfortunately don't know MAC addresses and racktables don't know them. They need to be identified. Then DHCP+DNS can be added like done within https://racktables.nue.suse.com/index.php?page=object&object_id=2242 for other machines in that rack.

Actions #3

Updated by okurz about 1 year ago

Together with mkittler experimented with cloud4.qa. I connected my notebook with a USB-C ethernet adapter directly to the individual cloud nodes. There is a little LED next to the management port which is actually a power switch. After I switched on one of the nodes I could see ARP requests in wiresharks. Helpful filter arp && eth.addr != 00:e0:4c:68:00:06

For qa4-cloud6 I see

190 280.895880177   SuperMic_4c:f1:7f   Broadcast   ARP 60  Who has 10.162.65.254? Tell 10.162.65.57    16:38:26.047037217

so the BMC at least on this node already seems to have an IP address.

Another thing, the nodes actually have visible labels with MAC addresses:

  • node1: 0CC47A4D031F
  • node2: 0CC47A4D01D7
  • node3: 0CC47A4CF2CC
  • node4: 0CC47A4D0323
  • node5: 0CC47A4D0324
  • node6: 0CC47A4CF17F
  • node7: 0CC47A4CF3F4
  • node8: 0CC47A4D0329

racktables updated.

I tried to find anything in nmap with nmap -sn 10.168.193.0/22 > nmap_sn ; grep -i '0C.C4.7A.4' nmap_sn for the dynamic DHCP range as defined in https://gitlab.suse.de/OPS-Service/salt/-/blob/production/pillar/domain/qe_nue2_suse_org/init.sls#L61 both when I manually powered off and on the nodes but no luck. Anyone has ideas how to continue?

EDIT: Asked bmwiedemann in chat https://suse.slack.com/archives/C02CANHLANP/p1677854856591749

(Oliver Kurz) hi, do you have hints for us how to make proper use of cloud4? I assume you are the former administrator/maintainer and would know how to use it.
(Bernhard Wiedemann) […] it is one of the 8-blade chassis. Then you got 8x IPMI and only the 2 PSUs are shared.
(Oliver Kurz) thx. That's what I figured. We have all 8xIPMI connected and production ethernet one per blade. But I couldn't see any DHCP request on the IPMI interfaces yet but I don't have full access to the switch nor DHCP server yet. Do you know if the first blade is in any way "special" as the master or controlling node or anything?
(Bernhard Wiedemann) We used it with the first one as gateway/controller - and it might have reconfigured the other blades' IPMI to a fixed static IP
(Oliver Kurz) do you know how to find the static IPs or reset?
(Bernhard Wiedemann) You can use rcipmi start and ipmitool lan print over ssh or local terminal. And sometimes BIOS can show/edit these IPs, too. ipmitool lan set 1 ipsrc dhcp sets DHCP mode again.
(Oliver Kurz) if I would have access into the machine, either remote or physical. But remote I don't have and for physical there is a special connector for what might include VGA/DP/HDMI but I don't have such cable
(Bernhard Wiedemann) There is probably such an adapter on our cloud machines in the A5 rack. Just return it after use. It has VGA+USB
(Oliver Kurz) ok, that might help. By now that's a different location by now. so I would need to pick it up from MH and move to FC and back again. I will try first to get access to the switch and DHCP server, seems easier to me

EDIT: In the end bmwiedemann could help me with getting IPMI access with user "root" and with what seems to be the default "crowbar" IPMI password (stored in private notes)

Actions #4

Updated by okurz 12 months ago

Looked into this again with nsinger. We connected a network cable directly from dingle in the same rack to the management ports of the left-most blade. We pulled out one blade and found a text "super X10SLD-F" which yields results pointing to https://www.supermicro.com/en/products/motherboard/X10SLD-F with the manual on https://www.supermicro.com/manuals/motherboard/C224/MNL-1485.pdf . Also the ethernet port next to the yellow sticker is definitely the IPMI interface when looking at the motherboard. The other two ethernet ports have other mac addresses on a label. Looking at what we have stored in racktables as "asset tag" and mac addresses we might have everything reversed. The corresponding server chassis seems to be "SuperServer 5038ML-H8TRF" https://www.supermicro.com/en/products/system/3u/5038/sys-5038ml-h8trf.cfm with the manual https://www.supermicro.com/manuals/superserver/3U/MNL-1535.pdf . We looked for any DHCP requests on walter1 with walter1:~ # journalctl --since=yesterday -f -u dhcpd | grep -i 0c:c4:7a:4 but nothing. Also tried to see any reaction on USB keyboard or display with an adapter that nsinger found in FC Basement row C/D but nothing. Then we tried out the top ethernet port and on cloud3, right-most blade, top right ethernet port with tcpdump -vvvv from seth-1 connected we could see IPv6 traffic and see the IPv6 address fe80::225:90ff:fed8:9174. We then actually created a port forward from within the ssh session (~C, then enter -L 127.0.0.1:4430:fe80::225:90ff:fed8:9174%eth1:443) and then access from local notebook. Same for c3n3. But for c3n1 not. So likely the BMC interfaces are shared for some blades, not for others.

I asked bmwiedemann again in https://suse.slack.com/archives/C02CANHLANP/p1683118726018749

(Oliver Kurz) do you or anyone else remember the machine cloud3? Happen to know the IPMI credentials for c3n8?
(Bernhard Wiedemann) It is one of those Supermicro 8-node-chassis. Maybe
tried both variants and also the fancy hardly documented old QAM susetesting. I don't have access to the installed system so this is why I am reverting to IPMI. Nick and me also tried with a KVM dongle but we observed no reaction on VGA nor USB keyboard. Bernhard could supply me with a working username and password: It's what "crowbar" sets as default for managed machines

And more details

(Oliver Kurz) ah, ok. Jetzt muss ich mal schauen ob das so für alle 2x8 Blades von cloud3+4 so klappen könnte
(Bernhard Wiedemann) Eventuell nur 7 von 8. Der erste war meist unser Gateway + Admin node
(Oliver Kurz) und was würde dann dafür gelten?
(Bernhard Wiedemann) Der sollte ein Linux mit ssh haben

Actions #5

Updated by okurz 12 months ago

  • Subject changed from Repurpose cloud4.qa.suse.de as employee-workstation replacement to Repurpose cloud4.qa.suse.de (and/or cloud3) as employee-workstation replacement
Actions #6

Updated by okurz 12 months ago

Based on our recent experiments we might need the top right ethernet connectors instead or additionally so for now I connected those for all 8 blades as well, each with a blue cable on the switch ports 33-47 (odd numbers), added in racktables. And from the switches with show ethernet-switching table brief I got mac addresses for many interfaces. Seems like the top left interface isn't doing anything right now though. Also connected cloud3, blade4 aka qa3-node4

Actions #7

Updated by okurz 12 months ago

From walter1 DHCP journalctl -u dhcpd | grep -i 'to \(0c:c4:7a\|00:25\)' | sed -n 's/^.*: DHCPACK on //p' to get current IP addresses for systems requesting them over DHCP matching the MAC addresses I saw in the switching table and have entered into racktables:

10.168.193.48 to 0c:c4:7a:51:e9:f5 via eth0
10.168.193.164 to 0c:c4:7a:51:e6:b2 (phys05) via eth0
10.168.193.35 to 00:25:90:e4:1c:ae (phys06) via eth0
10.168.193.21 to 00:25:90:e4:24:c4 (phys04) via eth0
10.168.193.155 to 0c:c4:7a:51:e8:1c (phys02) via eth0
10.168.193.159 to 0c:c4:7a:51:e7:fe (phys03) via eth0
10.168.193.161 to 00:25:90:e4:22:52 (phys01) via eth0

Those are all "eth1 right". None currently respond to a ping. Maybe those are really the target machines and not IPMI and need the machines to be powered on.

Actions #9

Updated by okurz 12 months ago

  • Status changed from New to In Progress
  • Assignee set to okurz
  • Target version changed from future to Ready

I picked up an adapter from NUE1-SRV2-A as discussed with bmwiedemann and brought that adapter to FC Basement. I connected cloud4 qa4-node7 with the adapter to a VGA screen and USB keyboard. I powered on the system and could see a Supermicro system booting up. The system actually showed the PXE boot menu from qa-jump.qe.nue2.suse.org. I reset the machine and entered the system setup and selected "IPMI" which showed a static configuration for mac 0c-c4-7a-4c-f3-f4 IPv4 10.162.65.51. The address is mentioned in https://gitlab.suse.de/qa-sle/qanet-configs/-/commit/1c46c3531b6c6b456210485e29e55e280ba655e2 "Bulk indentation change" where the entry is actually removed, what a lie!

The removed block from the dhcpd config:

-  #qa4 nodes IPMI 10.162.65.49 to 10.162.65.57
-  group {
-#     option routers 10.162.65.254;
-#     option subnet-mask 255.255.255.0;
-#     option domain-name "bmc.cloud4adm.qa.suse.de";
-#     host gate { hardware ethernet 0c:c4:7a:4d:03:29; fixed-address 10.162.65.49; option host-name "gate"; }
-#     host n1 { hardware ethernet 0c:c4:7a:4c:f3:f4; fixed-address 10.162.65.51; option host-name "n1"; }
-#     host n2 { hardware ethernet 0c:c4:7a:4c:f1:7f; fixed-address 10.162.65.52; option host-name "n2"; }
-#     host n3 { hardware ethernet 0c:c4:7a:4d:03:24; fixed-address 10.162.65.53; option host-name "n3"; }
-#     host n4 { hardware ethernet 0c:c4:7a:4d:03:23; fixed-address 10.162.65.54; option host-name "n4"; }
-#     host n5 { hardware ethernet 0c:c4:7a:4c:f2:cc; fixed-address 10.162.65.55; option host-name "n5"; }
-#     host n6 { hardware ethernet 0c:c4:7a:4d:01:d7; fixed-address 10.162.65.56; option host-name "n6"; }
-#     host n7 { hardware ethernet 0c:c4:7a:4d:03:1f; fixed-address 10.162.65.57; option host-name "n7"; }

I could configure to use DHCP or a different address from the 10.168 range but instead on walter1 I did

ip addr add 10.162.65.252/24 dev eth0

but ping does not reveal something. And the IPMI status page in system setup says "IPMI Network Link Status: No Connect". Let's see. I exited the setup and saw the system ending up in the PXE boot menu. On qa-jump.qe.nue2.suse.org I could see in journalctl -e that the request can actually from 10.168.193.58. Trying to select any installation entry ends up in an error. The menu just blinks and is back where it was. journal on qa-jump shows:

May 17 13:33:45 qa-jump in.tftpd[19657]: RRQ from 10.168.193.58 filename /mounts/dist/install/SLP/SLE-15-SP5-Full-LATEST/x86_64/DVD1/boot/x86_64/loader/linux
May 17 13:33:45 qa-jump in.tftpd[19657]: sending NAK (1, File not found) to 10.168.193.58

walter1 says that the mac is 0c:c4:7a:51:e9:f4

Checking PXE on qa-jump. I am not sure what is off here. /mnt/dist is empty so is /mounts/dist. I added to /etc/fstab

/mnt/dist                                       /mounts/dist                  none     defaults,bind    0 0

and then unmounted /mnt/dist and all dist.suse.de related shares and then mount -a would bring back a proper content in /mnt/dist. Now PXE on qa4-node7 does something useful. I booted into the Leap 15.4 installer. After "Probing EDD … ok" there is just a blinking cursor but alt-f2 shows tty2 from the installer system just fine.

In the meantime the switch shows the above mac …e9:f4 on ge-5/0/45.0 so top right blue cable corresponding to the racktables entry we already have. But no further response to the IPMI interface.

I could do

vgchange -a y
mount /dev/system/root /mnt
chroot /mnt /bin/bash

and enter a SLE15SP1 which also has ipmitool but ipmitool says that no IPMI device was found. I could continue with the actual installation. Or set IPMI to DHCP in system setup.

on walter1 arping -I eth0 10.162.65.51 actually works, ping does not

ARPING 10.162.65.51 from 10.162.65.252 eth0
Unicast reply from 10.162.65.51 [0C:C4:7A:4C:F3:F4]  0.930ms
Unicast reply from 10.162.65.51 [0C:C4:7A:4C:F3:F4]  0.889ms
…

same experiment on seth, same rack as tgt

ip addr add 10.162.65.251/24 dev br0
ping -I br0 10.162.65.51
# (nothing)
arping 10.162.65.51
# good response

also no response using ipmitool -4 -I lanplus -C 3 -H 10.162.65.51 -U root -P [masked] on both walter1 and seth. Maybe the IPMI interface does simply not respond to ICMP requests.

I did not manage to login into the ssh installer system remotely so I just called "yast.ssh" from the local console. In the installer I set default old SUSE root password, static hostname "qa4-node7", dhcp, select ipmitool for installation and ssh server.

After installation I rebooted and found that grub showing the SLE15SP1 entry still. I let the system continue to boot ending up in a "SUSE Manager Server 4.0" and IPv4 10.162.66.50, apparently statically configure. This time at least with an address in that range I could ping from walter1 but I could not find a working root password.

Now I reset the machine and configured IPMI to use DHCP but I did not see a related DHCP request on walter1. I entered the boot menu and selected the second hard drive and that booted the installed Leap 15.4. Using ssh root@10.168.193.58 I could login.
Now I could call ipmitool lan print which gives

Set in Progress         : Set Complete
Auth Type Support       : NONE MD2 MD5 PASSWORD 
Auth Type Enable        : Callback : MD2 MD5 PASSWORD 
                        : User     : MD2 MD5 PASSWORD 
                        : Operator : MD2 MD5 PASSWORD 
                        : Admin    : MD2 MD5 PASSWORD 
                        : OEM      : MD2 MD5 PASSWORD 
IP Address Source       : DHCP Address
IP Address              : 0.0.0.0
Subnet Mask             : 0.0.0.0
MAC Address             : 0c:c4:7a:4c:f3:f4
SNMP Community String   : public
IP Header               : TTL=0x00 Flags=0x00 Precedence=0x00 TOS=0x00
BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled

so no IP address received. Using

ipmitool lan set 1 ipsrc static
ipmitool lan set 1 ipsrc dhcp

I tried to explicitly make it request an address but there is nothing.

trying static with the next free IPv4 address in 10.168.192.0

ipmitool lan set 1 ipsrc static
ipmitool lan set 1 ipaddr 10.168.192.141
ipmitool lan set 1 netmask 255.255.255.0
ipmitool lan set 1 defgw ipaddr 10.168.195.254

and I set default ADMIN:ADMIN credentials for now

ipmitool user set name 2 ADMIN
ipmitool user set password 2
ipmitool channel setaccess 1 2 link=on ipmi=on callin=on privilege=4
ipmitool user enable 2

following https://www.thomas-krenn.com/en/wiki/Configuring_IPMI_under_Linux_using_ipmitool

Called watch -n 0.1 ipmitool lan stats get 1 and could see RX and TX packets as long as the cable is connected but stopping as soon as I pull out the cable.

I also crosschecked with a different cable on different switch port.

Interestingly nmap finds the IPMI node but no open ports

qa4-node7:~ # nmap 10.168.192.141
Starting Nmap 7.92 ( https://nmap.org ) at 2023-05-17 15:11 UTC
Nmap scan report for 10.168.192.141
Host is up (0.00035s latency).
All 1000 scanned ports on 10.168.192.141 are in ignored states.
Not shown: 1000 filtered tcp ports (no-response)
MAC Address: 0C:C4:7A:4C:F3:F4 (Super Micro Computer)

Nmap done: 1 IP address (1 host up) scanned in 21.18 seconds

https://serverfault.com/a/994962 to the rescue:

ipmitool lan set 1 vlan id off

and suddenly everything works including DHCP. I could also authenticate using the "root" user. So that means that likely I need to physically access every node, get access to a linux with ipmitool, delete the vlan assignment, set to dhcp and enable authentication with known credentials.

The current installation can be accessed with ssh root@10.168.193.40, old SUSE default root password.

Actions #10

Updated by openqa_review 12 months ago

  • Due date set to 2023-06-01

Setting due date based on mean cycle time of SUSE QE Tools

Actions #13

Updated by okurz 11 months ago

  • Due date changed from 2023-06-01 to 2023-06-16

Connected qa4-node6 with my personal usb thumbdrive, monitor, keyboard. Switched on, press F11 on start, select USB thumbdrive in BIOS mode (not UEFI) as harddisks are installed with BIOS mode as well. Booted grml64, selected terminal, ran:

ipmitool lan set 1 vlan id off
ipmitool lan set 1 ipsrc dhcp
ipmitool user set name 2 ADMIN
ipmitool user set password 2
ipmitool channel setaccess 1 2 link=on ipmi=on callin=on privilege=4
ipmitool user enable 2

there were error messages about "IANA PEN registry open failed: No such file or directory" which I found upstream in https://github.com/ipmitool/ipmitool/issues/379 and I shouldn't worry about. But then there were other errors like "Get Device ID command failed". Also with retries and waiting I could not set the password.
But ipmitool -I lanplus -C 3 -H 10.168.193.165 -U root -P [masked] at least sometimes. grml has ipmitool 1.8.19 so newer upstream version than openSUSE or SLE with 1.8.18. No difference when using ipmitool from installed SLE. Going to next machine. On qa4-node5 trying just vlan id off and ipsrc dhcp. After setting to dhcp eventually the machine would get an IPv4 address, 10.168.193.185, but then the IPMI also for local access behaved quite weird and unstable, same errors as on node node6. Maybe DHCP is problematic at least for the firmware version.

So setting static address for next node, qa4-node4:

ipmitool lan set 1 vlan id off
ipmitool lan set 1 ipaddr 10.168.192.148
ipmitool lan set 1 netmask 255.255.252.0
ipmitool lan set 1 defgw ipaddr 10.168.195.254

remote access works. Leaving that for now, continuing with next. Did the next on qa4-node3 with 10.168.192.146. Executing the ipmitool commands takes very long, the complete chain multiple minutes, remote access also with errors. Works with multiple retries. Maybe BMC firmware update helps. Found https://www.supermicro.com/en/support/resources/downloadcenter/firmware/MBD-X10SLD-F/BMC . For previous node https://10.168.192.148/cgi/url_redirect.cgi?url_name=mainmenu says Firmware Revision : 03.72, download is 3.88. Updating firmware with REDFISH_X10_388_20200221_unsigned.bin , worked ok.

In the meantime configured node1,2,3. node1 is reachable just fine, node2 isn't, node3 unreliable. Maybe problem with switch? network? Configured all nodes with static address for now.

TODO:

  1. Try to set .148 to DHCP and check IPMI stability with new firmware
  2. Update other node's firmware
  3. Create specific tickets for problematic nodes
  4. Consider renaming in racktables and DHCP the other way around as in before meaning that node1 would be right-most
  5. Submit MR for DHCP+DNS config
  6. Try remote installation once more with instructions for users
  7. Suggest the solution to others
Actions #14

Updated by okurz 11 months ago

  • Subject changed from Repurpose cloud4.qa.suse.de (and/or cloud3) as employee-workstation replacement to Repurpose cloud4.qa.suse.de (and/or cloud3) as employee-workstation replacement size:M
  • Description updated (diff)
Actions #15

Updated by okurz 11 months ago

  • Description updated (diff)
Actions #16

Updated by okurz 11 months ago

Submit MR for DHCP+DNS config:
https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/3536

TODO:

  1. Try to set .148 to DHCP and check IPMI stability with new firmware
  2. Update other node's firmware
  3. Create specific tickets for problematic nodes
  4. Try remote installation once more with instructions for users
  5. Suggest the solution to others
Actions #18

Updated by okurz 11 months ago

  • Status changed from In Progress to Feedback

I set .148 to DHCP and the system reappeared as https://10.168.193.132 . I also set the hostname in the BMC web menu to quake4-sp.qe.nue2.suse.org.
Same procedure for quake6+7, also upgraded firmware. Same for quake1 on https://10.168.192.142 and quake8 on https://10.168.192.156/ . Couldn't reach 2,3,5 right now.
Was running runs=10000 count_fail_ratio ipmitool -I lanplus -C 3 -H 10.168.193.132 -U root -P 'XXX' mc guid on ok1.qe.nue2.suse.org. Result: count_fail_ratio: Run: 10000. Fails: 0. Fail ratio 0±0%. No fails, computed failure probability < .03%, same for quake6+7, super fast and super stable. I created #129868 for the not reachable nodes.

Added some info on https://wiki.suse.net/index.php/SUSE-Quality_Assurance/Labs#Machines_available_for_reservation, should wait for https://gitlab.suse.de/OPS-Service/salt/-/merge_requests/3536

Actions #19

Updated by okurz 11 months ago

MR merged and effective. Trying an install on quake1

In PXE boot I selected "Autoyast" with parameters console=tty0 console=ttyS0,115200 console=ttyS1,115200 autoyast=https://w3.suse.de/~okurz/ay-openqa-worker.xml but couldn't see any output. Also tried just console=ttyS1,115200 but still no.

How can I make the OS output visible in the serial terminal output accessible over IPMI?

Actions #20

Updated by okurz 11 months ago

  • Subject changed from Repurpose cloud4.qa.suse.de (and/or cloud3) as employee-workstation replacement size:M to Repurpose quake.qe.nue2.suse.org (formerly known as cloud4) as employee-workstation replacement size:M
Actions #21

Updated by okurz 11 months ago

Things to try:

  1. Try "ttyS2"
  2. Try other hosts than quake1

We just succeeded with console=ttyS2,115200. Leap autoyast installation failed due to product missing. Adjusted autoyast config file as new https://w3.suse.de/~okurz/ay-openqa-worker-leap.xml

so boot options

console=ttyS2,115200 autoyast=https://w3.suse.de/~okurz/ay-openqa-worker-leap.xml rootpassword=susetesting

I tried to just add ttyS0…ttyS2 and that showed that there is no serial output. Let's try ttyS2…ttyS0. By the way removing characters in the PXE menu works with Ctrl-H. So selecting "Leap+HTTP+Text(console)". Leaving out the baudrate renders no output, trying again with ttyS2…ttyS0. That yields only partial ouput. Better use only one command line parameter as suggested above.

I updated https://wiki.suse.net/index.php/SUSE-Quality_Assurance/Labs#Machines_available_for_reservation with what ipmitool command works with a suggestion for the right console parameter.

In the end the installation kinda succeeded but neither salt nor ssh was properly configured or not active and the network interfaces were not configured properly either:

2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 0c:c4:7a:51:e8:1c brd ff:ff:ff:ff:ff:ff
    altname enp1s0f0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 0c:c4:7a:51:e8:1d brd ff:ff:ff:ff:ff:ff
    altname enp1s0f1
    inet 10.168.193.41/22 brd 10.168.195.255 scope global eth1

so maybe we can configure autoyast to configure the first and not the last network interface.

EDIT: Adapted https://w3.suse.de/~okurz/ay-openqa-worker-leap.xml to configure the first ethernet device. That actually configures both but that's ok.

And looks like online repositories are missing. https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD-Updates&machine=64bit&test=autoyast_leap_videomode_text&version=15.5 shows how repositories are explicitly added in the autoyast profile but I would prefer to just use what the installer offers.

I asked in https://suse.slack.com/archives/C02D1T4S58S/p1686642211490269

Hi, I found https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD-Updates&machine=64bit&test=autoyast_leap_videomode_text&version=15.5 shows how repositories are explicitly added in the autoyast profile but I would prefer to just use what the installer offers. I think that has worked in the past. I conducted an installation that is missing most online repositories if I did not add them. Any hints?

No response yet. As a quick fix after installation I did for i in update/leap/\$releasever/non-oss distribution/leap/\$releasever/repo/oss update/leap/\$releasever/oss distribution/leap/\$releasever/repo/non-oss; do zypper ar https://download.opensuse.org/$i $i; done

Actions #22

Updated by okurz 11 months ago

  • Related to action #80382: Provide installation recipes for automatic installations of openQA worker machines added
Actions #23

Updated by okurz 11 months ago

  • Due date deleted (2023-06-16)
  • Status changed from Feedback to Resolved

I updated https://wiki.suse.net/index.php/SUSE-Quality_Assurance/Labs#Machines_available_for_reservation with IPMI user+password instructions. Installation is definitely possible even though autoyast as described above is not without caveats.

Actions #24

Updated by okurz 11 months ago

  • Copied to action #130796: Use free blades on quake.qe.nue2.suse.org and unreal.qe.nue2.suse.org as openQA OSD bare-metal test machines added
Actions #25

Updated by okurz 10 months ago

  • Parent task set to #130955
Actions #26

Updated by okurz 8 months ago

  • Parent task changed from #130955 to #129280
Actions #27

Updated by okurz 7 months ago

  • Copied to action #137144: Ensure that we have less or no workstation left clogging our FC Basement space size:M added
Actions

Also available in: Atom PDF