On Sun, Jul 05, 2020 at 01:11:08AM -0700, John M. Harris Jr wrote:
> On Sunday, July 5, 2020 1:03:34 AM MST Luya Tshimbalanga wrote:
> > It would be great that the installer, Anaconda, enables sd-boot for
> > users running on UEFI system. The method was done before with both LILO
> > and Grub dec
On Mon, 2020-07-06 at 13:31 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > btw, sd-boot has a few tricks up its sleeve: if during boot you
> > > keep
> > > "w" pressed down it will automatically boot into windows, similar
> > > if
> > > you keep "l" pressed down it will automaticall boot into linux,
On Mon, 6 Jul 2020 at 07:38, Gerd Hoffmann wrote:
>
> Hi,
>
> > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep
> > > "w" pressed down it will automatically boot into windows, similar if
> > > you keep "l" pressed down it will automaticall boot into linux, "a"
> > > will b
On Mon, Jul 06, 2020 at 01:31:30PM +0200, Gerd Hoffmann wrote:
> The BIOS provides block device access at sector level, so the boot
> loader has little choice but implementing drivers for all kinds of
> stuff. Or use fragile block lists like lilo did in the last century.
>
> With UEFI much more f
Hi,
> I have no problem with GRUB2 or sd-boot. I have much more problems
> with refind and their ilk. While things can look pretty, that's fine,
> as soon as it gets in my way when I try to get things done it stops
> being fine.
"getting into the way" IMO includes "doesn't show up on the serial
Hi,
> > btw, sd-boot has a few tricks up its sleeve: if during boot you keep
> > "w" pressed down it will automatically boot into windows, similar if
> > you keep "l" pressed down it will automaticall boot into linux, "a"
> > will boot into macos, all without showing any UI at all. This means
>
On 5.7.2020 19:31, Solomon Peachy wrote:
On Sun, Jul 05, 2020 at 07:18:47PM -, Tom Seewald wrote:
In terms of physical x86 systems, you are right that UEFI is the
overwhelming majority. But as stated elsewhere in this thread, a lot
of cloud providers and virtualization software default to us
On 5.7.2020 18:34, Javier Martinez Canillas wrote:
On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering wrote:
[snip]
Please submit additions to the spec as PRs to systemd github. We added
a number of new keys in the past that sd-boot itself doesn't make use
of (devicetree and such), and we'd be
On Sun, 2020-07-05 at 11:50 -0700, John M. Harris Jr wrote:
> On Sunday, July 5, 2020 11:31:41 AM MST Solomon Peachy wrote:
> > On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote:
> > > Chromebook devices are neither UEFI nor BIOS. You can use GPT
> > > disk layout
> > > while still
On Sunday, July 5, 2020 12:18:46 PM MST Solomon Peachy wrote:
> On Sat, Jul 04, 2020 at 09:51:30PM -0700, John M. Harris Jr wrote:
> > Many people on this very thread are still using BIOS boot systems, and one
> > person provided a source for a NEW system they're using which is BIOS
> > boot,
> > w
On Sun, Jul 05, 2020 at 07:18:47PM -, Tom Seewald wrote:
> In terms of physical x86 systems, you are right that UEFI is the
> overwhelming majority. But as stated elsewhere in this thread, a lot
> of cloud providers and virtualization software default to using BIOS.
> So I think Fedora shoul
On Sat, Jul 04, 2020 at 09:51:30PM -0700, John M. Harris Jr wrote:
> Many people on this very thread are still using BIOS boot systems, and one
> person provided a source for a NEW system they're using which is BIOS boot,
> while another provided factory-default BIOS configurations on hardware
> su
> BIOS-based systems make up a miniscule minority of the current market.
> Pretending otherwise is delusional, and delusions are no basis for
> technical decisions.
>
> - Solomon
In terms of physical x86 systems, you are right that UEFI is the overwhelming
majority. But as stated elsewhere i
On Sun, Jul 5, 2020 at 12:41 PM Nicolas Mailhot via devel
wrote:
>
> Le dimanche 05 juillet 2020 à 12:21 -0600, Chris Murphy a écrit :
> >
> > specification != standard
>
> I, for one, am very happy that the systemd project makes the effort of
> documenting its formats so others can write competin
On Sunday, July 5, 2020 11:31:41 AM MST Solomon Peachy wrote:
> On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote:
> > Chromebook devices are neither UEFI nor BIOS. You can use GPT disk layout
> > while still booting BIOS, which they also don't do. Chromebook devices
> > either boot
Le dimanche 05 juillet 2020 à 12:21 -0600, Chris Murphy a écrit :
>
> specification != standard
I, for one, am very happy that the systemd project makes the effort of
documenting its formats so others can write competing implementations
or write software that interacts with the systemd implementa
On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering wrote:
[snip]
>
> Please submit additions to the spec as PRs to systemd github. We added
> a number of new keys in the past that sd-boot itself doesn't make use
> of (devicetree and such), and we'd be delighted to add more if they
> make sense an
On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote:
> Chromebook devices are neither UEFI nor BIOS. You can use GPT disk layout
> while still booting BIOS, which they also don't do. Chromebook devices either
> boot with uboot -> depthcharge or Coreboot -> uboot -> depthcharge. I do
On Sun, Jul 5, 2020 at 11:26 AM John M. Harris Jr wrote:
>
> On Sunday, July 5, 2020 3:07:44 AM MST Lennart Poettering wrote:
> > On Sa, 04.07.20 18:11, John M. Harris Jr (joh...@splentity.com) wrote:
> >
> >
> > > That systemd throws some crap out doesn't make it a standard. There's no
> > > reas
On Sunday, July 5, 2020 8:12:33 AM MST Markus Larsson wrote:
> I have no problem with GRUB2 or sd-boot. I have much more problems with
> refind and their ilk. While things can look pretty, that's fine, as soon as
> it gets in my way when I try to get things done it stops being fine.
I don't think
On Sunday, July 5, 2020 3:07:44 AM MST Lennart Poettering wrote:
> On Sa, 04.07.20 18:11, John M. Harris Jr (joh...@splentity.com) wrote:
>
>
> > That systemd throws some crap out doesn't make it a standard. There's no
> > reason for GRUB to adopt this, or for anyone else to use this.
>
>
> "bl
On Sunday, July 5, 2020 6:18:50 AM MST Solomon Peachy wrote:
> On Sun, Jul 05, 2020 at 08:52:12AM +0200, Nicolas Mailhot via devel wrote:
> > So you want to discuss Linux desktop deployments, excluding the only
> > sucessful mass Linux desktop deployment to date? Why?
>
> Because the raw data I ha
On Sun, 5 Jul 2020 at 11:23, Markus Larsson wrote:
>
>
>
> On 5 July 2020 16:27:07 CEST, Stephen John Smoogen wrote:
> >On Sat, 4 Jul 2020 at 11:34, Neal Gompa wrote:
> >>
> >> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering
> >> wrote:
> >> >
> >> > On Mi, 01.07.20 21:06, Neal Gompa (ngomp
On 5 July 2020 16:27:07 CEST, Stephen John Smoogen wrote:
>On Sat, 4 Jul 2020 at 11:34, Neal Gompa wrote:
>>
>> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering
>> wrote:
>> >
>> > On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote:
>> >
>> > > The user-interactive portion of sd-b
On Sat, 4 Jul 2020 at 11:34, Neal Gompa wrote:
>
> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering
> wrote:
> >
> > On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > The user-interactive portion of sd-boot is *awful*. I know our GRUB
> > > looks ugly by default these day
On Sun, Jul 05, 2020 at 08:41:16AM +0200, Nicolas Mailhot via devel wrote:
> Those things are not meant to run ancient software. They are meant to
> run a very long time. And yes at the end of this time the software is
> ancient.
Of course.
> That does not mean it is ancient at the start of the
I don't know about how important EFI and reducing the bootloader technical debt
is for the project, but at least for me personally, it will be a straight way
out. My hard disk has a traditional MBR based structure with about a TB of very
important data. I don't know of a 100% reliable way of con
On Sun, Jul 05, 2020 at 08:52:12AM +0200, Nicolas Mailhot via devel wrote:
> So you want to discuss Linux desktop deployments, excluding the only
> sucessful mass Linux desktop deployment to date? Why?
Because the raw data I had access to excludes chromebooks, only listing
"traditional" PCs and s
On Sa, 04.07.20 12:49, Chris Murphy (li...@colorremedies.com) wrote:
> Why do the security folks want POSIX and SELinux labels on the
> contents of /boot? I've never really gotten a straight answer on this,
> but I know it's considered important and a sticking point for why some
> folks do not wan
On Sa, 04.07.20 18:11, John M. Harris Jr (joh...@splentity.com) wrote:
> That systemd throws some crap out doesn't make it a standard. There's no
> reason for GRUB to adopt this, or for anyone else to use this.
"bloat", "crap", …
I am sorry, but you are apparently just a troll and this is the po
On Sunday, July 5, 2020 1:03:34 AM MST Luya Tshimbalanga wrote:
> It would be great that the installer, Anaconda, enables sd-boot for
> users running on UEFI system. The method was done before with both LILO
> and Grub decades ago and it was very surprising very few thought of that
> process esp
It would be great that the installer, Anaconda, enables sd-boot for
users running on UEFI system. The method was done before with both LILO
and Grub decades ago and it was very surprising very few thought of that
process especially for a distribution aiming to use latest technology.
The questi
Le samedi 04 juillet 2020 à 23:10 -0400, Solomon Peachy a écrit :
> (Note this explicitly excludes Chromebooks)
So you want to discuss Linux desktop deployments, excluding the only
sucessful mass Linux desktop deployment to date? Why?
Also your data conflates systems sold in with systems in
Le samedi 04 juillet 2020 à 23:10 -0400, Solomon Peachy a écrit :
> folks that make very long-lifecycle industrial systems
> meant to run generally ancient software
Those things are not meant to run ancient software. They are meant to
run a very long time. And yes at the end of this time the sof
On Saturday, July 4, 2020 8:10:49 PM MST Solomon Peachy wrote:
> On Sat, Jul 04, 2020 at 05:24:05PM -0700, John M. Harris Jr wrote:
> > There are still new systems built today that only support BIOS, and
> > vendors
> > providing systems factory-configured for BIOS boot on hardware that does
> > su
On Sat, Jul 04, 2020 at 05:24:05PM -0700, John M. Harris Jr wrote:
> There are still new systems built today that only support BIOS, and vendors
> providing systems factory-configured for BIOS boot on hardware that does
> support UEFI.
Lots of hardware has a very long tail -- For example, Intel
On Saturday, July 4, 2020 8:59:09 AM MST Lennart Poettering wrote:
> You can always enter its UI if you like, which is useful if the OS you
> come from doesn't support the interfaces as well as Linux does.
That should really be the default, as with the default, sane, bootloader..
> BTW, I think
On Saturday, July 4, 2020 9:19:34 AM MST Lennart Poettering wrote:
> If it way my decision I'd propose the following as the path to the
> future:
>
> 1. Unify/standardize on the boot loader spec, not the boot loader
>
> 2. Let's use UEFI as model and make MBR boots more alike UEFI then the
>o
On Saturday, July 4, 2020 6:44:55 AM MST Solomon Peachy wrote:
> On Sat, Jul 04, 2020 at 01:24:46PM -, ziba wrote:
> > Fedora should absolutely CONTINUE supporting BIOS boot (sometimes wrongly
> > labeled "legacy BIOS").
>
> Yep, Fedora should continue supporting BIOS boot at least for the n
On Sat, Jul 4, 2020 at 10:19 AM Lennart Poettering wrote:
> If it way my decision I'd propose the following as the path to the
> future:
>
> 1. Unify/standardize on the boot loader spec, not the boot loader
>
> 2. Let's use UEFI as model and make MBR boots more alike UEFI then the
>other way
On Mi, 01.07.20 17:19, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
> > Note that the spec has extension points (i.e. it's permissible to add
> > new fields without this breaking the spec), but turning it into a
> > programming lnaguage is wy outside of it...
> >
>
> I wouldn't consid
On Do, 02.07.20 17:24, Alex Thomas (karlth...@gmail.com) wrote:
> Question about systemd-boot vs GRUB2.
> One of the current stumbling blocks is the lack of LUKS2 support in
> GRUB2. Does sytemd-boot support LUKS2?
No it does not. Why would you encrypt your kernel/initrd?
On UEFI you have to hav
On 04.07.20 17:59, Lennart Poettering wrote:
> btw, sd-boot has a few tricks up its sleeve: if during boot you keep
> "w" pressed down it will automatically boot into windows, similar if
> you keep "l" pressed down it will automaticall boot into linux, "a"
> will boot into macos, all without showin
On Do, 02.07.20 15:30, Brandon Nielsen (niels...@jetfuse.net) wrote:
> I don't think removing BIOS support _today_ is the right answer either. I
> have BIOS only hardware kicking around, and quite a bit of my UEFI hardware
> still supports legacy BIOS booting as well (though I don't use it).
>
> H
On Sat, 2020-07-04 at 09:44 -0400, Solomon Peachy wrote:
> On Sat, Jul 04, 2020 at 01:24:46PM -, ziba wrote:
> > Fedora should absolutely CONTINUE supporting BIOS boot (sometimes
> > wrongly
> > labeled "legacy BIOS").
>
> Yep, Fedora should continue supporting BIOS boot at least for the
> n
On Sa, 04.07.20 11:39, Mauricio Tavares (raubvo...@gmail.com) wrote:
> On Sat, Jul 4, 2020 at 11:30 AM Lennart Poettering
> wrote:
> >
> > On Mi, 01.07.20 22:10, Neal Gompa (ngomp...@gmail.com) wrote:
> >
> > > This could still work. But you really shouldn't accept butt-ugliness
> > > from any u
On Mi, 01.07.20 22:55, John M. Harris Jr (joh...@splentity.com) wrote:
> Lennart,
>
> We don't need more systemd-bloat just to boot our systems. However your
> bootloader works, it doesn't really matter if it's not up to snuff with GRUB2.
> When it supports LUKS, LVM, LUKS+LVM, a recovery console
On Sat, Jul 4, 2020 at 11:30 AM Lennart Poettering wrote:
>
> On Mi, 01.07.20 22:10, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > This could still work. But you really shouldn't accept butt-ugliness
> > from any user-facing technology, even sd-boot.
>
> Dude, maybe what is "butt-ugly" and what isn
On Mi, 01.07.20 22:10, Neal Gompa (ngomp...@gmail.com) wrote:
> This could still work. But you really shouldn't accept butt-ugliness
> from any user-facing technology, even sd-boot.
Dude, maybe what is "butt-ugly" and what isn't is in the eye of the
beholder, and maybe if you want to spend the da
On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering wrote:
>
> On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > The user-interactive portion of sd-boot is *awful*. I know our GRUB
> > looks ugly by default these days too, but it doesn't have to be, and
> > most distros actually d
On Do, 02.07.20 12:46, Peter Robinson (pbrobin...@gmail.com) wrote:
> On Wed, Jul 1, 2020 at 12:19 AM Jóhann B. Guðmundsson
> wrote:
> >
> > On 30.6.2020 22:38, Kevin Kofler wrote:
> > > Jóhann B. Guðmundsson wrote:
> > >> sd-boot is already installed on end users system, is light weight
> > >> c
On Mi, 01.07.20 21:06, Neal Gompa (ngomp...@gmail.com) wrote:
> The user-interactive portion of sd-boot is *awful*. I know our GRUB
> looks ugly by default these days too, but it doesn't have to be, and
> most distros actually do make it look semi-decent.
BTW, the current look of systemd-boot was
On Mi, 01.07.20 22:09, John M. Harris Jr (joh...@splentity.com) wrote:
> GRUB2 supports UEFI well, probably better than systemd-bloat. At the same
> time, it's much more flexible in other aspects, providing users with the
> ability to boot their system in a number of situations that systemd-bloat
On Sat, Jul 04, 2020 at 01:24:46PM -, ziba wrote:
> Fedora should absolutely CONTINUE supporting BIOS boot (sometimes wrongly
> labeled "legacy BIOS").
Yep, Fedora should continue supporting BIOS boot at least for the next
few years. This question will surely be revisited after the remaini
> This post is just to gather feed back why Fedora should still continue
> to support legacy BIOS boot as opposed to stop supporting it
Fedora should absolutely CONTINUE supporting BIOS boot (sometimes wrongly
labeled "legacy BIOS").
Some of the finest hardware around uses trusty BIOS and w
On Friday, July 3, 2020 9:40:34 PM MST Rahul Sundaram wrote:
> Hi
>
> On Fri, Jul 3, 2020 at 4:32 PM John M. Harris Jr wrote:
> > These "qualifiers" are important.
> >
> > 1) Yes, I did get a response, as I said in the first email. The response
> > showed that there weren't any issues with the ke
Hi
On Fri, Jul 3, 2020 at 4:32 PM John M. Harris Jr wrote:
> These "qualifiers" are important.
>
> 1) Yes, I did get a response, as I said in the first email. The response
> showed that there weren't any issues with the kernel or core packages at
> the
> time it was dropped.
>
What you originall
I just came from Windows 10 not too long ago, and it was the worst computer
experience that I've ever had. Had it since the first week it came out, so glad
that I don't see it anymore. Hope I never see it again. It was really rough
getting my laptop downgraded to Windows 7, since my pc was being
On Friday, July 3, 2020 3:37:34 AM MST Rahul Sundaram wrote:
> Hi
>
> On Fri, Jul 3, 2020 at 2:14 AM John M. Harris wrote:
> > None of those bugs were release blocking, and none of them meant that x86
> > wouldn't boot, or that core packages didn't work
>
> When you add so many qualifiers, you a
On Friday, July 3, 2020 12:15:03 AM MST Nicolas Mailhot via devel wrote:
> Le jeudi 02 juillet 2020 à 15:19 -0500, Martin Jackson a écrit :
>
> > > 5-10 years? A better estimate would be 15-20 years. People aren't
> > > going to
> > > throw away perfectly fine systems and jump to new "cloud" platf
Hi
On Fri, Jul 3, 2020 at 2:14 AM John M. Harris wrote:
>
> None of those bugs were release blocking, and none of them meant that x86
> wouldn't boot, or that core packages didn't work
>
When you add so many qualifiers, you are now admitting a) you did get a
response b) that things weren't perf
Le jeudi 02 juillet 2020 à 15:19 -0500, Martin Jackson a écrit :
> > 5-10 years? A better estimate would be 15-20 years. People aren't
> > going to
> > throw away perfectly fine systems and jump to new "cloud" platforms
> > just
> > because the OS they were using dropped BIOS support. They'll just
On Thursday, July 2, 2020 11:45:09 PM MST Christopher Engelhard wrote:
> Can we maybe not restart this entire debate? i686 in Fedora has run down
> the curtain and joined the choir invisible. Whether we think that was
> the correct decision or not, there is absolutely no point in rehashing
> all th
Can we maybe not restart this entire debate? i686 in Fedora has run down
the curtain and joined the choir invisible. Whether we think that was
the correct decision or not, there is absolutely no point in rehashing
all the original arguments, let alone in a thread about BIOS support.
Christopher
O
On Thursday, July 2, 2020 6:56:03 PM MST Solomon Peachy wrote:
> On Thu, Jul 02, 2020 at 02:00:16PM -0700, John M. Harris Jr wrote:
> > If it doesn't have any reported CVEs, that's because nobody uses it.
>
> You may be right, but one can't have vulnerabilies in functionality that
> doesn't exist.
On Thursday, July 2, 2020 4:06:55 PM MST Alexander Ploumistos wrote:
> On Fri, Jul 3, 2020 at 12:49 AM John M. Harris Jr
> > None of the linked blockers are core packages, and some of them are
> > outright not designed to work on anything other than 64 bit. I really
> > don't understand how you ca
On Thursday, July 2, 2020 4:06:07 PM MST Rahul Sundaram wrote:
> Hi
>
> On Thu, Jul 2, 2020 at 6:49 PM John M. Harris Jr wrote:
> >That's a link to the release announcement.
>
> Hardly the first time it was announced. It refers to x86_32 sig that was
> formed much earlier which itself was a respo
On Thu, Jul 02, 2020 at 02:00:16PM -0700, John M. Harris Jr wrote:
> If it doesn't have any reported CVEs, that's because nobody uses it.
You may be right, but one can't have vulnerabilies in functionality that
doesn't exist.
(I find it hilarious that "small, simple, single-purpose" is suddenly
On 2020-07-02 13:08, Peter Robinson wrote:
I suppose "very good state" is a relative term, upstream hasn't seen a
release since 2016 so is essentially "unmaintained", not sure it
supports secure boot, probably has a bunch of CVEs (see point about
maintenance). I think it only lives on in Fedora i
On Fri, Jul 3, 2020 at 12:49 AM John M. Harris Jr wrote:
>
> On Thursday, July 2, 2020 3:47:00 PM MST Alexander Ploumistos wrote:
> > On Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr
> > wrote:
> > >
> > >
> > > That's a link to the release announcement. If you follow the thread,
> > > you'll fi
Hi
On Thu, Jul 2, 2020 at 6:49 PM John M. Harris Jr wrote:
>That's a link to the release announcement.
Hardly the first time it was announced. It refers to x86_32 sig that was
formed much earlier which itself was a response to an earlier warning that
x86_32 support is going away unless people st
On Thursday, July 2, 2020 3:47:00 PM MST Alexander Ploumistos wrote:
> On Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr
> wrote:
> >
> >
> > That's a link to the release announcement. If you follow the thread,
> > you'll find that I was provided a link to two bugzilla links are to meta
> > links
On Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr wrote:
>
> That's a link to the release announcement. If you follow the thread, you'll
> find that I was provided a link to two bugzilla links are to meta links to
> blockers, where the items that are blocking are not issues preventing x86
> system
Ok thought I had read somewhere that is was in the pipeline but had
not merged. Must be old data.
On Thu, Jul 2, 2020 at 5:34 PM Neal Gompa wrote:
>
> On Thu, Jul 2, 2020 at 6:24 PM Alex Thomas wrote:
> >
> > Question about systemd-boot vs GRUB2.
> > One of the current stumbling blocks is the la
On Thu, Jul 2, 2020 at 6:24 PM Alex Thomas wrote:
>
> Question about systemd-boot vs GRUB2.
> One of the current stumbling blocks is the lack of LUKS2 support in
> GRUB2. Does sytemd-boot support LUKS2?
GRUB2 supports LUKS2 in v2.06. sd-boot does not support it.
--
真実はいつも一つ！/ Always, there's
Question about systemd-boot vs GRUB2.
One of the current stumbling blocks is the lack of LUKS2 support in
GRUB2. Does sytemd-boot support LUKS2?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedo
On Thursday, July 2, 2020 3:09:14 PM MST Alexander Ploumistos wrote:
> On Thu, Jul 2, 2020 at 10:54 PM John M. Harris Jr
> wrote:
> >
> >
> > On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
> >
> > > On 7/2/20 3:16 AM, nick...@gmail.com wrote:
> > >
> > >
> > >
> > > > Note that, e
On Thu, Jul 2, 2020 at 10:54 PM John M. Harris Jr wrote:
>
> On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
> > On 7/2/20 3:16 AM, nick...@gmail.com wrote:
> >
> > > Note that, even though Microsoft is pushing for UEFI on new systems in
> > > the OEM version of Windows, they still
On 7/2/20 3:42 PM, John M. Harris Jr wrote:
GRUB2, which is a UEFI bootloader as well, is a far superior bootloader to
systemd-bloat, and it supports usecases that are supported by Anaconda (the
Fedora installer framework) that systemd-bloat doesn't, as addressed elsewhere
in this thread by m
On 02/07/20 07:08 -0500, Brandon Nielsen wrote:
On 7/2/20 12:55 AM, John M. Harris Jr wrote:
Lennart,
We don't need more systemd-bloat just to boot our systems. However your
bootloader works, it doesn't really matter if it's not up to snuff with GRUB2.
When it supports LUKS, LVM, LUKS+LVM,
HI
On Thu, Jul 2, 2020 at 4:54 PM John M. Harris Jr
> That's not really true. When it came down to it, it was dropped while 32
> bit
> Fedora still worked perfectly. I'm left with 5 systems that will never be
> updated as a result. I asked for a list of issues that warranted ending 32
> bit
> sup
On Thursday, July 2, 2020 7:50:25 AM MST Solomon Peachy wrote:
> On Thu, Jul 02, 2020 at 02:07:17PM -, Ivan Ivanov wrote:
> > hopefully those which don't have a SystemD security-vulnerable
> > bloatware
>
> Oh, FFS.
>
> In this comparison, grub2 is the _highly_ bloated,
> everything-AND-the-k
On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
> On 7/2/20 3:16 AM, nick...@gmail.com wrote:
>
> > Note that, even though Microsoft is pushing for UEFI on new systems in
> > the OEM version of Windows, they still support booting in legacy BIOS
> > mode in the latest Windows 10 vers
On Thursday, July 2, 2020 1:30:41 PM MST Brandon Nielsen wrote:
> On 7/2/20 3:19 PM, Martin Jackson wrote:
>
> >
> >
> >> 5-10 years? A better estimate would be 15-20 years. People aren't
> >> going to
> >> throw away perfectly fine systems and jump to new "cloud" platforms just
> >> because th
On Thursday, July 2, 2020 1:19:22 PM MST Martin Jackson wrote:
> > 5-10 years? A better estimate would be 15-20 years. People aren't going
> > to
> > throw away perfectly fine systems and jump to new "cloud" platforms just
> > because the OS they were using dropped BIOS support. They'll just stop
>
On Thu, 2020-07-02 at 08:24 -0700, Gordon Messmer wrote:
> On 7/2/20 3:16 AM, nick...@gmail.com wrote:
> > Note that, even though Microsoft is pushing for UEFI on new systems
> > in
> > the OEM version of Windows, they still support booting in legacy
> > BIOS
> > mode in the latest Windows 10 versi
On 7/2/20 3:19 PM, Martin Jackson wrote:
5-10 years? A better estimate would be 15-20 years. People aren't
going to
throw away perfectly fine systems and jump to new "cloud" platforms just
because the OS they were using dropped BIOS support. They'll just stop
updating, and likely move to somet
5-10 years? A better estimate would be 15-20 years. People aren't going to
throw away perfectly fine systems and jump to new "cloud" platforms just
because the OS they were using dropped BIOS support. They'll just stop
updating, and likely move to something that is still supporting BIOS, if the
On Wednesday, July 1, 2020 2:28:39 PM MST Jóhann B. Guðmundsson wrote:
> On 1.7.2020 21:00, Neal Gompa wrote:
>
> > On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> > wrote:
> >
> >> On 1.7.2020 16:10, Solomon Peachy wrote:
> >>
> >>> On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Rag
On 7/2/20 2:56 PM, John M. Harris Jr wrote:
On Thursday, July 2, 2020 5:08:14 AM MST Brandon Nielsen wrote:
On 7/2/20 12:55 AM, John M. Harris Jr wrote:
Lennart,
We don't need more systemd-bloat just to boot our systems. However your
bootloader works, it doesn't really matter if it's not
On Thursday, July 2, 2020 5:08:31 AM MST Peter Robinson wrote:
> On Wed, Jul 1, 2020 at 3:29 PM Alek Paunov wrote:
>
> >
> >
> > On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote:
> >
> > > Share your thoughts and comments on how such move might affect you so
> > > feedback can be collected for t
On Thursday, July 2, 2020 5:08:14 AM MST Brandon Nielsen wrote:
> On 7/2/20 12:55 AM, John M. Harris Jr wrote:
>
>
>
>
> >
> > Lennart,
> >
> > We don't need more systemd-bloat just to boot our systems. However your
> > bootloader works, it doesn't really matter if it's not up to snuff with
>
On 7/2/20 3:16 AM, nick...@gmail.com wrote:
Note that, even though Microsoft is pushing for UEFI on new systems in
the OEM version of Windows, they still support booting in legacy BIOS
mode in the latest Windows 10 version and they even support a 32-bit
version of Windows 10, which Fedora no long
On 7/2/20 4:46 AM, Peter Robinson wrote:
On Wed, Jul 1, 2020 at 12:19 AM Jóhann B. Guðmundsson
wrote:
On 30.6.2020 22:38, Kevin Kofler wrote:
In addition, as far as I know, systemd-boot is not compatible with the
"Secure Boot" shim.
sd-boot works fine with secure boot but good point I'll add
On Thu, Jul 02, 2020 at 02:07:17PM -, Ivan Ivanov wrote:
> hopefully those which don't have a SystemD security-vulnerable
> bloatware
Oh, FFS.
In this comparison, grub2 is the _highly_ bloated,
everything-AND-the-kitchen-sink solution with multiple CVEs under its
belt, and systemd-boot i
On Thu, Jul 2, 2020 at 9:49 AM Peter Robinson wrote:
>
> On Wed, Jul 1, 2020 at 10:01 PM Neal Gompa wrote:
> >
> > On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> > wrote:
> > >
> > > On 1.7.2020 16:10, Solomon Peachy wrote:
> > > > On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragus
> > If you need Secure Boot feature to be enabled, you must sign the
> > compiled kmod packages with your own CA.
> >
>
> This is what's wrong with everything. *This is not okay*. This is
> intentionally a poisonous user experience because we provide no
> automatic or easy way for this to be done.
Dropping the "legacy BIOS" support is a horrible idea:
Not just there are a lot of "legacy BIOS" PCs, especially in a corporate world
where the upgrades are slower than in the domestic environments.
There are also a lot of really modern PCs running a coreboot firmware with a
SeaBIOS payload - whi
On Wed, Jul 1, 2020 at 10:01 PM Neal Gompa wrote:
>
> On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> wrote:
> >
> > On 1.7.2020 16:10, Solomon Peachy wrote:
> > > On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> > >> I'm currently using BIOS, grub, grub2 basically everyw
On Wed, Jul 1, 2020 at 10:31 pm, Ralf Corsepius
wrote:
I definitely own BIOS-only systems, which have been sold long after
2005
and which are still in everyday use.
If we're looking for more data points, my System76 laptop is from 2015
(still just under five years old!) and only supports leg
101 - 200 of 317 matches
Mail list logo
