dora-comps/pull-request/676
which should remove memtest86+ and the menu entry for it from media for
now.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.or
On 9/3/21 12:13 PM, Gordon Messmer wrote:
Does Fedora GRUB also contain changes that might interfere with
chainloading? I believe that some people are using it to chainload
the Windows boot loader, but maybe it only works for binaries with
signatures?
# sbsign --key MOK.priv --cert MOK.pem
On 9/3/21 2:26 AM, Hans de Goede wrote:
It might be interesting to try and using e.g. an EFI
grub binary from Ubuntu with a:
linux /pcmemtest.efi
I created a UEFI VM running Debian 11 to try that out. It doesn't work
there, but I'm seeing in consistent results. The first time aroun
Hi,
On 8/30/21 9:35 PM, Gordon Messmer wrote:
> On 8/30/21 12:08 PM, Hans de Goede wrote:
>>
>> I checked the entry on a Windows multiboot system and it does not have the
>> "insmod chain" line, maybe droppint that helps?
>
>
> Same result. GRUB returns immediately to its menu. I'm certain the
On Mon, 2021-08-30 at 12:35 -0700, Gordon Messmer wrote:
> On 8/30/21 12:08 PM, Hans de Goede wrote:
> >
> > I checked the entry on a Windows multiboot system and it does not
> > have the
> > "insmod chain" line, maybe droppint that helps?
>
>
> Same result. GRUB returns immediately to its menu
On 8/30/21 12:08 PM, Hans de Goede wrote:
I checked the entry on a Windows multiboot system and it does not have the
"insmod chain" line, maybe droppint that helps?
Same result. GRUB returns immediately to its menu. I'm certain the
path is correct, because GRUB will report an error if it i
Hi,
On 8/30/21 7:11 PM, Gordon Messmer wrote:
> On 8/30/21 12:20 AM, Hans de Goede wrote:
>> For the grub bit I think you just need a menu entry with a chainloader
>> line in there, similar to how booting Windows in a multi-boot setup works.
>
>
> Among other things, I've tried
>
> insm
On 8/30/21 12:20 AM, Hans de Goede wrote:
For the grub bit I think you just need a menu entry with a chainloader
line in there, similar to how booting Windows in a multi-boot setup works.
Among other things, I've tried
insmod chain
chainloader //pcmemtest.efi
When that menuen
Hi,
On 8/29/21 11:46 PM, Gordon Messmer wrote:
> On 8/1/21 3:54 PM, Neal Gompa wrote:
>> But that doesn't stop anyone from maintaining an unsigned version.
>
>
> The documentation suggests that the UEFI binary can be loaded directly (which
> I've done), or through the EFI handover protocol. I h
On 8/1/21 3:54 PM, Neal Gompa wrote:
But that doesn't stop anyone from maintaining an unsigned version.
The documentation suggests that the UEFI binary can be loaded directly
(which I've done), or through the EFI handover protocol. I haven't done
the latter successfully yet. If I work out t
onally it's tedious to find it (neither memtest86 or memtest86+
> finding it, but doing a bunch of compiles of the kernel with gcc does
> find it - almost like gcc is a good memory tester, however unintended,
> much like btrfs and probably also zfs).
[..]
I can confirm, in the last instan
to advise this.
Tested with memtest86+-5.31-0.3.beta.fc34 on Intel Core i7 10700 - hangs
on start.
Tested on AMD Ryzen 7 5800X - it starts, works, then system hangs. Need
to press Reset button.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
On 02/08/2021 14:34, Nikolay Nikolov wrote:
The memtest86+, included in the Fedora install media works. AMD Ryzen 9
5900X here, with 128 GB RAM. Unfortunately, it was recently removed from
the install media.
Intel Core i7 10700 - hangs on start in legacy mode even from the Fedora
LiveUSB
On 8/2/21 9:15 AM, Vitaly Zaitsev via devel wrote:
On 02/08/2021 04:04, Chris Murphy wrote:
I'm definitely not attached to keeping things the same. The bios
memtest86+ is still these days installed to /boot but there hasn't
been a menu entry for it for a very long time; in fact ma
On Mon, Aug 2, 2021 at 12:15 AM Vitaly Zaitsev via devel
wrote:
>
> On 02/08/2021 04:04, Chris Murphy wrote:
> > I'm definitely not attached to keeping things the same. The bios
> > memtest86+ is still these days installed to /boot but there hasn't
> > been a
On 02/08/2021 04:04, Chris Murphy wrote:
I'm definitely not attached to keeping things the same. The bios
memtest86+ is still these days installed to /boot but there hasn't
been a menu entry for it for a very long time; in fact maybe it was
only ever on netintall or dvd images? I can&
e easiest thing to do today
> would be to put the iso on a flash drive (or even a cdrom) and boot it from
> there.
>
I'm definitely not attached to keeping things the same. The bios
memtest86+ is still these days installed to /boot but there hasn't
been a menu entry for it for a
y quite a bit less) with a user space
tester. But on the other hand, better memory testers find bad RAM
faster. They aren't all equally effective at this. At least over in
#btrfs land, we see evidence of bad RAM sourced corruption, and
occasionally it's tedious to find it (neither memtest8
really assess whether it's better or worse than
one that runs in the pre-boot environment. On the one hand, less
memory is being tested (possibly quite a bit less) with a user space
tester. But on the other hand, better memory testers find bad RAM
faster. They aren't all equally effectiv
On Sun, Aug 1, 2021 at 6:49 PM Gordon Messmer wrote:
>
> On 7/30/21 5:57 PM, Chris Murphy wrote:
> > It would need a maintainer. Any takers? ...
> > If we want it to work with UEFI Secure Boot
> > enabled, it'd need to be signed with Fedora's key
>
>
> Does the signing requirement imply that the m
On 7/30/21 5:57 PM, Chris Murphy wrote:
It would need a maintainer. Any takers? ...
If we want it to work with UEFI Secure Boot
enabled, it'd need to be signed with Fedora's key
Does the signing requirement imply that the maintainer would need to be
a Red Hat employee (or another trusted part
On 31/07/2021 19:47, Chris Murphy wrote:
I'm referring to memtest86+ not memtest86
Memtest86+ is a fork of the opensource version of memtest86.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list --
On Sat, Jul 31, 2021 at 1:28 AM Vitaly Zaitsev via devel
wrote:
>
> On 31/07/2021 02:57, Chris Murphy wrote:
> > This bug might be gcc, but also includes a note about the upstream
> > being kinda weak, possibly non-existent these days.
>
> They just closed the sources. M
On 31/07/2021 12:37, Alexander Ploumistos wrote:
Just to be sure, you are talking about Memtest86, not Memtest86+, right?
Yes. From the official website:
Based on the well-known original memtest86 written by Chris Brady, memtest86+
is a port by some members of the x86-secret team, now
Hi Vitaly,
On Sat, Jul 31, 2021 at 10:28 AM Vitaly Zaitsev via devel
wrote:
>
> They just closed the sources. Memtest86 is a commercial product now. It
> has full UEFI support, etc.
Just to be sure, you are talking about Memtest86, not Memtest8
El sáb, 31 jul 2021 a las 2:58, Chris Murphy ()
escribió:
> Neal Gompa mentioned pcmemtest earlier this year
> https://github.com/martinwhitaker/pcmemtest
>
> It would need a maintainer. Any takers?
>
>
Hi, I'm not interested in owning the package, but I've created a test build
because I want to p
On 31/07/2021 02:57, Chris Murphy wrote:
This bug might be gcc, but also includes a note about the upstream
being kinda weak, possibly non-existent these days.
They just closed the sources. Memtest86 is a commercial product now. It
has full UEFI support, etc.
--
Sincerely,
Vitaly Zaitsev
ler. But I think it's better to
not ship a memory tester at all, than to ship a broken one (given the
options).
Memtest86+ is bios only, where pcmemtest can be compiled to run on
either firmware type. If we want it to work with UEFI Secure Boot
enabled, it'd need to be signed with Fedor
* Florian Weimer:
> * Neal Gompa:
>
>> None of this had to be this way. It is so by our own inaction, not by
>> the action of Microsoft.
>
> I agree. No one but Microsoft stepped up and was willing to control the
> key material.
>
> I still wish we went the way of documenting how to disable Secur
* Neal Gompa:
> None of this had to be this way. It is so by our own inaction, not by
> the action of Microsoft.
I agree. No one but Microsoft stepped up and was willing to control the
key material.
I still wish we went the way of documenting how to disable Secure Boot
in commonly used firmware
Chris Murphy wrote:
> This is such an old argument. I know you've been around in Fedora long
> enough to actually understand this stuff if you really wanted to at
> least not spread misinformation.
I do not see how I am spreading misinformation. I think you are
misunderstanding me. I do not inten
Neal Gompa wrote:
> Don't blame Microsoft for our failings. The fact that we can't do
> hibernation or offer an easy path for third-party kernel modules to
> function in a Secure Boot environment is *entirely* our fault. After
> shim->grub2, Microsoft's trust ends and ours begins. We use *our*
> ce
On 2/9/21 10:53 AM, Vít Ondruch wrote:
Dne 08. 02. 21 v 21:44 Chris Murphy napsal(a):
On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote:
Being devils advocate, but should we have the memtest86 or similar by
default? I have certainly not used this feature in my 10+ yeas with
Fedora.
You
Dne 09. 02. 21 v 10:08 Roberto Ragusa napsal(a):
On 2/8/21 10:46 AM, Vít Ondruch wrote:
Being devils advocate, but should we have the memtest86 or similar by
default? I have certainly not used this feature in my 10+ yeas with
Fedora.
I've not used GNOME in my 18 years with Fedora (plus
On 2/8/21 10:46 AM, Vít Ondruch wrote:
Being devils advocate, but should we have the memtest86 or similar by default?
I have certainly not used this feature in my 10+ yeas with Fedora.
I've not used GNOME in my 18 years with Fedora (plus 5 pre-Fedora).
Can we consider removing it?
H
Dne 08. 02. 21 v 21:44 Chris Murphy napsal(a):
On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote:
Being devils advocate, but should we have the memtest86 or similar by
default? I have certainly not used this feature in my 10+ yeas with Fedora.
You mean get rid of it (from media and
On Mon, Feb 8, 2021 at 7:13 PM Kevin Kofler via devel
wrote:
>
> Chris Murphy wrote:
> > If you want to take the risk of acquiring a rootkit that can
> > permanently take control of your firmware, that is up to you. It
> > should not be a distribution recommendation to subject users to such
> > ba
On Mon, Feb 8, 2021 at 9:13 PM Kevin Kofler via devel
wrote:
>
> Chris Murphy wrote:
> > If you want to take the risk of acquiring a rootkit that can
> > permanently take control of your firmware, that is up to you. It
> > should not be a distribution recommendation to subject users to such
> > ba
Chris Murphy wrote:
> If you want to take the risk of acquiring a rootkit that can
> permanently take control of your firmware, that is up to you. It
> should not be a distribution recommendation to subject users to such
> bad advice.
And the "good advice" would be to accept that your computer wil
On Mon, Feb 8, 2021 at 5:19 PM Kevin Kofler via devel
wrote:
>
> Chris Murphy wrote:
> > Yeah I definitely do not want Fedora in a position where anyone has to
> > give users advice like "you need to disable UEFI Secure Boot" in order
> > to do X. Be it testing RAM or anything else.
>
> Why would
Chris Murphy wrote:
> Yeah I definitely do not want Fedora in a position where anyone has to
> give users advice like "you need to disable UEFI Secure Boot" in order
> to do X. Be it testing RAM or anything else.
Why would anyone want to NOT disable Restricted Boot? (Assuming the firmware
is not
On Mon, Feb 8, 2021 at 4:47 PM Martin Whitaker
wrote:
>
> On 07/02/2021 22:23, Chris Murphy wrote:
> > On Sun, Feb 7, 2021 at 2:08 AM Neal Gompa wrote:
> >>
> >> Hey all,
> >>
> >> I discovered today that there's a new replacement for memtest8
On 2/8/21 2:44 PM, Chris Murphy wrote:
On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote:
Being devils advocate, but should we have the memtest86 or similar by
default? I have certainly not used this feature in my 10+ yeas with Fedora.
You mean get rid of it (from media and installations
On Mon, Feb 8, 2021 at 2:46 AM Vít Ondruch wrote:
>
> Being devils advocate, but should we have the memtest86 or similar by
> default? I have certainly not used this feature in my 10+ yeas with Fedora.
>
You mean get rid of it (from media and installations)? Because we
install it unc
Being devils advocate, but should we have the memtest86 or similar by
default? I have certainly not used this feature in my 10+ yeas with Fedora.
Vít
Dne 07. 02. 21 v 10:07 Neal Gompa napsal(a):
Hey all,
I discovered today that there's a new replacement for memtest86+ that
appears to
On Sun, Feb 7, 2021 at 2:08 AM Neal Gompa wrote:
>
> Hey all,
>
> I discovered today that there's a new replacement for memtest86+ that
> appears to even have UEFI support called PCMemTest[0].
>
> The main reason I call out to this is because we don't have a memor
t; >
> > > «In particular, no attempt is made to measure the cache and main
> > memory speed,
> > > or to identify and report the DRAM type.»
> > >
> > >
> > > Which is nice to have but not really the point of a memory tester ...
>
«In particular, no attempt is made to measure the cache and main memory
speed,
or to identify and report the DRAM type.»
Which is nice to have but not really the point of a memory tester ...
When the tester reports errors then it is handy to know as much as possible
about where the
> dropping features:
> >
> > «In particular, no attempt is made to measure the cache and main
> memory speed,
> > or to identify and report the DRAM type.»
> >
> >
> > Which is nice to have but not really the point of a memory tester ...
>
> I&#
or to identify and report the DRAM type.»
Which is nice to have but not really the point of a memory tester ...
I'm pointing out that memtest86+ is not just a memory tester.
Is there any other tool covering that functionality?
--
Roberto Ragusamail at rober
On Sunday, February 7, 2021, Roberto Ragusa wrote:
> On 2/7/21 10:07 AM, Neal Gompa wrote:
>
>> Hey all,
>>
>> I discovered today that there's a new replacement for memtest86+ that
>> appears to even have UEFI support called PCMemTest[0].
>>
>
> I
On 2/7/21 10:07 AM, Neal Gompa wrote:
Hey all,
I discovered today that there's a new replacement for memtest86+ that
appears to even have UEFI support called PCMemTest[0].
It can only be an alternative, not a replacement, since it is dropping features:
«In particular, no attempt is ma
Hey all,
I discovered today that there's a new replacement for memtest86+ that
appears to even have UEFI support called PCMemTest[0].
The main reason I call out to this is because we don't have a memory
tester offering in our UEFI boot variant for the Fedora live media,
and this i
- Original Message -
>
>
> - Original Message -
> > On Fri, 8 Jan 2016 11:12:37 -0500 (EST)
> > Jaroslav Skarvada wrote:
> >
> > > $ git push -v
> > > Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+
> > >
- Original Message -
> On Fri, 8 Jan 2016 11:12:37 -0500 (EST)
> Jaroslav Skarvada wrote:
>
> > $ git push -v
> > Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+
> > WARNING: 'memtest86+' is an alias for 'rpms/memtest86+'
On Fri, 8 Jan 2016 11:12:37 -0500 (EST)
Jaroslav Skarvada wrote:
> $ git push -v
> Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+
> WARNING: 'memtest86+' is an alias for 'rpms/memtest86+'
> FATAL: W any memtest86+ jskarvad DENIED by fallthru
&g
On 01/08/2016 08:22 AM, Jerry James wrote:
On Fri, Jan 8, 2016 at 9:12 AM, Jaroslav Skarvada wrote:
$ git push -v
Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+
WARNING: 'memtest86+' is an alias for 'rpms/memtest86+'
And what's up with this warning?
On Fri, Jan 8, 2016 at 9:12 AM, Jaroslav Skarvada wrote:
> $ git push -v
> Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+
> WARNING: 'memtest86+' is an alias for 'rpms/memtest86+'
And what's up with this warning? I was just puzzling over that
myse
$ git push -v
Pushing to ssh://jskar...@pkgs.fedoraproject.org/memtest86+
WARNING: 'memtest86+' is an alias for 'rpms/memtest86+'
FATAL: W any memtest86+ jskarvad DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.
Please ma
On 06/02/2011 04:44 AM, Jaroslav Skarvada wrote:
> - Original Message -
> 4.20 is in rawhide since March 07. I will push it to f14/f15 also. Please
> file a bug next time
>
> thanks & regards
>
> Jaroslav
>
Thanks - I did file a bug and see that you replied to the bug too - so
thank
- Original Message -
> On 06/01/2011 09:59 PM, Genes MailLists wrote:
> >
> > Best I can tell the current version of memtest86+ in Fedora is
> > v4.10
> > which is too old for Sandy Bridge which needs version v4.20.
> >
> > Anyone know if there i
On 06/01/2011 09:59 PM, Genes MailLists wrote:
>
> Best I can tell the current version of memtest86+ in Fedora is v4.10
> which is too old for Sandy Bridge which needs version v4.20.
>
> Anyone know if there is some reason we haven't updated to the current
> version
On Wed, Jun 1, 2011 at 10:59 PM, Genes MailLists wrote:
>
> Best I can tell the current version of memtest86+ in Fedora is v4.10
> which is too old for Sandy Bridge which needs version v4.20.
>
> Anyone know if there is some reason we haven't updated to the current
> ve
Best I can tell the current version of memtest86+ in Fedora is v4.10
which is too old for Sandy Bridge which needs version v4.20.
Anyone know if there is some reason we haven't updated to the current
version (released January 2011) ?
Thanks.
--
devel mailing list
64 matches
Mail list logo
