GuixSD SSD install hangs at clocksource

  • Done
  • quality assurance status badge
Details
4 participants
  • Ludovic Courtès
  • Florian Paul Schmidt
  • myglc2
  • zimoun
Owner
unassigned
Submitted by
myglc2
Severity
normal
M
M
myglc2 wrote on 20 Mar 2016 20:56
(address . bug-guix@gnu.org)
87oaa853ex.fsf@gmail.com
I tried to upgrade my headless server running GuixSD from to HD to SSD.

First I shot myself in the foot doing 'guix init' on the SSD. Possibly
by labeling the SSD root using the same label as the system HD root, or
maybe I miss-specified the bootloader device?

Anyway, to dig myself out, I switched to a 2nd server running
Guix/Debian and ...

- reinstalled GuixSD to the 1st server's HD, see
"c06system.scm.log". This runs fine back in the 1st server.

- I did a near-identical install to a SSD (Kingston ssdnow300), see
"c06system-ssd.scm.log". If installed on the 1st server this shows
Guix welcome screen, loads the keyboard & mouse drivers, then hangs
showing:

"clocksource: Switched to clocksource tsc"

So to summarize, ~identical install on HD runs fine, install on SSD
hangs.

Please see attached logs. - George
F
F
Florian Paul Schmidt wrote on 20 Mar 2016 21:58
(address . bug-guix@gnu.org)
56EF0EED.5010102@gmx.net
On 20.03.2016 20:56, myglc2 wrote:

Toggle quote (7 lines)
> - I did a near-identical install to a SSD (Kingston ssdnow300), see
> "c06system-ssd.scm.log". If installed on the 1st server this shows
> Guix welcome screen, loads the keyboard & mouse drivers, then hangs
> showing:
>
> "clocksource: Switched to clocksource tsc"

This is just a shot in the dark, but I use SSD systems, too, and I
noticed that the first boot of a guixsd installation hangs for a while
collecting entropy before displaying a corresponding message IIRC and I
faintly remember the "switching to clocksource" message. Did you try
banging the keyboard? Maybe that's not possible on a headless server
though. Did you let it sit for a while?

Flo


--
Attachment: signature.asc
M
M
myglc2 wrote on 21 Mar 2016 14:44
(address . bug-guix@gnu.org)
87d1qorln8.fsf@gmail.com
Florian Paul Schmidt <mista.tapas@gmx.net> writes:

Toggle quote (17 lines)
> On 20.03.2016 20:56, myglc2 wrote:
>
>> - I did a near-identical install to a SSD (Kingston ssdnow300), see
>> "c06system-ssd.scm.log". If installed on the 1st server this shows
>> Guix welcome screen, loads the keyboard & mouse drivers, then hangs
>> showing:
>>
>> "clocksource: Switched to clocksource tsc"
>
> This is just a shot in the dark, but I use SSD systems, too, and I
> noticed that the first boot of a guixsd installation hangs for a while
> collecting entropy before displaying a corresponding message IIRC and I
> faintly remember the "switching to clocksource" message. Did you try
> banging the keyboard? Maybe that's not possible on a headless server
> though. Did you let it sit for a while?
>
> Flo
Thanks Flo. Can't test that theory at the moment. But I do have a
display attached (which is how I saw the "clocksource..." message).

FWIW, in the HD install there is a prompt for keyboard input. It seems
like the SSD install hung before it reached that. - George
L
L
Ludovic Courtès wrote on 9 Nov 2016 21:50
(name . myglc2)(address . myglc2@gmail.com)(address . 23072@debbugs.gnu.org)
8760nw74yk.fsf@gnu.org
Hi,

myglc2 <myglc2@gmail.com> skribis:

Toggle quote (25 lines)
> Florian Paul Schmidt <mista.tapas@gmx.net> writes:
>
>> On 20.03.2016 20:56, myglc2 wrote:
>>
>>> - I did a near-identical install to a SSD (Kingston ssdnow300), see
>>> "c06system-ssd.scm.log". If installed on the 1st server this shows
>>> Guix welcome screen, loads the keyboard & mouse drivers, then hangs
>>> showing:
>>>
>>> "clocksource: Switched to clocksource tsc"
>>
>> This is just a shot in the dark, but I use SSD systems, too, and I
>> noticed that the first boot of a guixsd installation hangs for a while
>> collecting entropy before displaying a corresponding message IIRC and I
>> faintly remember the "switching to clocksource" message. Did you try
>> banging the keyboard? Maybe that's not possible on a headless server
>> though. Did you let it sit for a while?
>>
>> Flo
> Thanks Flo. Can't test that theory at the moment. But I do have a
> display attached (which is how I saw the "clocksource..." message).
>
> FWIW, in the HD install there is a prompt for keyboard input. It seems
> like the SSD install hung before it reached that. - George

Any update on this bug?


Ludo’.
L
L
Ludovic Courtès wrote on 11 Jan 2017 23:31
(name . myglc2)(address . myglc2@gmail.com)(address . 23072@debbugs.gnu.org)
877f61ut2v.fsf@gnu.org
myglc2 <myglc2@gmail.com> skribis:

