Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Gerd Hoffmann writes: ... >> I'm talking about removing shim from the boot flow. > > That is not a goal of this change proposal, and it's not up for debate > for phase #2. Maybe an option in a later phase, once we have a signed > systemd-boot (see below). Also, we have one more Fedora-specific problem: we can't create a new SB cert for signing UKIs so we're currently using the same cert as the traditional kernel. This works if you enroll the cert in DB but then these kernels are indistinguishable if you only look at PCR7, this complicates creating PCR policies a lot. The problem why we can't have a new SB certificate is not technical but organizational: currently, private parts of the certs are on physical cards which a few people have an issuing a new one is a real pain. Rumor has it this is going to change and I'd really like to have it included in 'phase #3'. In phase #2, we can probably add an option to 'uki-direct' to add UKIs without shim to Boot, this certainly won't be the default and will require Fedora cert to be enrolled into DB/MOK but for specific use-cases (e.g. AWS with provisioned varstore) this can be used. -- Vitaly -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)
Gerd Hoffmann writes: > Hi, > >> Does that mean that the Linux EFI boot code knows how to call back to >> shim to get the certificates instead of reading the firmware directly? > > No. The linux efi stub doesn't need that. > > shim.efi does: > > (a) Set efi variables, where the linux kernel can read the > certificates from. This works the same way for both traditional > kernels and UKIs. > > (b) provide an efi protocol for bootloaders, which can be called by grub > and systemd-boot to verify the signature for binaries they load > (typically the linux kernel, but could also be fwupd.efi). Note, the protocol is also used by systemd-stub (the base for UKIs) to verify cmdline addons, see commit 05c9f9c2517c54b98d55f08f8afa67c79be861e8 Author: Luca Boccassi Date: Fri May 12 00:55:58 2023 +0100 stub: allow loading and verifying cmdline addons this AFAIU means that we also need shim in the boot chain if we want to support these addons. -- Vitaly -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LoadOptions handling in rhboot/shim fallback.c
Mike Beaton writes: > Vitaly Kuznetsov has offered https://github.com/rhboot/shim/pull/611 > to fix the NVRAM entry generated by `add_boot_option(...)` in Shim's > `fallback.c`. > > It is quite pervasive in that file to treat the size of the loaded > image arguments as `StrLen(arguments) * 2` (just search for > `StrLen(arguments)`, since `StrLen(arguments) * sizeof (CHAR16)` is > also used) - so the issue identified in the PR affects > `find_boot_option(...)` as well as add_boot_option(...)`. > > Additionally, while the PR does not currently address this, > `image->LoadOptionsSize` should include the size of the `CHAR_NULL` > terminator of `image->LoadOptions` (when `arguments` is non-empty), so > I believe the `first_new_option_size` handling in the file needs > updating in a similar manner too. Indeed, let me update my MR accordingly. Thanks! -- Vitaly ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Taskotron and Cloud Image tests
Vitaly Kuznetsov vi...@redhat.com writes: Hi Tim all, in Cloud WG we have 'Automatic Smoketests on Image Build' task: https://fedorahosted.org/cloud/ticket/38 AFAIK you have somehting similar among future Taskotron goals. It would be nice if we can collaborate here. By writing this message I just want to start the conversation :-) For RHEL cloud image checks we have special tool called 'valid': https://github.com/RedHatQE/valid , it can be reused for Fedora as well. The questions are: how do you see the integration and how can someone (me?) work on this (non-existent atm) part of Taskotron. I can see two possible approaches: 1) 'Easy'. We create special type of task (sorry if I'm not that precise with terminology) which is being executed on static slave node which runs valid (in black-box mode) on newly uploaded image, grabs the result and returns it back. 2) 'Hard'. We work on 'ephemeral task clients' (term from http://tirfa.com/an-initial-idea-for-taskbot.html). The benefit here is that in that case we can run any test on a cloud VM. This approach will require some optimization from the very beginning, at least: 1. One VM should be user for multiple tests (so several dozens of image tests won't require several dozens of VMs created) 2. Tests should be able to 'control' VM (e.g. use cloud-specific features: attach device, reboot VM,...) - that can be workarounded by providing cloud credential inside the VM itself but that doesn't sound that attractive. Yesterday I've tried setting up Taskotron (according to http://roshi.fedorapeople.org/dexy-themed/) on 3 F20 VMs in EC2 and actually I've failed (some ansible playbooks are out-of-sync with some git repos, e.g. 'master playbook' is failing with 'stderr: cp: cannot stat '/home/qaadmin/trigger/jobtrigger.py': No such file or directory' in 'TASK: [copy fedmsg config]'. I totally understand these instructions and repos are rather proof-of-concept and can be slightly outdated but I want to ask about 'minimalistic one-host dev environment' setup anyway. Can 'Host' be eliminated from the setup completely and can we merge Master and Slave (in case we'll need it for 'cloud') on one host? That would help a lot. I'm looking forward to hearing from you. Sorry to bug you again about this, am I completely out of sync with whatever is going on? I would really appreciate your comments.. -- Vitaly Kuznetsov ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: F21 Self Contained Change: Replace Bacula with Bareos
Kevin Kofler kevin.kof...@chello.at writes: Simone Caronni wrote: http://www.mail-archive.com/bacula-users@lists.sourceforge.net/msg57308.html Hmmm, that guy is painting a somewhat different picture of the situation of the 2 projects than your Change page. In particular, he claims the community version is not dead. (Is that credible?) (He does admit that Bacula is using the crippleware business model though.) His vague allegations of copyright infringement in Bareos lack any kind of details required to verify them though. Kern wrote new letter to the community explaining his point of view, it is available here: http://www.bacula.org/en/?page=news -- Vitaly Kuznetsov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20 TC4 AMIs
Matthew Miller mat...@fedoraproject.org writes: On Tue, Dec 03, 2013 at 04:42:44PM +0100, Vitaly Kuznetsov wrote: The only issue compared to TC3 is one more file with wrong selinux context (/var/log/cron). So, for TC4: # restorecon -R -v -n -e /proc -e /sys -e /dev -e/run -e/tmp / restorecon reset /var/log/cron context system_u:object_r:var_log_t:s0-system_u:object_r:cron_log_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0-system_u:object_r:plymouthd_var_log_t:s0 These files don't exist initially -- I expect that just creating them before the fixfiles is run in the kickstart should do it. restorecon reset /var/cache/yum context system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 This _does_ exist, though, so it's more of a puzzle. Any guesses? restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0 And this is because it's immutable. not sure if it deserves BZ and against what if it does. Last time I created https://bugzilla.redhat.com/show_bug.cgi?id=1033274 against anaconda but it seems misplaced. Since we're building with appliance-creator, anaconda isn't involved. That will change in the future In the meantime, we have to hack around it with kickstart kludges. Can you test http://mattdm.fedorapeople.org/tmp/Fedora20-sda.qcow2 to see if it's any better? It definitely is: restorecon -R -v -n -e /proc -e /sys -e /dev -e/run -e/tmp / restorecon reset /mnt context unconfined_u:object_r:default_t:s0-unconfined_u:object_r:mnt_t:s0 restorecon reset /var/cache/yum context unconfined_u:object_r:file_t:s0-unconfined_u:object_r:rpm_var_cache_t:s0 But that's kvm. Unless cloud-init does some nasty magick in EC2 we're ok) BTW, our cloud-init is slighly outdated (0.7.4 is out for couple of weeks). -- Vitaly Kuznetsov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20 TC4 AMIs
Dennis Gilmore den...@ausil.us writes: Hi all, Final TC4 images have been uploaded to EC2 and are available at ami-955476fc : us-east-1 image for i386 ami-c95476a0 : us-east-1 image for x86_64 The only issue compared to TC3 is one more file with wrong selinux context (/var/log/cron). So, for TC4: # restorecon -R -v -n -e /proc -e /sys -e /dev -e/run -e/tmp / restorecon reset /var/log/cron context system_u:object_r:var_log_t:s0-system_u:object_r:cron_log_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0-system_u:object_r:plymouthd_var_log_t:s0 restorecon reset /var/cache/yum context system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0 for TC3 it was: # restorecon -R -v -n -e /proc -e /sys -e /dev -e/run -e/tmp / restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0-system_u:object_r:plymouthd_var_log_t:s0 restorecon reset /var/cache/yum context system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 not sure if it deserves BZ and against what if it does. Last time I created https://bugzilla.redhat.com/show_bug.cgi?id=1033274 against anaconda but it seems misplaced. -- Vitaly Kuznetsov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20 TC3 AMIs
Dennis Gilmore den...@ausil.us writes: Hi all, Final TC3 images have been uploaded to EC2 and are available at ami-c17858a8 : us-east-1 image for i386 ami-6578580c : us-east-1 image for x86_64 I'm getting not authorized for AMI ami-c17858a8 in us-east-1 and not authorized for AMI ami-6578580c in us-east-1 so there is definitely something wrong with permissions.. -- Vitaly Kuznetsov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20 TC2 AMIs
Matthew Miller mat...@fedoraproject.org writes: On Thu, Nov 21, 2013 at 01:30:15PM +0100, Vitaly Kuznetsov wrote: I ran basic tests agains them and they're ok. The only issue I still see is wrong SELinux context for several files: # restorecon -Rvn -e/dev -e/proc -e/sys -e/run -e/tmp/ / restorecon reset /var/cache/yum context system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0-system_u:object_r:plymouthd_var_log_t:s0 restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0 That's weird. We're running fixfiles at the end of the build process to clean up anything like that. I looked into kickstart, you do '/usr/sbin/fixfiles -R -a restore'. I tried running it manually on fresh instance: # /usr/sbin/fixfiles -R -a restore 75k/sbin/restorecon set context /boot/extlinux/ldlinux.sys-system_u:object_r:boot_t:s0 failed:'Operation not permitted' 80k/sbin/restorecon set context /boot/extlinux/ldlinux.sys-system_u:object_r:boot_t:s0 failed:'Operation not permitted' 177k/sbin/restorecon set context /boot/extlinux/ldlinux.sys-system_u:object_r:boot_t:s0 failed:'Operation not permitted' However /boot/extlinux/ldlinux.sys is the only file needs fixind after this: # restorecon -Rvn -e/dev -e/proc -e/sys -e/run -e/tmp/ / restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0 Anyway, https://bugzilla.redhat.com/show_bug.cgi?id=1033274 as suggested by dwalsh) -- Vitaly Kuznetsov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20 TC2 AMIs
Dennis Gilmore den...@ausil.us writes: Hi all, Final TC2 images have been uploaded to EC2 and are available at ami-3392b55a : us-east-1 image for i386 ami-f794b39e : us-east-1 image for x86_64 I ran basic tests agains them and they're ok. The only issue I still see is wrong SELinux context for several files: # restorecon -Rvn -e/dev -e/proc -e/sys -e/run -e/tmp/ / restorecon reset /var/cache/yum context system_u:object_r:file_t:s0-system_u:object_r:rpm_var_cache_t:s0 restorecon reset /var/log/boot.log context system_u:object_r:var_log_t:s0-system_u:object_r:plymouthd_var_log_t:s0 restorecon reset /boot/extlinux/ldlinux.sys context system_u:object_r:file_t:s0-system_u:object_r:boot_t:s0 -- Vitaly Kuznetsov -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
