QA (public) » openQA Project (public) » openQA Tests (public) » qe-yam

https://download.suse.de/ibs/SUSE:/SLFO:/Products:/SLES:/16.0:/TEST/product/iso/

SLES-16.0-aarch64-Build35.1.install.iso
SLES-16.0-ppc64le-Build35.1.install.iso
SLES-16.0-s390x-Build35.1.install.iso
SLES-16.0-x86_64-Build35.1.install.iso

with OFFLINE_SUT=1 Build35.1.install.iso mannual test

• x86_64: https://openqa.suse.de/tests/16751615 PASSED
• Aarch64:
  • https://openqa.suse.de/tests/16751682 failed to boot
  • filed bug#1237171

• For this ticket we just handle 1), do it means it need to add new test case in prod or dev group? Thanks.

hjluo wrote in #note-6:

• For this ticket we just handle 1), do it means it need to add new test case in prod or dev group? Thanks.

Yes, in prod, overwrite ISO in job group yaml and leave failing for aarch pointing to the bug.
But first, we need validation of the repos, that is the main goal. Check in YaST job group how we do, we don't need to create new test module, we have some test modules for that AFIR.

• zypper lr : https://openqa.suse.de/tests/16770363#step/zypper_lr/7

hjluo wrote in #note-8:

• zypper lr : https://openqa.suse.de/tests/16770363#step/zypper_lr/7

Please, check with SM if you don't know what I mean with test module that "validate/check" the repos. This test module that you pointed to doesn't check anything (expected vs actual result) and belongs to a long list of legacy openQA test module that we tried to avoid years ago in the former YaST squad.

JERiveraMoya wrote in #note-9:

hjluo wrote in #note-8:

• zypper lr : https://openqa.suse.de/tests/16770363#step/zypper_lr/7

Please, check with SM if you don't know what I mean with test module that "validate/check" the repos. This test module that you pointed to doesn't check anything (expected vs actual result) and belongs to a long list of legacy openQA test module that we tried to avoid years ago in the former YaST squad.

I found a module console/validate_repos.pm, you can try to use it.

leli wrote in #note-10:

JERiveraMoya wrote in #note-9:

hjluo wrote in #note-8:

• zypper lr : https://openqa.suse.de/tests/16770363#step/zypper_lr/7

Please, check with SM if you don't know what I mean with test module that "validate/check" the repos. This test module that you pointed to doesn't check anything (expected vs actual result) and belongs to a long list of legacy openQA test module that we tried to avoid years ago in the former YaST squad.

I found a module console/validate_repos.pm, you can try to use it.

looks like the result is same:
https://openqa.suse.de/tests/16825751#step/validate_repos/4

• PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/21283

I think it is not possible to run unattended installation without network, because we would not be able to pick the profile. I missed that when creating the ticket.
Why didn't you mention it?

I'm not sure what you tried to accomplish in your PR, but running a bunch of 'tab', 'tab' is not the way that we would like to have this for interactive installation, but that would be another ticket.

More info about feature how to get profile from another device:
https://trello.com/c/LRv5Dli5/4351-5-agama-add-support-for-autoyast-suse-specific-urls
https://agama-preview-pull-58.surge.sh/docs/user/urls (e
Developers didn't try with a qcow2 in virtual manager, but they did with libvirt, we will need to play with that and see how we can have it in any device.

these commands might help to create a qcow2 that we boot as HDD_2, but I haven't tried out:

# qemu-img create drive.qcow2 1G -f qcow2
# modprobe nbd max_part=63
# qemu-nbd -c /dev/nbd0 drive.qcow2
# create partition table and format here
# mount /dev/nbd0p1 /mnt/image

JERiveraMoya wrote in #note-18:

these commands might help to create a qcow2 that we boot as HDD_2, but I haven't tried out:

# qemu-img create drive.qcow2 1G -f qcow2
# modprobe nbd max_part=63
# qemu-nbd -c /dev/nbd0 drive.qcow2
# create partition table and format here
# mount /dev/nbd0p1 /mnt/image

