bug#44257: guix boot stop

bug#44257: guix boot stop

[Douglas Linford]

[-- Attachment #1.1: Type: text/plain, Size: 799 bytes --]

Good day,
I am new to Guix, but not Linux, so I am familiar with Linux and it's structures.
Upon my initial install of Guix, the boot will start, but always hangs.
The last four lines in the boot messages are as follows...
populating /etc from /gnu/store/mfmgcsra291k3psl7mippy53fhqkf912-etc...

error in finalization thread: Success

[ 4.190744] udevd[217]: no sender credentials received, message ignored

[ 5.889796] Error: Driver 'pcspkr' is already registered, aborting...

And the boot process stops. It seems it would be a hardware issue.
My enclosed screenshot shows the /gnu/store folder.
And as you see, all modify times show a date of Dec 31 1969.
So, am I seeing a corrupted store, or maybe a corrupted install usb stick...or?Any thoughts or resolutions?

Respectfully,
Douglas Linford


[-- Attachment #1.2: Type: text/html, Size: 1294 bytes --]

[-- Attachment #2: Guix Store.png --]
[-- Type: image/png, Size: 381929 bytes --]

bug#44257: guix boot stop

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

Hi Douglas,

I think I've seen this before and the solution was to use the latest image, instead of the latest release because this issue was fixed after the last release. You can find more info on the latest installer at http://guix.gnu.org/en/download/latest/

Please tell us if it solves your issue or not!

Le 27 octobre 2020 10:23:07 GMT-04:00, Douglas Linford <drkrider@gmail.com> a écrit :
>Good day,
>I am new to Guix, but not Linux, so I am familiar with Linux and it's
>structures.
>Upon my initial install of Guix, the boot will start, but always hangs.
>The last four lines in the boot messages are as follows...
>populating /etc from /gnu/store/mfmgcsra291k3psl7mippy53fhqkf912-etc...
>
>error in finalization thread: Success
>
>[ 4.190744] udevd[217]: no sender credentials received, message ignored
>
>[ 5.889796] Error: Driver 'pcspkr' is already registered, aborting...
>
>And the boot process stops. It seems it would be a hardware issue.
>My enclosed screenshot shows the /gnu/store folder.
>And as you see, all modify times show a date of Dec 31 1969.
>So, am I seeing a corrupted store, or maybe a corrupted install usb
>stick...or?Any thoughts or resolutions?
>
>Respectfully,
>Douglas Linford

[-- Attachment #2: Type: text/html, Size: 1983 bytes --]

bug#44257: guix boot stop

[Douglas Linford]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

Thanks, I'll check it out.

Douglas

On Tue, Oct 27, 2020, 12:25 PM Julien Lepiller <julien@lepiller.eu> wrote:

> Hi Douglas,
>
> I think I've seen this before and the solution was to use the latest
> image, instead of the latest release because this issue was fixed after the
> last release. You can find more info on the latest installer at
> http://guix.gnu.org/en/download/latest/
>
> Please tell us if it solves your issue or not!
>
> Le 27 octobre 2020 10:23:07 GMT-04:00, Douglas Linford <drkrider@gmail.com>
> a écrit :
>>
>> Good day,
>> I am new to Guix, but not Linux, so I am familiar with Linux and it's
>> structures.
>> Upon my initial install of Guix, the boot will start, but always hangs.
>> The last four lines in the boot messages are as follows...
>>
>>    1. populating /etc from
>>    /gnu/store/mfmgcsra291k3psl7mippy53fhqkf912-etc...
>>    2. error in finalization thread: Success
>>    3. [    4.190744] udevd[217]: no sender credentials received, message
>>    ignored
>>    4. [    5.889796] Error: Driver 'pcspkr' is already registered,
>>    aborting...
>>
>> And the boot process stops. It seems it would be a hardware issue.
>> My enclosed screenshot shows the /gnu/store folder.
>> And as you see, all modify times show a date of Dec 31 1969.
>> So, am I seeing a corrupted store, or maybe a corrupted install usb
>> stick...or?Any thoughts or resolutions?
>>
>> Respectfully,
>> Douglas Linford
>>
>>
>> [image: Sent from Mailspring]
>
>

[-- Attachment #2: Type: text/html, Size: 2443 bytes --]

bug#44257: guix boot stop

[Ludovic Courtès]

Hi,

Julien Lepiller <julien@lepiller.eu> skribis:

> I think I've seen this before and the solution was to use the latest
> image, instead of the latest release because this issue was fixed
> after the last release.

I think the 1.1 ISO did install bootable systems in general though.  :-)
Do you have a specific bug in mind?

Thanks,
Ludo’.

bug#44257: guix boot stop

[Douglas Linford]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

Good day,
I seem to have the boot issue resolved, (an issue with radeon, I put nomodeset in the grub load line), but the bug issue I was referring to is when I run the command: ls -l on the /gnu/store directory, all store folders have a date stamp of Dec 31, 1969.
It doesn't seem to effect anything, so maybe I should just ignore the dates.

Douglas
Sent from Mailspring (https://link.getmailspring.com/link/1563A7D9-9391-4DB8-9059-C416F0C44DF4@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=NDQyNTdAZGViYnVncy5nbnUub3Jn), the best free email app for work
On Oct 28 2020, at 10:21 am, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi,
>
> Julien Lepiller <julien@lepiller.eu> skribis:
> > I think I've seen this before and the solution was to use the latest
> > image, instead of the latest release because this issue was fixed
> > after the last release.
>
> I think the 1.1 ISO did install bootable systems in general though. :-)
> Do you have a specific bug in mind?
>
> Thanks,
> Ludo’.
>


[-- Attachment #2: Type: text/html, Size: 1594 bytes --]

bug#44257: guix boot stop

[Leo Famulari]

The timestamps are reset to "zero" (the first date possible on Unix
systems) as part of Guix's efforts to build everything reproducibly.

On Wed, Oct 28, 2020 at 10:55:38AM -0400, Douglas Linford wrote:
> Good day,
> I seem to have the boot issue resolved, (an issue with radeon, I put nomodeset in the grub load line), but the bug issue I was referring to is when I run the command: ls -l on the /gnu/store directory, all store folders have a date stamp of Dec 31, 1969.
> It doesn't seem to effect anything, so maybe I should just ignore the dates.
> 
> Douglas
> Sent from Mailspring (https://link.getmailspring.com/link/1563A7D9-9391-4DB8-9059-C416F0C44DF4@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=NDQyNTdAZGViYnVncy5nbnUub3Jn), the best free email app for work
> On Oct 28 2020, at 10:21 am, Ludovic Courtès <ludo@gnu.org> wrote:
> > Hi,
> >
> > Julien Lepiller <julien@lepiller.eu> skribis:
> > > I think I've seen this before and the solution was to use the latest
> > > image, instead of the latest release because this issue was fixed
> > > after the last release.
> >
> > I think the 1.1 ISO did install bootable systems in general though. :-)
> > Do you have a specific bug in mind?
> >
> > Thanks,
> > Ludo’.
> >
> 

bug#44257: guix boot stop

[Douglas Linford]

[-- Attachment #1: Type: text/plain, Size: 1494 bytes --]

Awesome, thanks!
How do I close my, "non" bug?

Douglas

On Wed, Oct 28, 2020, 12:24 PM Leo Famulari <leo@famulari.name> wrote:

> The timestamps are reset to "zero" (the first date possible on Unix
> systems) as part of Guix's efforts to build everything reproducibly.
>
> On Wed, Oct 28, 2020 at 10:55:38AM -0400, Douglas Linford wrote:
> > Good day,
> > I seem to have the boot issue resolved, (an issue with radeon, I put
> nomodeset in the grub load line), but the bug issue I was referring to is
> when I run the command: ls -l on the /gnu/store directory, all store
> folders have a date stamp of Dec 31, 1969.
> > It doesn't seem to effect anything, so maybe I should just ignore the
> dates.
> >
> > Douglas
> > Sent from Mailspring (
> https://link.getmailspring.com/link/1563A7D9-9391-4DB8-9059-C416F0C44DF4@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=NDQyNTdAZGViYnVncy5nbnUub3Jn),
> the best free email app for work
> > On Oct 28 2020, at 10:21 am, Ludovic Courtès <ludo@gnu.org> wrote:
> > > Hi,
> > >
> > > Julien Lepiller <julien@lepiller.eu> skribis:
> > > > I think I've seen this before and the solution was to use the latest
> > > > image, instead of the latest release because this issue was fixed
> > > > after the last release.
> > >
> > > I think the 1.1 ISO did install bootable systems in general though. :-)
> > > Do you have a specific bug in mind?
> > >
> > > Thanks,
> > > Ludo’.
> > >
> >
>

[-- Attachment #2: Type: text/html, Size: 2383 bytes --]

bug#44257: guix boot stop

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Douglas,

Thanks for clarifying!

Douglas Linford 写道：
> the bug issue I was referring to is when I run the command: ls 
> -l on the /gnu/store directory, all store folders have a date 
> stamp of Dec 31, 1969.
> It doesn't seem to effect anything, so maybe I should just 
> ignore the dates.

It affects everything: 
<https://www.mail-archive.com/help-guix@gnu.org/msg10274.html>.

Since there's no bug I'm closing this issue, but don't hesitate to 
send any further questions or (mis)adventures to help-guix@ or 
bug-guix@.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#44257: guix boot stop

[Leo Famulari]

On Wed, Oct 28, 2020 at 12:32:49PM -0400, Douglas Linford wrote:
> Awesome, thanks!
> How do I close my, "non" bug?

You can send any message to <44257-done@debbugs.gnu.org>, or you can
send the message "close 44257" to <control@debbugs.gnu.org>.

bug#44257: guix boot stop

[Douglas Linford]

[-- Attachment #1: Type: text/plain, Size: 1035 bytes --]

Tobias,
Is there a more appropriate place to post issues so as not to fill up the bug reports with needless issues?

Douglas

Sent from Mailspring (https://link.getmailspring.com/link/296E87C0-08A8-405A-973A-A0B00140C158@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F&recipient=NDQyNTdAZGViYnVncy5nbnUub3Jn), the best free email app for work
On Oct 28 2020, at 12:33 pm, Tobias Geerinckx-Rice <me@tobias.gr> wrote:
> Douglas,
>
> Thanks for clarifying!
> Douglas Linford 写道：
> > the bug issue I was referring to is when I run the command: ls
> > -l on the /gnu/store directory, all store folders have a date
> > stamp of Dec 31, 1969.
> > It doesn't seem to effect anything, so maybe I should just
> > ignore the dates.
>
> It affects everything:
> <https://www.mail-archive.com/help-guix@gnu.org/msg10274.html>.
>
> Since there's no bug I'm closing this issue, but don't hesitate to
> send any further questions or (mis)adventures to help-guix@ or
> bug-guix@.
>
> Kind regards,
> T G-R

[-- Attachment #2: Type: text/html, Size: 1642 bytes --]

bug#44257: guix boot stop

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

Douglas,

To augment Leo's answer, here's the full skinny: 
<https://debbugs.gnu.org/server-control.html>.

Douglas Linford 写道：
> Is there a more appropriate place to post issues so as not to 
> fill up the bug reports with needless issues?

In our system, ‘issues’ are synonymous with ‘bugs’ (‘shortcomings 
in the software’, which can include feature requests).  But 
opening a bug that turns out not to be one isn't the end of the 
world!  They are easiest to fix...

Questions or other ‘troubles’ that aren't (yet) obvious flaws are 
always welcome at help-guix@gnu.org.   For more technical design- 
and code-related discussions there's guix-devel@gnu.org.

Oy vey, semantics,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#44257: guix boot stop

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

Well, since this is the Internet...

Leo Famulari 写道：
> The timestamps are reset to "zero" (the first date possible on 
> Unix
> systems) as part of Guix's efforts to build everything 
> reproducibly.

The manual does claim as much (in (guix)Binary Installation) but 
it's never been true:

  $ stat -c %Y /gnu/store/arbitrary.file
  1

0 is a valid value:

  $ touch -d @0 /tmp/foo
  $ stat -c %Y /tmp/foo
  0

But (IIRC) it's a dangerous one to use in practice as too much 
code assumes it never occurs in the wild, and use it to mean 
something special for internal use.  IIRRC GNU make was (once?) 
one such culprit.

I shall patch the manual and make this an actionable bug after 
all.

Thanks,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#44257: guix boot stop

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

Nothing specific, the description rang a bell anl I thought I already saw that and its solution, but I might have been wrong.

Le 28 octobre 2020 10:21:28 GMT-04:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hi,
>
>Julien Lepiller <julien@lepiller.eu> skribis:
>
>> I think I've seen this before and the solution was to use the latest
>> image, instead of the latest release because this issue was fixed
>> after the last release.
>
>I think the 1.1 ISO did install bootable systems in general though. 
>:-)
>Do you have a specific bug in mind?
>
>Thanks,
>Ludo’.

[-- Attachment #2: Type: text/html, Size: 977 bytes --]

bug#44257: guix boot stop

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Wed, Oct 28, 2020 at 06:31:42PM +0100, Tobias Geerinckx-Rice wrote:
> Well, since this is the Internet...
> 
> Leo Famulari 写道：
> > The timestamps are reset to "zero" (the first date possible on Unix
> > systems) as part of Guix's efforts to build everything reproducibly.
> 
> The manual does claim as much (in (guix)Binary Installation) but it's never
> been true:
> 
>  $ stat -c %Y /gnu/store/arbitrary.file
>  1

Right, I meant "zero", not 0. As you point out, it's not practical to
actually set the timestamps to zero seconds.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

bug#44257: guix boot stop

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

Leo Famulari 写道：
> Right, I meant "zero", not 0. As you point out, it's not 
> practical to
> actually set the timestamps to zero seconds.

You've lost me but I think that's OK.  The manual didn't & was 
lovingly corrected in 83c60bb0622440afe98930820186ddfa1e6e8b2f.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]