Project

General

Profile

Actions

action #176832

open

coordination #169654: [epic] Create test scenarios for Agama

Create default unattended installation for offline medium without network

Added by JERiveraMoya about 2 months ago. Updated 3 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
-
Start date:
2025-02-09
Due date:
% Done:

0%

Estimated time:

Description

Motivation

There are 2 use cases for offline medium:
1) installation without network
2) installation with registration where installer prefers the package in the medium but still setup registration and installed system contains update repos.

In this ticket we will deal with 1) setting up for the architecture that allow us to switch off the network, with qemu it is just OFFLINE_SUT=1
As the SUT doesn't have network the easier way "for now" is to provide unattended installation where we can control it with needles, due to we are not going to be able to download the puppeteer tests.

Acceptance criteria

  • AC1: Monitor bugs and provide feedback about the state of the offline medium regarding proper booting.
  • AC2: Default unattended installation for offline medium without network is provided.
  • AC3: Check repos after installation.

Additional information

If the medium is not sync on openQA, just copy it to openQA and override openQA variable ISO.


Files

image.png (24.1 KB) image.png leli, 2025-03-24 06:36
process_agama_oemdrv_qcow2.txt (2.08 KB) process_agama_oemdrv_qcow2.txt leli, 2025-03-28 03:07
Actions #1

Updated by JERiveraMoya about 2 months ago

  • Description updated (diff)
Actions #2

Updated by JERiveraMoya about 2 months ago

  • Description updated (diff)
Actions #3

Updated by hjluo about 2 months ago

  • Status changed from Workable to In Progress
  • Assignee set to hjluo
Actions #4

Updated by hjluo about 2 months ago

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

Actions #5

Updated by hjluo about 2 months ago · Edited

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

Actions #6

Updated by hjluo about 1 month ago

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

Updated by JERiveraMoya about 1 month ago

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.

Actions #9

Updated by JERiveraMoya about 1 month ago

hjluo wrote in #note-8:

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.

Actions #10

Updated by leli about 1 month ago

JERiveraMoya wrote in #note-9:

hjluo wrote in #note-8:

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.

Actions #11

Updated by hjluo about 1 month ago

leli wrote in #note-10:

JERiveraMoya wrote in #note-9:

hjluo wrote in #note-8:

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

Actions #13

Updated by JERiveraMoya about 1 month ago

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.

Actions #14

Updated by JERiveraMoya about 1 month ago

  • Status changed from In Progress to Workable
Actions #15

Updated by JERiveraMoya about 1 month ago · Edited

  • Assignee deleted (hjluo)

I'm asking how it would be possible to access the profile when the sut doesn't have network:
https://suse.slack.com/archives/C02TLF25571/p1740580619960939

Regarding this task and PR, we should not continue with a different test case if the test case purposed in this ticket cannot be accomplish or we don't know how.
I have different plans to avoid to create tests with needles and a bunch of keys, that was the motivation of this ticket to do it with the unattended.
Closing your PR and unassigning until we solve the question above.

Actions #16

Updated by JERiveraMoya 28 days ago

  • Tags changed from qe-yam-feb-sprint-fy25 to qe-yam-mar-sprint-fy25
Actions #17

Updated by JERiveraMoya 24 days ago

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.

Actions #18

Updated by JERiveraMoya 20 days ago

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
Actions #19

Updated by leli 19 days ago

  • Status changed from Workable to In Progress
  • Assignee set to leli
Actions #20

Updated by leli 18 days ago · Edited

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'.

Actions #21

Updated by JERiveraMoya 18 days ago

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.

Actions #22

Updated by leli 18 days ago

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.

Actions #23

Updated by leli 17 days ago · Edited

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

Actions #24

Updated by leli 17 days ago · Edited

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.

Actions #25

Updated by JERiveraMoya 17 days ago

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.

Actions #26

Updated by JERiveraMoya 10 days ago

  • Priority changed from High to Normal
Actions #27

Updated by leli 7 days ago · Edited

After created the qcow with profile, added the qcow as 2nd virtio disk, installed system, mount the disk then found the profile.
Detail steps:

1. On local VM, add the drive.qcow as 2nd virtio disk.
2. Installed 15SP7 textmode system.
3. Mount disk:
3.1 Create a directory for the mount point.
 # mkdir /mnt/data
3.2 Get the UUID of the disk drive.
 # lsblk -f
3.3 Add disk drive to fstab.
   # vim /etc/fstab
   # UUID=xxx   /mnt/data   ext4    defaults   0 2
3.4 Mount disk drive.
   # mount -a
3.5 Verify drive is mounted.
   # lsblk
4. Show the profile
   # la /mnt/data/
Actions #28

Updated by JERiveraMoya 7 days ago

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

Actions #29

Updated by leli 4 days ago · Edited

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

Actions #30

Updated by leli 4 days ago

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

Actions #31

Updated by JERiveraMoya 4 days ago

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.

Actions #32

Updated by JERiveraMoya 4 days ago

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.

Actions #33

Updated by JERiveraMoya 4 days ago

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

Actions #34

Updated by leli 3 days ago

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.

Actions #35

Updated by leli 3 days ago

Upload the process for creation of agama_oemdrv.qcow2

Actions

Also available in: Atom PDF