Hello!
"pelzflorian (Florian Pelz)" skribis:
> On Wed, Jun 05, 2019 at 11:13:34PM +0200, Ludovic Courtès wrote:
[...]
>> The attached patch for Shepherd moves everything before loading the
>> config file. I think it will have the desired effect, though I’m not
>> entirely sure the signal
On Wed, Jun 05, 2019 at 11:13:34PM +0200, Ludovic Courtès wrote:
> Awesome! I must say that I’m really glad you’re putting this much
> energy into reproducing issues and investigating—it’s rare for people
> who report bug to dig this deep, but it’s super helpful and motivating!
:)
> The
"pelzflorian (Florian Pelz)" skribis:
> It appears your patch fixes the issue. I admire the speed at which
> you write patches. :) Thank you!
Awesome! I must say that I’m really glad you’re putting this much
energy into reproducing issues and investigating—it’s rare for people
who report bug
It appears your patch fixes the issue. I admire the speed at which
you write patches. :) Thank you!
On Wed, Jun 05, 2019 at 11:54:23AM +0200, Ludovic Courtès wrote:
> Note that you’ll have to create a new “broken” generation with this
> patch (because we already know that the old one can
Hi,
"pelzflorian (Florian Pelz)" skribis:
> On Tue, Jun 04, 2019 at 11:21:05PM +0200, Ludovic Courtès wrote:
[...]
>> If that theory holds, the patch below (on top of the others) should
>> help. Could you give it a try?
>>
>
> Will do.
Note that you’ll have to create a new “broken”
On Tue, Jun 04, 2019 at 11:21:05PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)" skribis:
> > When booting an unbootable generation with Ludovic’s patches and then
> > rebooting a normal generation with Ludovic’s patches, /etc/shadow is
> > locked.
>
> So with this scenario, the
Hi,
"pelzflorian (Florian Pelz)" skribis:
> I got a locked /etc/shadow again now despite Ludovic’s patches (which
> would nonetheless give me a better feeling when pushed).
Will do. :-)
> When booting an unbootable generation with Ludovic’s patches and then
> rebooting a normal generation
I got a locked /etc/shadow again now despite Ludovic’s patches (which
would nonetheless give me a better feeling when pushed).
When booting an unbootable generation with Ludovic’s patches and then
rebooting a normal generation with Ludovic’s patches, /etc/shadow is
locked.
Note that I get a
On Tue, Jun 04, 2019 at 02:17:11PM +0200, pelzflorian (Florian Pelz) wrote:
> On Tue, Jun 04, 2019 at 11:22:45AM +0200, Ludovic Courtès wrote:
> > What’s the effect of this brokenness concretely? Is the wrong root file
> > system mounted, or something like that?
> >
>
When removing quiet from
On Tue, Jun 04, 2019 at 11:22:45AM +0200, Ludovic Courtès wrote:
> Hi,
>
> "pelzflorian (Florian Pelz)" skribis:
>
> > On Mon, Jun 03, 2019 at 03:22:51PM +0200, Ludovic Courtès wrote:
> >> > After multiple reconfigures, it happened again, my /etc/shadow has !
> >> > again in the password field.
Hi,
"pelzflorian (Florian Pelz)" skribis:
> On Mon, Jun 03, 2019 at 03:22:51PM +0200, Ludovic Courtès wrote:
>> > After multiple reconfigures, it happened again, my /etc/shadow has !
>> > again in the password field. My recently changed root password became
>> > empty as well, like 35902. I
For debugging, I've used "chattr +i" in the past in order to make such files
(i.e. /etc/shadow) immutable. This would hopefully expose the mutator (other
than Guix)--it should log some error somewhere.
pgpKrPhEw9hmR.pgp
Description: OpenPGP digital signature
Hello,
"pelzflorian (Florian Pelz)" skribis:
> Please add more logging and/or locking. Note that the elogind has the
> following comment in its locking implementation in
> /gnu/store/dm2ri0qvjirl0iq2ndfk5z9lq9dyk4jf-elogind-241.3-checkout/src/basic/user-util.c:
>
> /* This is roughly
On Mon, Jun 03, 2019 at 03:22:51PM +0200, Ludovic Courtès wrote:
> > After multiple reconfigures, it happened again, my /etc/shadow has !
> > again in the password field. My recently changed root password became
> > empty as well, like 35902. I did not even run sudo concurrently. The
> >
Hi Florian,
"pelzflorian (Florian Pelz)" skribis:
> After I booted to a Guix install USB, chrooted as described on the
> Arch wiki and started a Guix daemon, I could reconfigure as before.
> There was no need to fiddle with grub-install.
>
> After multiple reconfigures, it happened again, my
Please add more logging and/or locking. Note that the elogind has the
following comment in its locking implementation in
/gnu/store/dm2ri0qvjirl0iq2ndfk5z9lq9dyk4jf-elogind-241.3-checkout/src/basic/user-util.c:
/* This is roughly the same as lckpwdf(), but not as awful. We
*
Hello,
pelzflorian (Florian Pelz) ezt írta (időpont:
2019. jún. 3., Hét 8:04):
> After I booted to a Guix install USB, chrooted as described on the
> Arch wiki and started a Guix daemon, I could reconfigure as before.
> There was no need to fiddle with grub-install.
>
> After multiple
After I booted to a Guix install USB, chrooted as described on the
Arch wiki and started a Guix daemon, I could reconfigure as before.
There was no need to fiddle with grub-install.
After multiple reconfigures, it happened again, my /etc/shadow has !
again in the password field. My recently
"pelzflorian (Florian Pelz)" skribis:
> On Sun, Jun 02, 2019 at 11:38:36AM +0200, Ludovic Courtès wrote:
[...]
>> Actually, another thing that could happen is that Guix reads an
>> incomplete /etc/shadow because some other program is writing to it.
>>
>> In that case, suppose Guix reads a
On Sun, Jun 02, 2019 at 11:38:36AM +0200, Ludovic Courtès wrote:
> Hi Florian,
>
> "pelzflorian (Florian Pelz)" skribis:
>
> > On Sat, Jun 01, 2019 at 11:37:51PM +0200, Ludovic Courtès wrote:
> >> This is definitely not a problem when booting. It could be a problem if
> >> you’re concurrently
Hi Florian,
"pelzflorian (Florian Pelz)" skribis:
> On Sat, Jun 01, 2019 at 11:37:51PM +0200, Ludovic Courtès wrote:
>> This is definitely not a problem when booting. It could be a problem if
>> you’re concurrently running ‘guix system reconfigure’ (which runs
>> activation snippets, including
On Sat, Jun 01, 2019 at 11:37:51PM +0200, Ludovic Courtès wrote:
> This is definitely not a problem when booting. It could be a problem if
> you’re concurrently running ‘guix system reconfigure’ (which runs
> activation snippets, including the account updating code) and some other
> program, such
Hi Florian,
"pelzflorian (Florian Pelz)" skribis:
> On Sat, Jun 01, 2019 at 07:52:38AM +0200, pelzflorian (Florian Pelz) wrote:
>> I wonder what would change /etc/shadow.
>>
>
> If the error occurred on common non-Guix distros, it hopefully would
> have been fixed before, maybe. Of course
On Sat, Jun 01, 2019 at 07:52:38AM +0200, pelzflorian (Florian Pelz) wrote:
> I wonder what would change /etc/shadow.
>
If the error occurred on common non-Guix distros, it hopefully would
have been fixed before, maybe. Of course Guix recreates /etc/shadow
much more frequently.
Guix appears to
On Sat, Jun 01, 2019 at 12:05:44AM +0200, Ludovic Courtès wrote:
> Did the old generation you booted have user ‘florian’?
>
Yes, this is my main machine. The users are the same.
> Also, how old was it? User account management changed in March (commit
>
Hello,
"pelzflorian (Florian Pelz)" skribis:
> After I reconfigured to a broken, unbootable generation and then
> rebooted to an old working generation, I found my user account
> password was locked. This was my /etc/shadow:
>
> root::18045::
> florian:!:18045::
> nobody:!:18045::
After I reconfigured to a broken, unbootable generation and then
rebooted to an old working generation, I found my user account
password was locked. This was my /etc/shadow:
root::18045::
florian:!:18045::
nobody:!:18045::
guixbuilder01:!:18045::
guixbuilder02:!:18045::
27 matches
Mail list logo