I think we should create a qcow2 to hot plugin before installation, while on installer it seems doesn't support these cmds: qemu-img and qemu-nbd, only found 'qemu-ga'.

leli wrote in #note-20:

JERiveraMoya wrote in #note-18:

these commands might help to create a qcow2 that we boot as HDD_2, but I haven't tried out:

# qemu-img create drive.qcow2 1G -f qcow2
# modprobe nbd max_part=63
# qemu-nbd -c /dev/nbd0 drive.qcow2
# create partition table and format here
# mount /dev/nbd0p1 /mnt/image

I think we should create a qcow2 to hot plugin before installation, while on installer it seems doesn't support these cmds: qemu-img and qemu-nbd, only found 'qemu-ga'.

I honestly don't have a clear idea how to do this but seems that is feasible, developers use usb. Most wisely would be to ask tools team about what are the possibilities to have a single file in some other unit. I see that is possible with ignition/combution, but we need a simple way, it is not related with that technology.

JERiveraMoya wrote in #note-21:

leli wrote in #note-20:

JERiveraMoya wrote in #note-18:

these commands might help to create a qcow2 that we boot as HDD_2, but I haven't tried out:

# qemu-img create drive.qcow2 1G -f qcow2
# modprobe nbd max_part=63
# qemu-nbd -c /dev/nbd0 drive.qcow2
# create partition table and format here
# mount /dev/nbd0p1 /mnt/image

I think we should create a qcow2 to hot plugin before installation, while on installer it seems doesn't support these cmds: qemu-img and qemu-nbd, only found 'qemu-ga'.

I honestly don't have a clear idea how to do this but seems that is feasible, developers use usb. Most wisely would be to ask tools team about what are the possibilities to have a single file in some other unit. I see that is possible with ignition/combution, but we need a simple way, it is not related with that technology.

I thought wrong, the idea should be create a qcow2 with the autoyast profile and upload to OSD data/, for openQA to mount as a second disk and agama can ready profile from this disk and begin installation. Maybe can refer the ignition/combution for how to make the qcow2 file mount as 2nd disk.

Now created qcow and put profile in it, just can see the qcow as data disk in bootloader, but haven't proved that profile file in it.

Steps:
localhost:/home/lemon/ndb_test # qemu-img create drive.qcow2 1G -f qcow2
Formatting 'drive.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=1073741824 lazy_refcounts=off refcount_bits=16
localhost:/home/lemon/ndb_test # modprobe nbd max_part=63
localhost:/home/lemon/ndb_test # qemu-nbd -c /dev/nbd0 drive.qcow2
localhost:/home/lemon/ndb_test # parted --script /dev/nbd0 mklabel gpt mkpart primary 1MiB 500MiB mkpart primary 500MiB 900MiB
localhost:/home/lemon/ndb_test # parted /dev/nbd0 print
Model: Unknown (unknown)
Disk /dev/nbd0: 1074MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 524MB 523MB primary
2 524MB 944MB 419MB primary
localhost:/home/lemon/ndb_test # ls /mnt
lemon-ndb
localhost:/home/lemon/ndb_test # partprobe -s /dev/nbd0
/dev/nbd0: gpt partitions 1 2
1:43
localhost:/home/lemon/ndb_test # mkfs.ext4 /dev/nbd0p1
mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 510976 1k blocks and 127512 inodes
Filesystem UUID: c957cfa3-8013-465b-ad79-30f9b3061912
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
localhost:/home/lemon/ndb_test # mount /dev/nbd0p1 /mnt/lemon-ndb
1:44

Copy profile file to /mnt/lemon-ndb
localhost:/mnt/lemon-ndb # cp /home/lemon/agama-supported.xml .
localhost:/mnt/lemon-ndb # la
total 16
drwxr-xr-x 3 root root 1024 Mar 14 13:29 .
dr-xr-xr-x 1 root root 18 Mar 14 10:28 ..
-rw-r--r-- 1 root root 3027 Mar 14 13:29 agama-supported.xml
drwx------ 2 root root 12288 Mar 14 13:23 lost+found

