Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

install: Use zipl to install bootloader on s390x #665

Merged
merged 2 commits into from
Jul 17, 2024

Conversation

yoheiueda
Copy link
Contributor

This is a part of s390x enablement #569

Currently, the zipl command is called via libostree to install bootloader on s390x, but it does not work correctly on a loop device.

This patch changes bootc to execute the zipl command directly with appropriate command line options for installation on a loop device.

@github-actions github-actions bot added the area/install Issues related to `bootc install` label Jul 3, 2024
Copy link
Collaborator

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much for working on this! I have some style/structural nits but I think we're heading in the right direction.

lib/src/bootloader.rs Outdated Show resolved Hide resolved
lib/src/bootloader.rs Outdated Show resolved Hide resolved
lib/src/bootloader.rs Show resolved Hide resolved
lib/src/bootloader.rs Outdated Show resolved Hide resolved
}
};

let image_path = boot_dir.join(image.trim_start_matches('/')).canonicalize_utf8()?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did something specifically motivate the .canonicalize_utf8() here out of curiosity?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

canonicalize_utf8 is just a cosmetic, nice-to-have thing here.

When the target filesystem is /boot, image_path becomes something like /run/bootc/mounts/rootfs/boot/boot/ostree/.... boot directory appears twice in the path, and the second boot directory is actually a symlink to ..

This path representation is OK for zipl to work correctly, but looks a little bit strange. So I use canonicalize_utf8 to remove the duplicated boot from the path.

@@ -1229,7 +1223,12 @@ async fn install_to_filesystem_impl(state: &State, rootfs: &mut RootSetup) -> Re
.context("Writing aleph version")?;
}

crate::bootloader::install_via_bootupd(&rootfs.device, &rootfs.rootfs, &state.config_opts)?;
if cfg!(target_arch = "s390x") {
// TODO: Integrate s390x support into install_via_bootupd
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah...that would definitely be better in the longer term I think, but this is totally fine to do here for now. See also coreos/bootupd#432

@@ -572,15 +572,9 @@ async fn initialize_ostree_root_from_self(
crate::lsm::ensure_dir_labeled(rootfs_dir, "boot", None, 0o755.into(), sepolicy)?;
}

// Default to avoiding grub2-mkconfig etc., but we need to use zipl on s390x.
// TODO: Lower this logic into ostree proper.
let bootloader = if cfg!(target_arch = "s390x") {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this means we're now relying on ostreedev/ostree@e3d93a8 which should be fine.

@cgwalters
Copy link
Collaborator

@yoheiueda let me know if you want me to take a pass at updating this PR

@yoheiueda
Copy link
Contributor Author

@cgwalters I am working on this. I will update the patch this week.

BTW, lsblk does not show an partition offset in a disk in my environment. Do you have any idea how to get partition offset info with lsblk?

@cgwalters
Copy link
Collaborator

BTW, lsblk does not show an partition offset in a disk in my environment. Do you have any idea how to get partition offset info with lsblk?

Just briefly looking at lsblk -J -O /dev/vda in a virt environment I see a start attribute; does that not exist for dasd?

@yoheiueda
Copy link
Contributor Author

lsblk from util-linux 2.37.4 (RHEL 9.4) does not have start attribute, but lsblk from util-linux 2.40.1 (Fedora 40) does have the attribute.

util-linux/util-linux@856457b

It looks like the start attribute has been introduced from 2.38.

@cgwalters do you think it is safe to assume that the newer lsblk? I think the commit needs to be backported to RHEL eventually if we use this command.

@jlebon
Copy link
Contributor

jlebon commented Jul 10, 2024

It might be in sfdisk -J since that one actually reads the GPT header.

You can also look at the start file in sysfs directly too.

@cgwalters
Copy link
Collaborator

@cgwalters do you think it is safe to assume that the newer lsblk? I think the commit needs to be backported to RHEL eventually if we use this command.

We need to support whatever is in C9S for code we land today as a baseline. So we could ask for that to be backported.

But, I think it's easiest for now to go with what jlebon suggested, and maybe also queue a backport request.

@yoheiueda
Copy link
Contributor Author

@cgwalters @jlebon thank you for your suggestions. I will use /sys/dev/<maj:min>/start to get a partition offset.

lib/src/bootloader.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is overall looking good!

lib/src/bootloader.rs Outdated Show resolved Hide resolved
lib/src/bootloader.rs Outdated Show resolved Hide resolved
lib/src/bootloader.rs Outdated Show resolved Hide resolved
lib/src/bootloader.rs Outdated Show resolved Hide resolved
lib/src/bootloader.rs Outdated Show resolved Hide resolved
lib/src/bootloader.rs Outdated Show resolved Hide resolved
@cgwalters
Copy link
Collaborator

cgwalters commented Jul 13, 2024

xref #667 (comment)

Specifically on this PR, we all the preparatory changes should be there now in the blockdev bits - do you want to rebase this one on #680 ?

Note specifically for example 61feba4 I think is cleaner.

As of now, if we land #680 first then this PR should no longer textually conflict with #667 at least and they can land in either order.

@yoheiueda
Copy link
Contributor Author

@cgwalters thank you for the new PR. It looks good.

I'll rebase this PR on #680.

@yoheiueda
Copy link
Contributor Author

@cgwalters Ive rebased this PR on #688

Comment on lines +34 to +60
// Identify the target boot partition from UUID
let fs = crate::mount::inspect_filesystem_by_uuid(boot_uuid)?;
let boot_dir = Utf8Path::new(&fs.target);
let maj_min = fs.maj_min;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just looking at this a bit more closely...I think this is fine for now, but what I think we should do instead as a followup is just pass a Dir (file descriptor) for the boot as we mounted it. Then we can probably use findmnt -J . on it or so.

This patch adds a new function that identifies a filesystem by
partition UUID.

Signed-off-by: Yohei Ueda <yohei@jp.ibm.com>
Signed-off-by: Colin Walters <walters@verbum.org>
Running zipl via ostree does not work correctly on a loop deivce.
This patch changes bootc to execute zipl directly with appropriate
command line options for installation on a loop device.

Signed-off-by: Yohei Ueda <yohei@jp.ibm.com>
@cgwalters
Copy link
Collaborator

(I resolved the trivial conflict with #667 )

@cgwalters cgwalters enabled auto-merge July 17, 2024 14:13
@cgwalters cgwalters merged commit 80d102d into containers:main Jul 17, 2024
17 of 27 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/install Issues related to `bootc install`
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants