On Sat, Dec 30, 2017 at 00:30:32 +0800,
weiping zhang wrote:
1. Add proper SELINUX policy that give permission to mdadm for debugfs.
2. Split mdadm into 2 part, Firstly, user proccess mdadm trigger a kwork,
secondly kwork will create gendisk)and mdadm wait it
On Sat, Dec 30, 2017 at 00:30:32 +0800,
weiping zhang wrote:
1. Add proper SELINUX policy that give permission to mdadm for debugfs.
2. Split mdadm into 2 part, Firstly, user proccess mdadm trigger a kwork,
secondly kwork will create gendisk)and mdadm wait it done, Like
following:
diff --git
On Fri, Dec 22, 2017 at 08:04:23AM -0600, Bruno Wolff III wrote:
> On Fri, Dec 22, 2017 at 21:20:10 +0800,
> weiping zhang wrote:
> >2017-12-22 12:53 GMT+08:00 Bruno Wolff III :
> >>On Thu, Dec 21, 2017 at 17:16:03 -0600,
> >> Bruno Wolff III
On Fri, Dec 22, 2017 at 08:04:23AM -0600, Bruno Wolff III wrote:
> On Fri, Dec 22, 2017 at 21:20:10 +0800,
> weiping zhang wrote:
> >2017-12-22 12:53 GMT+08:00 Bruno Wolff III :
> >>On Thu, Dec 21, 2017 at 17:16:03 -0600,
> >> Bruno Wolff III wrote:
> >>>
> >>>
> >>>Enforcing mode alone isn't
On Fri, Dec 22, 2017 at 08:04:23AM -0600, Bruno Wolff III wrote:
> On Fri, Dec 22, 2017 at 21:20:10 +0800,
> weiping zhang wrote:
> >2017-12-22 12:53 GMT+08:00 Bruno Wolff III :
> >>On Thu, Dec 21, 2017 at 17:16:03 -0600,
> >> Bruno Wolff III
On Fri, Dec 22, 2017 at 08:04:23AM -0600, Bruno Wolff III wrote:
> On Fri, Dec 22, 2017 at 21:20:10 +0800,
> weiping zhang wrote:
> >2017-12-22 12:53 GMT+08:00 Bruno Wolff III :
> >>On Thu, Dec 21, 2017 at 17:16:03 -0600,
> >> Bruno Wolff III wrote:
> >>>
> >>>
> >>>Enforcing mode alone isn't
On Fri, Dec 22, 2017 at 21:20:10 +0800,
weiping zhang wrote:
2017-12-22 12:53 GMT+08:00 Bruno Wolff III :
On Thu, Dec 21, 2017 at 17:16:03 -0600,
Bruno Wolff III wrote:
Enforcing mode alone isn't enough as I tested that one one machine
On Fri, Dec 22, 2017 at 21:20:10 +0800,
weiping zhang wrote:
2017-12-22 12:53 GMT+08:00 Bruno Wolff III :
On Thu, Dec 21, 2017 at 17:16:03 -0600,
Bruno Wolff III wrote:
Enforcing mode alone isn't enough as I tested that one one machine at home
and it didn't trigger the problem. I'll try
2017-12-22 12:53 GMT+08:00 Bruno Wolff III :
> On Thu, Dec 21, 2017 at 17:16:03 -0600,
> Bruno Wolff III wrote:
>>
>>
>> Enforcing mode alone isn't enough as I tested that one one machine at home
>> and it didn't trigger the problem. I'll try another machine late
2017-12-22 12:53 GMT+08:00 Bruno Wolff III :
> On Thu, Dec 21, 2017 at 17:16:03 -0600,
> Bruno Wolff III wrote:
>>
>>
>> Enforcing mode alone isn't enough as I tested that one one machine at home
>> and it didn't trigger the problem. I'll try another machine late tonight.
>
>
> I got the problem
On Thu, Dec 21, 2017 at 17:16:03 -0600,
Bruno Wolff III wrote:
Enforcing mode alone isn't enough as I tested that one one machine at
home and it didn't trigger the problem. I'll try another machine late
tonight.
I got the problem to occur on my i686 machine when booting in
On Thu, Dec 21, 2017 at 17:16:03 -0600,
Bruno Wolff III wrote:
Enforcing mode alone isn't enough as I tested that one one machine at
home and it didn't trigger the problem. I'll try another machine late
tonight.
I got the problem to occur on my i686 machine when booting in enforcing
On Thu, 2017-12-21 at 10:02 -0700, Jens Axboe wrote:
> On 12/21/17 9:42 AM, Bruno Wolff III wrote:
> >
> > On Thu, Dec 21, 2017 at 23:48:19 +0800,
> > weiping zhang wrote:
> > >
> > > >
> > > > output you want. I never saw it for any kernels I compiled
> > > > myself.
On Thu, 2017-12-21 at 10:02 -0700, Jens Axboe wrote:
> On 12/21/17 9:42 AM, Bruno Wolff III wrote:
> >
> > On Thu, Dec 21, 2017 at 23:48:19 +0800,
> > weiping zhang wrote:
> > >
> > > >
> > > > output you want. I never saw it for any kernels I compiled
> > > > myself. Only when I test
On Thu, Dec 21, 2017 at 12:15:31 -0600,
Bruno Wolff III wrote:
One important thing I have just found is that it looks like the
problem only happens when booting in enforcing mode. If I boot in
permissive mode it does not happen. My home machines are currently set
to boot in
On Thu, Dec 21, 2017 at 12:15:31 -0600,
Bruno Wolff III wrote:
One important thing I have just found is that it looks like the
problem only happens when booting in enforcing mode. If I boot in
permissive mode it does not happen. My home machines are currently set
to boot in permissive mode
On Thu, Dec 21, 2017 at 10:02:15 -0700,
Jens Axboe wrote:
On 12/21/17 9:42 AM, Bruno Wolff III wrote:
On Thu, Dec 21, 2017 at 23:48:19 +0800,
weiping zhang wrote:
output you want. I never saw it for any kernels I compiled myself. Only when
I test
On Thu, Dec 21, 2017 at 10:02:15 -0700,
Jens Axboe wrote:
On 12/21/17 9:42 AM, Bruno Wolff III wrote:
On Thu, Dec 21, 2017 at 23:48:19 +0800,
weiping zhang wrote:
output you want. I never saw it for any kernels I compiled myself. Only when
I test kernels built by Fedora do I see it.
see
2017-12-22 1:02 GMT+08:00 Jens Axboe :
> On 12/21/17 9:42 AM, Bruno Wolff III wrote:
>> On Thu, Dec 21, 2017 at 23:48:19 +0800,
>> weiping zhang wrote:
output you want. I never saw it for any kernels I compiled myself. Only
when
I test
2017-12-22 1:02 GMT+08:00 Jens Axboe :
> On 12/21/17 9:42 AM, Bruno Wolff III wrote:
>> On Thu, Dec 21, 2017 at 23:48:19 +0800,
>> weiping zhang wrote:
output you want. I never saw it for any kernels I compiled myself. Only
when
I test kernels built by Fedora do I see it.
>>>
On 12/21/17 9:42 AM, Bruno Wolff III wrote:
> On Thu, Dec 21, 2017 at 23:48:19 +0800,
> weiping zhang wrote:
>>> output you want. I never saw it for any kernels I compiled myself. Only when
>>> I test kernels built by Fedora do I see it.
>> see it every boot ?
>
> I don't
On 12/21/17 9:42 AM, Bruno Wolff III wrote:
> On Thu, Dec 21, 2017 at 23:48:19 +0800,
> weiping zhang wrote:
>>> output you want. I never saw it for any kernels I compiled myself. Only when
>>> I test kernels built by Fedora do I see it.
>> see it every boot ?
>
> I don't look every boot. The
On Thu, Dec 21, 2017 at 23:48:19 +0800,
weiping zhang wrote:
output you want. I never saw it for any kernels I compiled myself. Only when
I test kernels built by Fedora do I see it.
see it every boot ?
I don't look every boot. The warning gets scrolled of the screen.
On Thu, Dec 21, 2017 at 23:48:19 +0800,
weiping zhang wrote:
output you want. I never saw it for any kernels I compiled myself. Only when
I test kernels built by Fedora do I see it.
see it every boot ?
I don't look every boot. The warning gets scrolled of the screen. Once I see
the CPU
2017-12-21 23:36 GMT+08:00 Bruno Wolff III :
> On Thu, Dec 21, 2017 at 23:31:40 +0800,
> weiping zhang wrote:
>>
>> does every time boot fail can trigger WANRING in device_add_disk ?
>
>
> Not that I see. But the message could scroll off the screen. The boot
2017-12-21 23:36 GMT+08:00 Bruno Wolff III :
> On Thu, Dec 21, 2017 at 23:31:40 +0800,
> weiping zhang wrote:
>>
>> does every time boot fail can trigger WANRING in device_add_disk ?
>
>
> Not that I see. But the message could scroll off the screen. The boot gets
> far enough that systemd copies
On Thu, Dec 21, 2017 at 23:31:40 +0800,
weiping zhang wrote:
does every time boot fail can trigger WANRING in device_add_disk ?
Not that I see. But the message could scroll off the screen. The boot gets
far enough that systemd copies over dmesg output to permanent
On Thu, Dec 21, 2017 at 23:31:40 +0800,
weiping zhang wrote:
does every time boot fail can trigger WANRING in device_add_disk ?
Not that I see. But the message could scroll off the screen. The boot gets
far enough that systemd copies over dmesg output to permanent storage that
I can see on
2017-12-21 23:18 GMT+08:00 Bruno Wolff III :
> On Thu, Dec 21, 2017 at 22:01:33 +0800,
> weiping zhang wrote:
>>
>> Hi,
>> how do you do bisect ?build all kernel commit one by one ?
>> as you did before:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1520982
>
2017-12-21 23:18 GMT+08:00 Bruno Wolff III :
> On Thu, Dec 21, 2017 at 22:01:33 +0800,
> weiping zhang wrote:
>>
>> Hi,
>> how do you do bisect ?build all kernel commit one by one ?
>> as you did before:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1520982
>
>
> I just did the one bisect using
On Thu, Dec 21, 2017 at 22:01:33 +0800,
weiping zhang wrote:
Hi,
how do you do bisect ?build all kernel commit one by one ?
as you did before:
https://bugzilla.redhat.com/show_bug.cgi?id=1520982
I just did the one bisect using Linus' tree. After each build, I would do
a
On Thu, Dec 21, 2017 at 22:01:33 +0800,
weiping zhang wrote:
Hi,
how do you do bisect ?build all kernel commit one by one ?
as you did before:
https://bugzilla.redhat.com/show_bug.cgi?id=1520982
I just did the one bisect using Linus' tree. After each build, I would do
a test boot and see if
2017-12-21 21:00 GMT+08:00 Bruno Wolff III :
> After today, I won't have physical access to the problem machine until
> January 2nd. So if you guys have any testing suggestions I need them soon if
> they are to get done before my vacation.
> I do plan to try booting to level 1 to
2017-12-21 21:00 GMT+08:00 Bruno Wolff III :
> After today, I won't have physical access to the problem machine until
> January 2nd. So if you guys have any testing suggestions I need them soon if
> they are to get done before my vacation.
> I do plan to try booting to level 1 to see if I can get
After today, I won't have physical access to the problem machine until
January 2nd. So if you guys have any testing suggestions I need them soon
if they are to get done before my vacation.
I do plan to try booting to level 1 to see if I can get a login prompt
that might facilitate testing. The
After today, I won't have physical access to the problem machine until
January 2nd. So if you guys have any testing suggestions I need them soon
if they are to get done before my vacation.
I do plan to try booting to level 1 to see if I can get a login prompt
that might facilitate testing. The
On Tue, Dec 19, 2017 at 10:24:52 -0800,
Shaohua Li wrote:
Not sure if this is MD related, but could you please check if this debug patch
changes anything?
The system still had cpu hangs. I've attached dmesg output saved by systemd
and retrieved after booting with a pre-rc2
On Tue, Dec 19, 2017 at 10:24:52 -0800,
Shaohua Li wrote:
Not sure if this is MD related, but could you please check if this debug patch
changes anything?
The system still had cpu hangs. I've attached dmesg output saved by systemd
and retrieved after booting with a pre-rc2 kernel.
-- Logs
On Tue, Dec 19, 2017 at 10:24:52 -0800,
Shaohua Li wrote:
Not sure if this is MD related, but could you please check if this debug patch
changes anything?
I'm doing a build now. I do use md to mirror disk partitions between two disks. I do that on another machine that
On Tue, Dec 19, 2017 at 10:24:52 -0800,
Shaohua Li wrote:
Not sure if this is MD related, but could you please check if this debug patch
changes anything?
I'm doing a build now. I do use md to mirror disk partitions between two disks. I do that on another machine that doesn't exhibit the
On Tue, Dec 19, 2017 at 10:17:43AM -0600, Bruno Wolff III wrote:
> On Sun, Dec 17, 2017 at 21:43:50 +0800,
> weiping zhang wrote:
> > Hi, thanks for testing, I think you first reproduce this issue(got WARNING
> > at device_add_disk) by your own build, then add my debug patch.
On Tue, Dec 19, 2017 at 10:17:43AM -0600, Bruno Wolff III wrote:
> On Sun, Dec 17, 2017 at 21:43:50 +0800,
> weiping zhang wrote:
> > Hi, thanks for testing, I think you first reproduce this issue(got WARNING
> > at device_add_disk) by your own build, then add my debug patch.
>
> The problem is
On Sun, Dec 17, 2017 at 21:43:50 +0800,
weiping zhang wrote:
Hi, thanks for testing, I think you first reproduce this issue(got WARNING
at device_add_disk) by your own build, then add my debug patch.
The problem is still in rc4. Reverting the commit still fixes the
On Sun, Dec 17, 2017 at 21:43:50 +0800,
weiping zhang wrote:
Hi, thanks for testing, I think you first reproduce this issue(got WARNING
at device_add_disk) by your own build, then add my debug patch.
The problem is still in rc4. Reverting the commit still fixes the problem.
I tested that
On Sun, Dec 17, 2017 at 21:43:50 +0800,
weiping zhang wrote:
Hi, thanks for testing, I think you first reproduce this issue(got WARNING
at device_add_disk) by your own build, then add my debug patch.
I'm going to try testing warnings with a kernel I've built, to try to
On Sun, Dec 17, 2017 at 21:43:50 +0800,
weiping zhang wrote:
Hi, thanks for testing, I think you first reproduce this issue(got WARNING
at device_add_disk) by your own build, then add my debug patch.
I'm going to try testing warnings with a kernel I've built, to try to
determine if warnings
On Sun, Dec 17, 2017 at 21:43:50 +0800,
weiping zhang wrote:
Hi, thanks for testing, I think you first reproduce this issue(got WARNING
at device_add_disk) by your own build, then add my debug patch.
No, the first log (that Laura copied) was from the Fedora bug and it was
On Sun, Dec 17, 2017 at 21:43:50 +0800,
weiping zhang wrote:
Hi, thanks for testing, I think you first reproduce this issue(got WARNING
at device_add_disk) by your own build, then add my debug patch.
No, the first log (that Laura copied) was from the Fedora bug and it was
from a Fedora
2017-12-17 0:32 GMT+08:00 Bruno Wolff III :
> On Fri, Dec 15, 2017 at 13:51:22 -0600,
> Bruno Wolff III wrote:
>>
>>
>> I do not know what is different. Do you have any ideas? Most likely I
>> won't be able to test any more kernels until Monday (unless I can use
2017-12-17 0:32 GMT+08:00 Bruno Wolff III :
> On Fri, Dec 15, 2017 at 13:51:22 -0600,
> Bruno Wolff III wrote:
>>
>>
>> I do not know what is different. Do you have any ideas? Most likely I
>> won't be able to test any more kernels until Monday (unless I can use most
>> of my most recent build
On Fri, Dec 15, 2017 at 13:51:22 -0600,
Bruno Wolff III wrote:
I do not know what is different. Do you have any ideas? Most likely I
won't be able to test any more kernels until Monday (unless I can use
most of my most recent build over again very soon).
The .config looks
On Fri, Dec 15, 2017 at 13:51:22 -0600,
Bruno Wolff III wrote:
I do not know what is different. Do you have any ideas? Most likely I
won't be able to test any more kernels until Monday (unless I can use
most of my most recent build over again very soon).
The .config looks like it should
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Sorry to let you confuse, WARN_ON means we catch log as following:
WARNING: CPU: 3 PID: 3486 at block/genhd.c:680 device_add_disk+0x3d9/0x460
I do not get this warning for any of the kernels I build, whether
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Sorry to let you confuse, WARN_ON means we catch log as following:
WARNING: CPU: 3 PID: 3486 at block/genhd.c:680 device_add_disk+0x3d9/0x460
I do not get this warning for any of the kernels I build, whether from
Linus' tree or
On Fri, Dec 15, 2017 at 09:18:56 -0800,
Laura Abbott wrote:
You can see the trees Fedora produces at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
which includes the configs (you want to look at the ones withtout - debug)
Thanks. I found it a little
On Fri, Dec 15, 2017 at 09:18:56 -0800,
Laura Abbott wrote:
You can see the trees Fedora produces at
https://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
which includes the configs (you want to look at the ones withtout - debug)
Thanks. I found it a little while ago and am
On 12/15/2017 08:30 AM, Bruno Wolff III wrote:
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Yes, please help reproduce this issue include my debug patch. Reproduce means
we can see WARN_ON in device_add_disk caused by failure of bdi_register_owner.
I'm
On 12/15/2017 08:30 AM, Bruno Wolff III wrote:
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Yes, please help reproduce this issue include my debug patch. Reproduce means
we can see WARN_ON in device_add_disk caused by failure of bdi_register_owner.
I'm not sure why yet,
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Yes, please help reproduce this issue include my debug patch. Reproduce means
we can see WARN_ON in device_add_disk caused by failure of bdi_register_owner.
I'm not sure why yet, but I'm only getting the
On Fri, Dec 15, 2017 at 22:02:20 +0800,
weiping zhang wrote:
Yes, please help reproduce this issue include my debug patch. Reproduce means
we can see WARN_ON in device_add_disk caused by failure of bdi_register_owner.
I'm not sure why yet, but I'm only getting the warning message you want
2017-12-15 19:10 GMT+08:00 Bruno Wolff III :
> On Fri, Dec 15, 2017 at 10:04:32 +0800,
> weiping zhang wrote:
>>
>> I just want to know WARN_ON WHAT in device_add_disk,
>> if bdi_register_owner return error code, it may fail at any step of
>> following:
>
>
>
2017-12-15 19:10 GMT+08:00 Bruno Wolff III :
> On Fri, Dec 15, 2017 at 10:04:32 +0800,
> weiping zhang wrote:
>>
>> I just want to know WARN_ON WHAT in device_add_disk,
>> if bdi_register_owner return error code, it may fail at any step of
>> following:
>
>
> Was that output in the original boot
On Fri, Dec 15, 2017 at 10:04:32 +0800,
weiping zhang wrote:
I just want to know WARN_ON WHAT in device_add_disk,
if bdi_register_owner return error code, it may fail at any step of following:
Was that output in the original boot log? I didn't see anything there
that had
On Fri, Dec 15, 2017 at 10:04:32 +0800,
weiping zhang wrote:
I just want to know WARN_ON WHAT in device_add_disk,
if bdi_register_owner return error code, it may fail at any step of following:
Was that output in the original boot log? I didn't see anything there
that had the string WARN_ON.
On Fri, Dec 15, 2017 at 10:04:32 +0800,
weiping zhang wrote:
so I want see the WARN_ON as you paste before, also my DEBUG log will help
to find which step fail.
The previous time also journalctl for output, but maybe I used slightly
different options. I'll look and see
On Fri, Dec 15, 2017 at 10:04:32 +0800,
weiping zhang wrote:
so I want see the WARN_ON as you paste before, also my DEBUG log will help
to find which step fail.
The previous time also journalctl for output, but maybe I used slightly
different options. I'll look and see if it is in the
2017-12-15 9:44 GMT+08:00 Bruno Wolff III :
> On Fri, Dec 15, 2017 at 09:22:21 +0800,
> weiping zhang wrote:
>>
>>
>> Thanks your testing, but I cann't find WARN_ON in device_add_disk from
>> this boot1.log, could you help reproduce that issue? And does this
2017-12-15 9:44 GMT+08:00 Bruno Wolff III :
> On Fri, Dec 15, 2017 at 09:22:21 +0800,
> weiping zhang wrote:
>>
>>
>> Thanks your testing, but I cann't find WARN_ON in device_add_disk from
>> this boot1.log, could you help reproduce that issue? And does this issue
>> can be
>> triggered at every
On Fri, Dec 15, 2017 at 09:22:21 +0800,
weiping zhang wrote:
Thanks your testing, but I cann't find WARN_ON in device_add_disk from
this boot1.log, could you help reproduce that issue? And does this issue can be
triggered at every bootup ?
I don't know what you need for
On Fri, Dec 15, 2017 at 09:22:21 +0800,
weiping zhang wrote:
Thanks your testing, but I cann't find WARN_ON in device_add_disk from
this boot1.log, could you help reproduce that issue? And does this issue can be
triggered at every bootup ?
I don't know what you need for the first question.
2017-12-14 23:41 GMT+08:00 Bruno Wolff III :
> On Thu, Dec 14, 2017 at 18:09:27 +0800,
> weiping zhang wrote:
>>
>>
>> It seems something wrong with bdi debugfs register, could you help
>> test the forllowing debug patch, I add some debug log, no
2017-12-14 23:41 GMT+08:00 Bruno Wolff III :
> On Thu, Dec 14, 2017 at 18:09:27 +0800,
> weiping zhang wrote:
>>
>>
>> It seems something wrong with bdi debugfs register, could you help
>> test the forllowing debug patch, I add some debug log, no function
>> change, thanks.
>
>
> I applied your
On Thu, Dec 14, 2017 at 18:09:27 +0800,
weiping zhang wrote:
It seems something wrong with bdi debugfs register, could you help
test the forllowing debug patch, I add some debug log, no function
change, thanks.
I applied your patch to
On Thu, Dec 14, 2017 at 18:09:27 +0800,
weiping zhang wrote:
It seems something wrong with bdi debugfs register, could you help
test the forllowing debug patch, I add some debug log, no function
change, thanks.
I applied your patch to d39a01eff9af1045f6e30ff9db40310517c4b45f and there
were
On Thu, Dec 14, 2017 at 18:09:27 +0800,
weiping zhang wrote:
On Thu, Dec 14, 2017 at 02:24:52AM -0600, Bruno Wolff III wrote:
On Wed, Dec 13, 2017 at 16:54:17 -0800,
Laura Abbott wrote:
>Hi,
>
>Fedora got a bug report
On Thu, Dec 14, 2017 at 18:09:27 +0800,
weiping zhang wrote:
On Thu, Dec 14, 2017 at 02:24:52AM -0600, Bruno Wolff III wrote:
On Wed, Dec 13, 2017 at 16:54:17 -0800,
Laura Abbott wrote:
>Hi,
>
>Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982
>of a boot
On Thu, Dec 14, 2017 at 02:24:52AM -0600, Bruno Wolff III wrote:
> On Wed, Dec 13, 2017 at 16:54:17 -0800,
> Laura Abbott wrote:
> >Hi,
> >
> >Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982
> >of a boot failure/bug on Linus' master (full bootlog
On Thu, Dec 14, 2017 at 02:24:52AM -0600, Bruno Wolff III wrote:
> On Wed, Dec 13, 2017 at 16:54:17 -0800,
> Laura Abbott wrote:
> >Hi,
> >
> >Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982
> >of a boot failure/bug on Linus' master (full bootlog at the bugzilla)
>
>
On Wed, Dec 13, 2017 at 16:54:17 -0800,
Laura Abbott wrote:
Hi,
Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982
of a boot failure/bug on Linus' master (full bootlog at the bugzilla)
I'm available for testing. The problem happens on my x86_64
On Wed, Dec 13, 2017 at 16:54:17 -0800,
Laura Abbott wrote:
Hi,
Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982
of a boot failure/bug on Linus' master (full bootlog at the bugzilla)
I'm available for testing. The problem happens on my x86_64 Dell Workstation,
80 matches
Mail list logo