Re: Trying out a unified kernel image

2024-08-08 Thread Vitaly Kuznetsov
Julian Sikorski writes: > Am 07.08.24 um 14:32 schrieb Julian Sikorski: >> >> >> Am 06.08.24 um 10:15 schrieb Julian Sikorski: >>> >>> >>> Am 06.08.24 um 09:37 schrieb Vitaly Kuznetsov: >>>> Julian Sikorski writes: >>>

Re: Trying out a unified kernel image

2024-08-06 Thread Vitaly Kuznetsov
Julian Sikorski writes: > Am 05.08.24 um 11:07 schrieb Vitaly Kuznetsov: >> Julian Sikorski writes: >> >>> Hi list, >>> >>> I recently got curious about unified kernel images and what they bring >>> to the table. While informing myself ab

Re: Trying out a unified kernel image

2024-08-05 Thread Vitaly Kuznetsov
Julian Sikorski writes: > Hi list, > > I recently got curious about unified kernel images and what they bring > to the table. While informing myself about these, the following > questions came to mind: > - ESP partition size: my laptop has it set at 260 MB by the laptop > vendor, my desktop ha

Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

2023-12-20 Thread Vitaly Kuznetsov
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

Re: F40 Change Proposal: Unified Kernel Support Phase Two (System-Wide)

2023-12-06 Thread Vitaly Kuznetsov
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

Re: LoadOptions handling in rhboot/shim fallback.c

2023-09-21 Thread Vitaly Kuznetsov
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

Re: F21 Self Contained Change: Replace Bacula with Bareos

2013-12-13 Thread Vitaly Kuznetsov
mmunity 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

2013-12-04 Thread Vitaly Kuznetsov
Matthew Miller 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

Re: Fedora 20 TC4 AMIs

2013-12-03 Thread Vitaly Kuznetsov
um 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.fedorap

Re: Fedora 20 TC3 AMIs

2013-11-28 Thread Vitaly Kuznetsov
"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

2013-11-21 Thread Vitaly Kuznetsov
: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 Conduc

Re: Fedora 20 TC2 AMIs

2013-11-21 Thread Vitaly Kuznetsov
Matthew Miller 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/sy