localhost:/mnt # umount /mnt/lemon-ndb
localhost:/mnt # la
total 0
dr-xr-xr-x 1 root root 18 Mar 14 10:28 .
drwxr-xr-x 1 root root 150 Oct 14 12:25 ..
drwxr-xr-x 1 root root 0 Mar 14 10:28 lemon-ndb
localhost:/mnt # qemu-nbd --disconnect /dev/nbd0
/dev/nbd0 disconnected
localhost:/mnt # rmmod nbd

Now created qcow and put profile in it, just can see the qcow as data disk in bootloader, but haven't proved that profile file in it.

Steps:
qemu-img create drive.qcow2 1G -f qcow2
modprobe nbd max_part=63
qemu-nbd -c /dev/nbd0 drive.qcow2
parted --script /dev/nbd0 mklabel gpt mkpart primary 1MiB 500MiB mkpart primary 500MiB 900MiB
parted /dev/nbd0 print

partprobe -s /dev/nbd0
mkfs.ext4 /dev/nbd0p1

mount /dev/nbd0p1 /mnt/lemon-ndb

Copy profile file to /mnt/lemon-ndb
cp /home/lemon/agama-supported.xml .
localhost:/mnt # umount /mnt/lemon-ndb
localhost:/mnt # qemu-nbd --disconnect /dev/nbd0
localhost:/mnt # rmmod nbd

Updated for copy file to qcow.

it would be more practical if you attached to the job the commands and the output but in your comment you could just sanitize them including only the command themselves, not the output or the prompt, as it is really difficult to read what you wrote above.

We don't need to specify any inst.auto anymore, it will be detected automatically if we label the filesystem with OEMDRV (using something like e2label for instance or some qemu parameters).
Please take a look to latest update:
https://trello.com/c/Im2yrXlm/4415-3-unattended-search-for-the-configuration-profile-at-same-locations-as-autoyast-oemdrv

Uploaded the qcow (OEMDRV) to OSD server:
leli@openqa:/var/lib/openqa/factory/hdd/fixed> la agama_ay_oemdrv.qcow2
-rw-r--r-- 1 geekotest nogroup 43057152 Mar 27 07:04 agama_ay_oemdrv.qcow2

Cloned a job to add HDD_2=agama_ay_oemdrv.qcow2 AGAMA_AUTO= https://openqa.suse.de/tests/17171858

Try to mount the disk to make agama can find the autoyast profile, clone with own branch https://openqa.suse.de/tests/17172181#

leli wrote in #note-30:

Try to mount the disk to make agama can find the autoyast profile, clone with own branch https://openqa.suse.de/tests/17172181#

you don't need to mount the disk or do any action, it should be detected automatically if you format the filesystem with a label in that qcow2, how did you do that btw?
then you also don't need to specify inst.auto=url because the installer already search for you in the hdd2 or should.

you can simplify this:
parted --script /dev/nbd0 mklabel gpt mkpart primary ext4 1MiB 100%
and use an image size of... idk 100MB for example, we don't need 1G.

Notice you can add the label during creation:
mkfs.ext4 -L OEMDRV /dev/nbd0p1
Once mounted to check the label:
lsblk -f /dev/nbd0p1

JERiveraMoya wrote in #note-33:

Notice you can add the label during creation:
mkfs.ext4 -L OEMDRV /dev/nbd0p1
Once mounted to check the label:
lsblk -f /dev/nbd0p1

Ok, I will create a new qcow 100M and label it during creation. Then upload the qcow and run the test again, if it can't be searched again, I will try to import the profile manually and collect logs.

Now blocked by product issue, detailed please check https://suse.slack.com/archives/C02TLF25571/p1743149881130019 . We will apply the test in production group.

in development we can also continue because we should have put a jsonnet profile, where that bug might not appear.

In development group, run this test with qcow with 'autoinst.xml' passed https://openqa.suse.de/tests/17221321#step/agama_auto/36;
run this test with qcow with 'autoinst.jsonnet' has some format issue https://openqa.suse.de/tests/17221094#live.

I will check the test results on the coming Beta3 candidate build in production group also.