Project

General

Profile

Actions

action #87988

closed

[SLE-17186][SLE-17185] Bootloader setup in YaST should follow the identification method as mount method

Added by riafarov over 3 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
SUSE QA - SLE 15 SP3
Start date:
2021-02-11
Due date:
% Done:

0%

Estimated time:

Description

See https://jira.suse.com/browse/SLE-17081

https://trello.com/c/Ow3Vlrmx/1734-2-second-part-of-sle-17081-unification-of-yast2-bootloader-udev-code-try-again

https://trello.com/c/L8Xiojzb/2215-3-first-part-of-sle-17081-enforce-uuid-for-new-swap-partitions

Part for swap partitions was tested by riafarov for other feature. fstab entries have to be still validated.

As always, proposal for automation should be files as a ticket for qe-yast project.


Content of trello cards:

We are using [SLE-17081](https://jira.suse.com/browse/SLE-17081) as an opportunity to bring this card back to $CURRENT (we wanted to do it for SLE-15-SP3 anyways).

This card was originally created as a follow-up of https://trello.com/c/SFYLkAIX/, that was a follow-up/consequence of https://trello.com/c/TyCrUgrP/

yast-bootloader contains logic for finding the preferred (most stable) device name to reference a device. See https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/udev_mapping.rb#L47 and implementation at https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/udev_mapping.rb#L110

It makes sense for yast-bootloader to just rely on yast-storage-ng instead of implementing the logic on its own. Of course, the yast-storage-ng API may need some refinements to make it possible.

Tip: `MountByType.best_for` contains the related logic in yast-storage-ng

See also https://bugzilla.suse.com/show_bug.cgi?id=1169874.

## Testing opportunity

Let's use this as an opportunity to manually test the FULL installation process to check how this works together with:

- https://trello.com/c/L8Xiojzb/
- https://github.com/yast/yast-yast2/pull/1126 - [bsc#1169874](https://bugzilla.suse.com/show_bug.cgi?id=1169874)
- https://github.com/openSUSE/libstorage-ng/pull/790 - [bsc#1180560](https://bugzilla.suse.com/show_bug.cgi?id=1180560)


## Review

- PR for storage-ng (includes a lot of info): https://github.com/yast/yast-storage-ng/pull/1196
- PR for bootloader: https://github.com/yast/yast-bootloader/pull/628
- Logic to determine the better available name moved to `BlkDevice#preferred_name` and `BlkFilesystem#preferred_name`.
- Tested manually (with a dud including both PRs and the most recent libstorage-ng, and yast2.rpm)
  - Full installation of Tumbleweed with role XFCE and default settings (verified everything works and it includes the `resume=/dev/disk/by-uuid/xxyyzz` parameter)
  - Full installation of Tumbleweed with role XFCE changing default mount_by to path (verified everything works and it includes the `resume=/dev/disk/by-path/aa:bb-cc` parameter)
See [SLE-17081](https://jira.suse.com/browse/SLE-17081), which is a follow-up of [bug#1177926](https://bugzilla.suse.com/show_bug.cgi?id=1177926), which is basically the same as [bsc#1169874](https://bugzilla.suse.com/show_bug.cgi?id=1169874).

The problem is about using "resume=/dev/disk/by-id/$whatever" in the bootloader line. The bootloader proposal indeed tries to use UUID in most situations. See https://github.com/yast/yast-bootloader/blob/master/src/lib/bootloader/udev_mapping.rb#L47

But the problem is that, in most cases, the swap device is still not created in the moment the bootloader proposal is calculated. Thus the UUID is not known and the bootloader proposal falls back to another identification method.

This card is about imply enforcing an UUID for all new swap devices, instead of delegating the generation of the UUID to mkfs.

### Review

- https://github.com/yast/yast-storage-ng/pull/1192 (includes description and screenshot)
- Other problems found during manual testing:
  - [bug#1180218](https://bugzilla.suse.com/show_bug.cgi?id=1180218): bootloader proposal cannot handle changes in the swap device
  - [bug#1180222](https://bugzilla.suse.com/show_bug.cgi?id=1180222): reusing UUIDs of deleted swaps does not work in all cases

Related issues 1 (0 open1 closed)

Related to qe-yam - action #88533: automate verifying/setting the default mount_by option in partitionerResolvedsyrianidou_sofia2021-02-11

Actions
Actions #1

Updated by riafarov over 3 years ago

  • Tracker changed from coordination to action
Actions #2

Updated by riafarov about 3 years ago

  • Status changed from New to Workable
Actions #3

Updated by JRivrain about 3 years ago

  • Assignee set to JRivrain
Actions #4

Updated by JRivrain about 3 years ago

  • Status changed from Workable to In Progress
Actions #5

Updated by JRivrain about 3 years ago

  • Status changed from In Progress to Feedback

It took me some time to figure out what really needed testing here, I tested some un-related things by misunderstanding. after consulting Yast teams, it seems like the relevant things to test were the following:

  • if we set the "mount_by" option in the partitioner the partitions created after are effectively mounted by the specified method, and the resume=option is using the specified method too, however, the root= option is still using UUID.
  • by default, the system is using UUID, and the resume option uses it too.

Other related things tested:

  • The resume option is proposed for opensuse, not SLE, see https://jira.suse.com/browse/SLE-12280
  • In a VM with TW, booting with "resume" option always seems to work, whatever "mount_by" option used
  • If we clone the system, the same value for "resume" is in the cloned system (if it was /dev/vda3, it will remain so)
  • changing the mount_by method for a specific device in partitioner edits the fstab file accordingly.

So the feature, despite being a bit confusing, works as expected. No bugs found.

Actions #6

Updated by JRivrain about 3 years ago

I think it's mostly not worth automating, as we don't use hibernation at all in our test environment, as it's all either VM or server/mainframe hardware.

But we could check that "if we set the "mount_by" option in the partitioner the partitions created after are effectively mounted by the specified method", and that the UUID is the default mount_by option.

Actions #7

Updated by riafarov about 3 years ago

  • Related to action #88533: automate verifying/setting the default mount_by option in partitioner added
Actions #8

Updated by riafarov about 3 years ago

  • Status changed from Feedback to Closed

I believe we can resolve this one. I've added this ticket as related to #88533 as automation is independent activity and we can resolve item for the feature testing at least.
Thanks!

Actions

Also available in: Atom PDF