Toggle quote (25 lines)
> Florian Paul Schmidt <mista.tapas@gmx.net> writes:
>
>> On 20.03.2016 20:56, myglc2 wrote:
>>
>>> - I did a near-identical install to a SSD (Kingston ssdnow300), see
>>> "c06system-ssd.scm.log". If installed on the 1st server this shows
>>> Guix welcome screen, loads the keyboard & mouse drivers, then hangs
>>> showing:
>>>
>>> "clocksource: Switched to clocksource tsc"
>>
>> This is just a shot in the dark, but I use SSD systems, too, and I
>> noticed that the first boot of a guixsd installation hangs for a while
>> collecting entropy before displaying a corresponding message IIRC and I
>> faintly remember the "switching to clocksource" message. Did you try
>> banging the keyboard? Maybe that's not possible on a headless server
>> though. Did you let it sit for a while?
>>
>> Flo
> Thanks Flo. Can't test that theory at the moment. But I do have a
> display attached (which is how I saw the "clocksource..." message).
>
> FWIW, in the HD install there is a prompt for keyboard input. It seems
> like the SSD install hung before it reached that. - George

Any update on this bug?


Ludo’.
L
L
Ludovic Courtès wrote on 11 Jan 2017 23:31
control message for bug #23072
(address . control@debbugs.gnu.org)
8760llut2n.fsf@gnu.org
tags 23072 moreinfo
M
M
myglc2 wrote on 24 Jan 2017 20:15
Re: bug#23072: GuixSD SSD install hangs at clocksource
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 23072@debbugs.gnu.org)
86vat41d8n.fsf@gmail.com
On 01/11/2017 at 23:31 Ludovic Courtès writes:

Toggle quote (33 lines)
> myglc2 <myglc2@gmail.com> skribis:
>
>> Florian Paul Schmidt <mista.tapas@gmx.net> writes:
>>
>>> On 20.03.2016 20:56, myglc2 wrote:
>>>
>>>> - I did a near-identical install to a SSD (Kingston ssdnow300), see
>>>> "c06system-ssd.scm.log". If installed on the 1st server this shows
>>>> Guix welcome screen, loads the keyboard & mouse drivers, then hangs
>>>> showing:
>>>>
>>>> "clocksource: Switched to clocksource tsc"
>>>
>>> This is just a shot in the dark, but I use SSD systems, too, and I
>>> noticed that the first boot of a guixsd installation hangs for a while
>>> collecting entropy before displaying a corresponding message IIRC and I
>>> faintly remember the "switching to clocksource" message. Did you try
>>> banging the keyboard? Maybe that's not possible on a headless server
>>> though. Did you let it sit for a while?
>>>
>>> Flo
>> Thanks Flo. Can't test that theory at the moment. But I do have a
>> display attached (which is how I saw the "clocksource..." message).
>>
>> FWIW, in the HD install there is a prompt for keyboard input. It seems
>> like the SSD install hung before it reached that. - George
>
> Any update on this bug?
>
> http://bugs.gnu.org/23072
>
> Ludo’.

Hi Ludo,

I did experiments and I now see that this happens when the boot drive ID
has changed from what was specified as the grub-configuration device in
the most recent 'system init' or 'system reconfigure' operation.

This can happen, for example, when one moves drives around or when one
inserts a new drive in an empty lower SATA slot below drives holding
GuixSD.

This seemed like a bug to me because the doc says ...

• Make sure the ‘grub-configuration’ form refers to the device you
want to install GRUB on.

... but there is no mention that it affects boot operation.

Also I assumed, possibly wrongly, that GuixSD does not need the config
to tell it which device grub is on at boot because it is already running
on the boot device ;-)

So, I don't know ... Is this a bug or is this expected behavior.

If it is not a bug it seems like an opportunity to reduce the fragility
of GuixSD configurations.

HTH - George
Z
Z
zimoun wrote on 18 Feb 2020 15:09
Hunting#23072: GuixSD SSD install hangs at clocksource
CAJ3okZ2qw9=t6GM3s7SEVHk+43TQ_v_5AuVgpPuNas5w5mqWSw@mail.gmail.com
Dear,

Any update about the bug#20372 [1]?

Since it is 3 years old, does it still happen with a recent Guix versions?



All the best,
simon
Z
Z
zimoun wrote on 20 Feb 2020 01:45
(address . 23072@debbugs.gnu.org)
CAJ3okZ1RnjN+jBCGTuYyw48rR6gmdtReBeT-o0njLq5=ptJFoA@mail.gmail.com
On Tue, 18 Feb 2020 at 17:00, zimoun <zimon.toutoune@gmail.com> wrote:
Toggle quote (9 lines)
> On Tue, 18 Feb 2020 at 16:56, my glc2 <myglc2@gmail.com> wrote:

> > I don't know. i haven't changed drive config since 2017, or, for that matter, upgraded since 2018.
>
> Ok.
> Keep in touch if you change something. :-)
>
> (I am in the process of triaging old bugs ;-))

For the record, line above why the bug is still open.
Z
Z
zimoun wrote on 26 Nov 2021 02:31
Re: bug#23072: Hunting#23072: GuixSD SSD install hangs at clocksource
86sfvjr9br.fsf@gmail.com
Hi,

On Thu, 20 Feb 2020 at 01:45, zimoun <zimon.toutoune@gmail.com> wrote:
Toggle quote (5 lines)
> On Tue, 18 Feb 2020 at 17:00, zimoun <zimon.toutoune@gmail.com> wrote:
>> On Tue, 18 Feb 2020 at 16:56, my glc2 <myglc2@gmail.com> wrote:
>
>> > I don't know. i haven't changed drive config since 2017, or, for that matter, upgraded since 2018.

This old bug is open because an error back in 2016. Nothing change
since 2017 and last upgrade since 2018. A lot of thing has changes
since then. Therefore I am closing.

Feel free to reopen if you consider it is worth to keep it open and if
it could useful.



Cheers,
simon
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 23072@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 23072
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch