Project

General

Profile

Actions

action #176832

closed

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

Create default unattended installation for offline medium without network and oemdrv detection

Added by JERiveraMoya 3 months ago. Updated 14 days ago.

Status:
Resolved
Priority:
Urgent
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
image.png

Related issues 1 (1 open0 closed)

Related to qe-yam - action #180170: Add automation test to generate qcows for oemdrv testNew2025-04-08

Actions
Actions #1

Updated by JERiveraMoya 3 months ago

  • Description updated (diff)
Actions #2

Updated by JERiveraMoya 3 months ago

  • Description updated (diff)
Actions #3

Updated by hjluo 3 months ago

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

Updated by hjluo 3 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 2 months ago · Edited

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

Actions #6

Updated by hjluo 2 months 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 2 months 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 2 months 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 2 months 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 2 months 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 2 months 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 2 months ago

  • Status changed from In Progress to Workable
Actions #15

Updated by JERiveraMoya 2 months 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 about 2 months ago

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

Updated by JERiveraMoya about 2 months 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 about 2 months 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 about 2 months ago

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

Updated by leli about 2 months 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 about 2 months 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 about 2 months 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 about 2 months 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 about 2 months 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 about 1 month 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 about 1 month ago

  • Priority changed from High to Normal
Actions #27

Updated by leli about 1 month ago · Edited

image.png

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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month 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 about 1 month ago

Upload the process for creation of agama_oemdrv.qcow2

Actions #36

Updated by leli 28 days ago

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

Actions #37

Updated by JERiveraMoya 28 days ago

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

Actions #38

Updated by leli 27 days ago

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.

Actions #40

Updated by JERiveraMoya 24 days ago

  • Tags changed from qe-yam-mar-sprint-fy25 to qe-yam-apr-sprint-fy25
Actions #41

Updated by JERiveraMoya 21 days ago

  • Priority changed from Normal to Urgent
Actions #42

Updated by leli 20 days ago · Edited

Updated the autoinst.jsonnet in qcow for aarch64 to specify search vdb for installation, it passed now on OSD. https://openqa.suse.de/tests/17285492#step/agama_auto/31

The profile is:

{
  "bootloader": {
    "stopOnBootMenu": true
  },
  "product": {
    "id": "SLES",
    "registrationCode": "xxx"
   },
  "root": {
    "hashedPassword": true,
    "password": "$6$vYbbuJ9WMriFxGHY$gQ7shLw9ZBsRcPgo6/8KmfDvQ/lCqxW8/WnMoLCoWGdHO6Touush1nhegYfdBbXRpsQuy/FTZZeg7gQL50IbA/"
  },
  "scripts": {
    "post": [
       {
          "content": "#!/usr/bin/env bash\necho 'PermitRootLogin yes' > /etc/ssh/sshd_config.d/root.conf\n",
          "chroot": true,
          "name": "enable root login"
       }
     ]
   },
  "storage": {
    "drives": [
      {
        "search": "/dev/vdb",
        "partitions": [
          ~~{ "search": "*", "delete": true },~~
          { "generate": "default" }
        ]
      }
    ]
  },
  "user": {
    "fullName": "Bernhard M. Wiedemann",
    "hashedPassword": true,
    "password": "$6$vYbbuJ9WMriFxGHY$gQ7shLw9ZBsRcPgo6/8KmfDvQ/lCqxW8/WnMoLCoWGdHO6Touush1nhegYfdBbXRpsQuy/FTZZeg7gQL50IbA/",
    "userName": "bernhard"
  }
}
Actions #43

Updated by leli 20 days ago

PR submitted to make the profiles for oemdrv test in version control, https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/21723

Actions #44

Updated by leli 20 days ago

  • Related to action #180170: Add automation test to generate qcows for oemdrv test added
Actions #45

Updated by JERiveraMoya 19 days ago

  • Subject changed from Create default unattended installation for offline medium without network to Create default unattended installation for offline medium without network and oemdrv detection
Actions #46

Updated by leli 18 days ago

Submitted a new PR to make the profiles for oemdrv test in version control, https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/21758

Actions #47

Updated by JERiveraMoya 14 days ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF