Update Grub on component devices if /boot is on mdraid device #1093

matejmatuska · 2023-06-22T12:37:58Z

On BIOS systems, previously, if /boot was on md device such as RAID
consisting of multiple partitions on different MBR/GPT partitioned
drives, the part of Grub residing in the 512 Mb after MBR was only
updated for one of the drives. Similar situation occurred on GPT
partitioned drives and the BIOS boot partition. This resulted in
outdated GRUB on the remaining drives which could cause the system to be
unbootable.

Now, Grub is updated on all the component devices of an md array if Grub
was already installed on them before the upgrade.

Jira: OAMG-7835
BZ#2219544
BZ#2140011

github-actions · 2023-06-22T12:38:10Z

Thank you for contributing to the Leapp project!

Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable.
If you want to request a review or rebuild a package in copr, you can use following commands as a comment:

review please @oamg/developers to notify leapp developers of the review request
/packit copr-build to submit a public copr build using packit

Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build. If you need a different version of leapp from PR#42, use /packit test oamg/leapp#42

To launch regression testing public members of oamg organization can leave the following comment:

/rerun to schedule basic regression tests using this pr build and latest upstream leapp build as artifacts
/rerun 42 to schedule basic regression tests using this pr build and leapp*PR42* as artifacts
/rerun-sst to schedule sst tests using this pr build and latest upstream leapp build as artifacts
/rerun-sst 42 to schedule sst tests using this pr build and leapp*PR42* as artifacts

Please open ticket in case you experience technical problem with the CI. (RH internal only)

Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra.

fernflower

Please see some questions/remarks inline.
BTW, would it be possible to add some unit tests? It seems like a significant change that definitely deserves some :)

repos/system_upgrade/common/actors/scangrubdevice/actor.py

repos/system_upgrade/common/libraries/mdraid.py

repos/system_upgrade/common/libraries/grub.py

repos/system_upgrade/common/actors/updategrubcore/libraries/updategrubcore.py

matejmatuska · 2023-06-25T09:05:38Z

Tested on RHEL 7.9->8.8 and 8.8->9.2
With the following disk configuration:

# lsblk -so "NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT"
NAME     SIZE TYPE  FSTYPE            MOUNTPOINT
md126     12G raid5 xfs               /
├─vda2     4G part  linux_raid_member
│ └─vda    5G disk
├─vdb2     4G part  linux_raid_member
│ └─vdb    5G disk
├─vdc2     4G part  linux_raid_member
│ └─vdc    5G disk
└─vdd2     4G part  linux_raid_member
  └─vdd    5G disk
md127   1023M raid1 xfs               /boot
├─vda1     1G part  linux_raid_member
│ └─vda    5G disk
├─vdb1     1G part  linux_raid_member
│ └─vdb    5G disk
├─vdc1     1G part  linux_raid_member
│ └─vdc    5G disk
└─vdd1     1G part  linux_raid_member
  └─vdd    5G disk
sr0     1024M rom

(4 drives, /boot on RAID1, / on RAID5)

Without this patch the upgrades failed to boot into the system after initramfs
phase. GRUB jumps into rescue with symbol ... not found error.

With this patch applied, this problem is fixed on both RHEL versions. In the scan phase the
scangrubdevice actor correctly identifies all boot devices:
leapp.workflow.FactsCollection.scan_grub_device_name: GRUB is installed on /dev/vdc,/dev/vdb,/dev/vda,/dev/vdd

And in the RPMUpgrade phase grub2-install is correctly called on each of those
devices:

leapp.workflow.RPMUpgrade.update_grub_core: External command has started: ['grub2-install', u'/dev/vdc', '-v']
...
leapp.workflow.RPMUpgrade.update_grub_core: External command has finished: ['grub2-install', u'/dev/vdc', '-v']
leapp.workflow.RPMUpgrade.update_grub_core: External command has started: ['grub2-install', u'/dev/vdc', '-v']
...
leapp.workflow.RPMUpgrade.update_grub_core: External command has finished: ['grub2-install', u'/dev/vdc', '-v']
leapp.workflow.RPMUpgrade.update_grub_core: External command has started: ['grub2-install', u'/dev/vdc', '-v']
...
leapp.workflow.RPMUpgrade.update_grub_core: External command has finished: ['grub2-install', u'/dev/vdc', '-v']
leapp.workflow.RPMUpgrade.update_grub_core: External command has started: ['grub2-install', u'/dev/vdc', '-v']
...
leapp.workflow.RPMUpgrade.update_grub_core: External command has finished: ['grub2-install', u'/dev/vdc', '-v']

The system then properly boots and the upgrade continues smoothly.

matejmatuska · 2023-06-30T09:34:01Z

Tested on RHEL 7.9->8.8 and 8.8->9.2 With the following disk configuration:

# lsblk -so "NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT"
NAME     SIZE TYPE  FSTYPE            MOUNTPOINT
md126     12G raid5 xfs               /
├─vda2     4G part  linux_raid_member
│ └─vda    5G disk
├─vdb2     4G part  linux_raid_member
│ └─vdb    5G disk
├─vdc2     4G part  linux_raid_member
│ └─vdc    5G disk
└─vdd2     4G part  linux_raid_member
  └─vdd    5G disk
md127   1023M raid1 xfs               /boot
├─vda1     1G part  linux_raid_member
│ └─vda    5G disk
├─vdb1     1G part  linux_raid_member
│ └─vdb    5G disk
├─vdc1     1G part  linux_raid_member
│ └─vdc    5G disk
└─vdd1     1G part  linux_raid_member
  └─vdd    5G disk
sr0     1024M rom

(4 drives, /boot on RAID1, / on RAID5)

Without this patch the upgrades failed to boot into the system after initramfs phase. GRUB jumps into rescue with symbol ... not found error.

With this patch applied, this problem is fixed on both RHEL versions. In the scan phase the scangrubdevice actor correctly identifies all boot devices: leapp.workflow.FactsCollection.scan_grub_device_name: GRUB is installed on /dev/vdc,/dev/vdb,/dev/vda,/dev/vdd

And in the RPMUpgrade phase grub2-install is correctly called on each of those devices:

leapp.workflow.RPMUpgrade.update_grub_core: External command has started: ['grub2-install', u'/dev/vdc', '-v']
...
leapp.workflow.RPMUpgrade.update_grub_core: External command has finished: ['grub2-install', u'/dev/vdc', '-v']
leapp.workflow.RPMUpgrade.update_grub_core: External command has started: ['grub2-install', u'/dev/vdc', '-v']
...
leapp.workflow.RPMUpgrade.update_grub_core: External command has finished: ['grub2-install', u'/dev/vdc', '-v']
leapp.workflow.RPMUpgrade.update_grub_core: External command has started: ['grub2-install', u'/dev/vdc', '-v']
...
leapp.workflow.RPMUpgrade.update_grub_core: External command has finished: ['grub2-install', u'/dev/vdc', '-v']
leapp.workflow.RPMUpgrade.update_grub_core: External command has started: ['grub2-install', u'/dev/vdc', '-v']
...
leapp.workflow.RPMUpgrade.update_grub_core: External command has finished: ['grub2-install', u'/dev/vdc', '-v']

The system then properly boots and the upgrade continues smoothly.

This should still be up to date.

pirat89

@matejmatuska I have discussed the PR with @pholica and we have realized that actually it fixes different things than to which refers and commit msg actually should be also different. let's sync about it later.

pholica · 2023-07-04T06:05:13Z

Going through the code quickly, it looks like this should be fixing situation when /boot is on RAID1 on BIOS system with MBR partition table, however as @pirat89 said, that's not situation of https://en.wikipedia.org/wiki/BIOS_boot_partition (referenced Jira task by this PR) neither /boot and /boot/efi being on RAID1 on UEFI (which are other parts of "SW RAID support" needed to be implemented to fix the referenced bug.

It sounds to me like the only problematic thing (please correct me if I'm wrong) when it comes to this PR is just bug/issue references and lack of mention of BIOS and MBR in the description.

matejmatuska · 2023-07-04T08:10:28Z

Going through the code quickly, it looks like this should be fixing situation when /boot is on RAID1 on BIOS system with MBR partition table, however as @pirat89 said, that's not situation of https://en.wikipedia.org/wiki/BIOS_boot_partition (referenced Jira task by this PR) neither /boot and /boot/efi being on RAID1 on UEFI (which are other parts of "SW RAID support" needed to be implemented to fix the referenced bug.

It sounds to me like the only problematic thing (please correct me if I'm wrong) when it comes to this PR is just bug/issue references and lack of mention of BIOS and MBR in the description.

@pholica @pirat89 I see the porblem now, for a moment I missed the fact that there are GPT disks in the BZ. Yes, this should solve the problem for MBR partitoned disks on BIOS, I will update the description. However seems like the BZ reporter fixed the bug in a similar fashion, so I will do some testing with GPT disks also and see if we can fix that here too.

repos/system_upgrade/common/libraries/mdraid.py

pirat89 · 2023-07-04T08:29:44Z

Going through the code quickly, it looks like this should be fixing situation when /boot is on RAID1 on BIOS system with MBR partition table, however as @pirat89 said, that's not situation of https://en.wikipedia.org/wiki/BIOS_boot_partition (referenced Jira task by this PR) neither /boot and /boot/efi being on RAID1 on UEFI (which are other parts of "SW RAID support" needed to be implemented to fix the referenced bug.
It sounds to me like the only problematic thing (please correct me if I'm wrong) when it comes to this PR is just bug/issue references and lack of mention of BIOS and MBR in the description.

@pholica @pirat89 I see the porblem now, for a moment I missed the fact that there are GPT disks in the BZ. Yes, this should solve the problem for MBR partitoned disks on BIOS, I will update the description. However seems like the BZ reporter fixed the bug in a similar fashion, so I will do some testing with GPT disks also and see if we can fix that here too.

for the GPT, it would need more work as currently we do not have even detection of the grub for GPT partitioned disks nat all.

matejmatuska · 2023-07-04T09:27:31Z

@pirat89 can you please address the TODO in PR description, not sure what the process is there?

It makes more sense to me to remove them now, but just to be sure.

repos/system_upgrade/common/actors/scangrubdevice/actor.py

repos/system_upgrade/common/actors/updategrubcore/libraries/updategrubcore.py

repos/system_upgrade/common/libraries/grub.py

repos/system_upgrade/common/libraries/mdraid.py

pirat89 · 2023-07-17T10:13:01Z

Manual testing for https://bugzilla.redhat.com/show_bug.cgi?id=2219544:

orig:

----------------------------------------------------------------------
Stamp: 2023-07-17T09:56:02.523801Z
Actor: scan_grub_device_name
Phase: FactsCollection
Type: GrubInfo
Message_data:
{
    "orig_device_name": "/dev/vdb"
}

new msg:

Actor: scan_grub_device_name
Phase: FactsCollection
Type: GrubInfo
Message_data:
{
    "orig_device_name": null, 
    "orig_devices": [
        "/dev/vdb", 
        "/dev/vda"
    ]
}

pirat89 · 2023-07-17T11:29:22Z

@matejmatuska on normal systems it reproduces now 2 GrubInfo msgs, which is wrong. There must not be more than one:

######################################################################
                          PRODUCED MESSAGES                           
######################################################################
Stamp: 2023-07-17T11:00:21.381393Z
Actor: scan_grub_device_name
Phase: FactsCollection
Type: GrubInfo
Message_data:
{
    "orig_device_name": "/dev/vda", 
    "orig_devices": [
        "/dev/vda"
    ]
}
----------------------------------------------------------------------
Stamp: 2023-07-17T11:00:21.355611Z
Actor: scan_grub_device_name
Phase: FactsCollection
Type: GrubInfo
Message_data:
{
    "orig_device_name": "/dev/vda", 
    "orig_devices": [
        "/dev/vda"
    ]
}
######################################################################

Update: this is bug in the framework: oamg/leapp#836 - in the meanwhile, let's check if the file exists manually - proove it works now:

######################################################################
                          PRODUCED MESSAGES                           
######################################################################
Stamp: 2023-07-17T16:55:53.879339Z
Actor: scan_grub_device_name
Phase: FactsCollection
Type: GrubInfo
Message_data:
{
    "orig_device_name": "/dev/vda", 
    "orig_devices": [
        "/dev/vda"
    ]
}
######################################################################

On BIOS systems, previously, if /boot was on md device such as RAID consisting of multiple partitions on different MBR/GPT partitioned drives, the part of Grub residing in the 512 Mb after MBR was only updated for one of the drives. Similar situation occurred on GPT partitioned drives and the BIOS boot partition. This resulted in outdated GRUB on the remaining drives which could cause the system to be unbootable. Now, Grub is updated on all the component devices of an md array if Grub was already installed on them before the upgrade. Jira: OAMG-7835 BZ#2219544 BZ#2140011

Praviously the check was implemented using OSError return from `run` function. However, in this particular case it's not safe and leads to unexpected behaviour. Check the existence of the file explicitly instead prior the `run` function is called. Update existing unit-tests and extend the test case when mdadm is not installed.

pirat89 · 2023-07-17T18:28:58Z

Tested manually

system without raid - w/o mdadm installed
system with raid (7 -> 8 -> 9): setup described https://bugzilla.redhat.com/show_bug.cgi?id=2219544

works as expected. merging.

pirat89

ltgm and works (see my comments)

See related leapp-repository PRs: * oamg/leapp-repository#1093 * oamg/leapp-repository#1097 * oamg/leapp-repository#1107

## Packaging - Requires leapp-framework 5.0 ## Upgrade handling ### Fixes - Add el8toel9 actor to handle directory -> symlink with ruby IRB. (oamg#1076) - Do not try to update GRUB core on IBM Z systems (oamg#1117) - Fix failing upgrades with devtmpfs file systems specified in FSTAB (oamg#1090) - Fix the calculation of the required free space on each partitions/volume for the upgrade transactions (oamg#1097) - Fix the generation of the report about hybrid images (oamg#1064) - Handle correctly the installed certificates to allow upgrades with custom repositories using HTTPs with enabled SSL verification (oamg#1106) - Minor improvements and fixes of various reports (oamg#1066, oamg#1067, oamg#1085) - Update error messages about leapp data files to inform user how to obtain valid data files (oamg#1121) - Update links in various reports (oamg#1062, oamg#1086) - Update the repomap data to cover changed repoids in RHUI Azure (oamg#1087) - [IPU 7 -> 8] Fix false positive report about invalid symlinks on RHEL 7 (oamg#1052) - [IPU 8 -> 9] Inhibit the upgrade when unsupported x86-64 microarchitecture is detected (oamg#1059) ### Enhancements - Include updated leapp data files in the RPM (oamg#1046, oamg#1092, oamg#1119) - Update the set of supported upgrade paths (oamg#1077): - RHEL with SAP HANA 7.9 -> 8.6, 8.8 (default: 8.6) - RHEL with SAP HANA 8.8 -> 9.2 - Introduce new upgrade paths: - RHEL 7.9 -> 8.9 (default) - RHEL 8.9 -> 9.3 - Correctly update grub2 when /boot resides on multiple devices aggregated in RAID (oamg#1093, oamg#1115) - Enable upgrades for machines using RHUI on AlibabaCloud (oamg#1088) - Introduce possibility to add kernel drivers to initramfs (oamg#1081) - Redesign handling of information about kernel (booted and target) in preparation for new changes in RHEL 9 (oamg#1107) - Redesign source system overlay to use disk images backed by sparse files to optimize disk space consumption (oamg#1097, oamg#1103) - Requires leapp-framework 5.0 (oamg#1061, oamg#1116) - Use new leapp CLI API which provides better report summary output (oamg#1061, oamg#1116) - [IPU 8 -> 9] Detect and report use of deprecated Xorg drivers (oamg#1078) - [IPU 8 -> 9] Introduce IPU for systems with FIPS enabled (oamg#1053) ## Additional changes interesting for devels - Deprecated `GrubInfo.orig_device_name` field in the `GrubInfo` model (replaced by `GrubInfo.orig_devices`) (oamg#1093) - Deprecated `InstalledTargetKernelVersion` model (replaced by `InstalledTargetKernelInfo`) (oamg#1107) - Deprecated `leapp.libraries.common.config.version.is_rhel_realtime` (check the type in msg `KernelInfo`, field `type`) (oamg#1107) - Deprecated `leapp.libraries.common.grub.get_grub_device()` (replaced by `leapp.libraries.common.grub.get_grub_devices()`) (oamg#1093) - Introduced new devel envar LEAPP_DEVEL_KEEP_DISK_IMGS=1 to skip the removal of the created disk images for OVL. That's sometimes handy for the debugging. (oamg#1097)

See related leapp-repository PRs: * oamg/leapp-repository#1093 * oamg/leapp-repository#1097 * oamg/leapp-repository#1107

## Packaging - Requires leapp-framework 5.0 ## Upgrade handling ### Fixes - Add el8toel9 actor to handle directory -> symlink with ruby IRB. (#1076) - Do not try to update GRUB core on IBM Z systems (#1117) - Fix failing upgrades with devtmpfs file systems specified in FSTAB (#1090) - Fix the calculation of the required free space on each partitions/volume for the upgrade transactions (#1097) - Fix the generation of the report about hybrid images (#1064) - Handle correctly the installed certificates to allow upgrades with custom repositories using HTTPs with enabled SSL verification (#1106) - Minor improvements and fixes of various reports (#1066, #1067, #1085) - Update error messages about leapp data files to inform user how to obtain valid data files (#1121) - Update links in various reports (#1062, #1086) - Update the repomap data to cover changed repoids in RHUI Azure (#1087) - [IPU 7 -> 8] Fix false positive report about invalid symlinks on RHEL 7 (#1052) - [IPU 8 -> 9] Inhibit the upgrade when unsupported x86-64 microarchitecture is detected (#1059) ### Enhancements - Include updated leapp data files in the RPM (#1046, #1092, #1119) - Update the set of supported upgrade paths (#1077): - RHEL with SAP HANA 7.9 -> 8.6, 8.8 (default: 8.6) - RHEL with SAP HANA 8.8 -> 9.2 - Introduce new upgrade paths: - RHEL 7.9 -> 8.9 (default) - RHEL 8.9 -> 9.3 - Correctly update grub2 when /boot resides on multiple devices aggregated in RAID (#1093, #1115) - Enable upgrades for machines using RHUI on AlibabaCloud (#1088) - Introduce possibility to add kernel drivers to initramfs (#1081) - Redesign handling of information about kernel (booted and target) in preparation for new changes in RHEL 9 (#1107) - Redesign source system overlay to use disk images backed by sparse files to optimize disk space consumption (#1097, #1103) - Requires leapp-framework 5.0 (#1061, #1116) - Use new leapp CLI API which provides better report summary output (#1061, #1116) - [IPU 8 -> 9] Detect and report use of deprecated Xorg drivers (#1078) - [IPU 8 -> 9] Introduce IPU for systems with FIPS enabled (#1053) ## Additional changes interesting for devels - Deprecated `GrubInfo.orig_device_name` field in the `GrubInfo` model (replaced by `GrubInfo.orig_devices`) (#1093) - Deprecated `InstalledTargetKernelVersion` model (replaced by `InstalledTargetKernelInfo`) (#1107) - Deprecated `leapp.libraries.common.config.version.is_rhel_realtime` (check the type in msg `KernelInfo`, field `type`) (#1107) - Deprecated `leapp.libraries.common.grub.get_grub_device()` (replaced by `leapp.libraries.common.grub.get_grub_devices()`) (#1093) - Introduced new devel envar LEAPP_DEVEL_KEEP_DISK_IMGS=1 to skip the removal of the created disk images for OVL. That's sometimes handy for the debugging. (#1097)

matejmatuska force-pushed the update-grub-raid branch from c21a763 to 60cc6cd Compare June 22, 2023 12:40

fernflower reviewed Jun 22, 2023

View reviewed changes

matejmatuska force-pushed the update-grub-raid branch 4 times, most recently from 3f48a58 to a9e00e3 Compare June 25, 2023 09:05

fernflower mentioned this pull request Jun 30, 2023

Packit config for leapp oamg/leapp#827

Merged

matejmatuska force-pushed the update-grub-raid branch from 2471fcc to 867f7f2 Compare June 30, 2023 09:12

matejmatuska marked this pull request as ready for review June 30, 2023 09:25

pirat89 requested changes Jul 3, 2023

View reviewed changes

pirat89 reviewed Jul 4, 2023

View reviewed changes

repos/system_upgrade/common/libraries/mdraid.py Outdated Show resolved Hide resolved

matejmatuska changed the title ~~Update Grub on component devices if /boot is on md device~~ Update Grub on component MBR drives if /boot is on mdraid device Jul 4, 2023

matejmatuska force-pushed the update-grub-raid branch 2 times, most recently from 27d837f to 026ead8 Compare July 7, 2023 11:15

pirat89 reviewed Jul 17, 2023

View reviewed changes

repos/system_upgrade/common/actors/scangrubdevice/actor.py Show resolved Hide resolved

pirat89 reviewed Jul 17, 2023

View reviewed changes

repos/system_upgrade/common/actors/updategrubcore/libraries/updategrubcore.py Show resolved Hide resolved

pirat89 reviewed Jul 17, 2023

View reviewed changes

repos/system_upgrade/common/libraries/grub.py Outdated Show resolved Hide resolved

pirat89 reviewed Jul 17, 2023

View reviewed changes

repos/system_upgrade/common/libraries/mdraid.py Outdated Show resolved Hide resolved

matejmatuska force-pushed the update-grub-raid branch from b5ed0de to c7b1e75 Compare July 17, 2023 14:11

matejmatuska changed the title ~~Update Grub on component MBR drives if /boot is on mdraid device~~ Update Grub on component devices if /boot is on mdraid device Jul 17, 2023

pirat89 force-pushed the update-grub-raid branch from aca9b54 to 50d06eb Compare July 17, 2023 17:12

pirat89 approved these changes Jul 17, 2023

View reviewed changes

pirat89 merged commit 2e85af5 into oamg:master Jul 17, 2023
11 of 15 checks passed

pirat89 added the bug Something isn't working label Jul 17, 2023

pirat89 added this to the 8.9/9.3 milestone Jul 17, 2023

pirat89 added the changelog-checked The merger/reviewer checked the changelog draft document and updated it when relevant label Jul 17, 2023

pirat89 mentioned this pull request Jul 17, 2023

Doing an EL8 to EL9 upgrade on raid1 /boot drives results in (potentially) unbootable system #1054

Closed

matejmatuska added the deprecation Any change in the set of deprecation functionality. label Aug 23, 2023

pirat89 added a commit to pirat89/leapp that referenced this pull request Aug 23, 2023

Doc: update deprecations and envars for leapp-repository v0.19.0

9ab56c6

See related leapp-repository PRs: * oamg/leapp-repository#1093 * oamg/leapp-repository#1097 * oamg/leapp-repository#1107

pirat89 mentioned this pull request Aug 23, 2023

Release 0.19.0 #1122

Merged

pirat89 added a commit to pirat89/leapp that referenced this pull request Aug 23, 2023

Doc: update deprecations and envars for leapp-repository v0.19.0

ca2e159

See related leapp-repository PRs: * oamg/leapp-repository#1093 * oamg/leapp-repository#1097 * oamg/leapp-repository#1107

Rezney pushed a commit to oamg/leapp that referenced this pull request Aug 23, 2023

Doc: update deprecations and envars for leapp-repository v0.19.0

1a68726

See related leapp-repository PRs: * oamg/leapp-repository#1093 * oamg/leapp-repository#1097 * oamg/leapp-repository#1107

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update Grub on component devices if /boot is on mdraid device #1093

Update Grub on component devices if /boot is on mdraid device #1093

matejmatuska commented Jun 22, 2023 •

edited

Loading

github-actions bot commented Jun 22, 2023

fernflower left a comment

matejmatuska commented Jun 25, 2023

matejmatuska commented Jun 30, 2023

pirat89 left a comment

pholica commented Jul 4, 2023

matejmatuska commented Jul 4, 2023 •

edited

Loading

pirat89 commented Jul 4, 2023

matejmatuska commented Jul 4, 2023 •

edited

Loading

pirat89 commented Jul 17, 2023

pirat89 commented Jul 17, 2023 •

edited

Loading

pirat89 commented Jul 17, 2023 •

edited

Loading

pirat89 left a comment

Update Grub on component devices if /boot is on mdraid device #1093

Update Grub on component devices if /boot is on mdraid device #1093

Conversation

matejmatuska commented Jun 22, 2023 • edited Loading

github-actions bot commented Jun 22, 2023

Thank you for contributing to the Leapp project!

fernflower left a comment

Choose a reason for hiding this comment

matejmatuska commented Jun 25, 2023

matejmatuska commented Jun 30, 2023

pirat89 left a comment

Choose a reason for hiding this comment

pholica commented Jul 4, 2023

matejmatuska commented Jul 4, 2023 • edited Loading

pirat89 commented Jul 4, 2023

matejmatuska commented Jul 4, 2023 • edited Loading

pirat89 commented Jul 17, 2023

pirat89 commented Jul 17, 2023 • edited Loading

pirat89 commented Jul 17, 2023 • edited Loading

pirat89 left a comment

Choose a reason for hiding this comment

matejmatuska commented Jun 22, 2023 •

edited

Loading

matejmatuska commented Jul 4, 2023 •

edited

Loading

matejmatuska commented Jul 4, 2023 •

edited

Loading

pirat89 commented Jul 17, 2023 •

edited

Loading

pirat89 commented Jul 17, 2023 •

edited

Loading