Re: Shepherd timers

[Development of GNU Guix and the GNU System distribution.]

Hi Ludo'

On Fri, Apr 19 2024, Ludovic Courtès wrote:

> that’s already possible with the #:user argument of ‘command’.

While 'command' works and was in your initial example, I had trouble
tracking down the documentation for it.  Is it a record entry destined
for 'shepherd-command'?

Spoiled by Guix's seamless Guile integration, I don't shell out much
anymore.  Will 'command' accept a thunk?

Kind regards
Felix

Re: Should we include nss-certs out of the box?

[Fabio Natali]

On 2024-04-20, 11:06 +0100, Fabio Natali  wrote:
> I'll send an update here.

Hi Maxim,

There's a couple of mentions of 'nss-certs' in the manual that might be
rephrased to reflect '65e8472a4b6fc6f66871ba0dad518b7d4c63595e'.

For what it's worth, I put together a micro-patch and sent it over as a
follow-up to #70451.

https://issues.guix.gnu.org/70451#4

Thanks, cheers, Fabio.


-- 
Fabio Natali
https://fabionatali.com

Re: System can no longer be reconfigured

[John Kehayias]

Dear Felix et al,

On Sun, Apr 21, 2024 at 08:54 AM, Felix Lechner via \"Development of GNU Guix 
and the GNU System distribution.\" wrote:

> Hi Ludo'
>
> On Fri, Apr 19 2024, Ludovic Courtès wrote:
>
>> Is it not hanging during Shepherd service upgrade?
>
> Yes, thank you!  It was hanging during the Shepherd system upgrade due
> to an invalid calendar-event specification.  In a service that uses both
> #:days-of-month as well as #:days-of-week, I got confused because the
> count starts with one in one, and with zero in the other. [1]
>
> Thank you for your kind pointer in another forum! The issue is now
> solved.
>
> On this occasion, please allow me to mention for everyone's benefit that
> your support level for the Shepherd is very generous---especially when
> the complaints involve repeated user errors by the people bothering you.
>
>> If that is the case, (1) that is not preventing upgrade from happening
>> since that’s the very last step (it just means you’ll have to reboot),
>
> Yes, but 'reboot' and 'halt' also stop working, which meant that I
> issued 'sync' a few times and then, crossing my fingers, pressed the
> reset button a few hundreds of a second later.  I wish there were a way
> to force a reboot.
>

Not sure if this is what you did, but for anyone else that didn't know
this (like me, for many years!) there is the Magic SysRq Key to talk
directly to the kernel:


I always remember "BUSIER" backwards as the sequence to push to safely
stop everything, sync disks, and reboot, without needing to use the
power button. Or the mnemonics: "raising elephants is so utterly
boring" or "reboot even if system utterly broken." Hopefully rarely
needed, but really handy when it is.

(I wrote a whole basic guide to killing things and these last keys:
)

>> (2) it’s a shepherd-related bug for which perhaps there are clues in
>> /var/log/messages?
>
> Thank you for that pointer, too.  I'm still learning about where to look
> for error messages, whose destination is not always obvious to me.
>
> Kind regards
> Felix
>
> [1]
> 

Re: No public interface for shepherd-package

[Development of GNU Guix and the GNU System distribution.]

On Fri, Apr 19 2024, Ludovic Courtès wrote:

> Is ‘shepherd’ among your channels?

Sorry, it works fine.

My message was borne from a terrible desperation after one of my most
important machines refused to reconfigure for a week.  As so often with
technical systems, it was an operator error. [1]

Kind regards
Felix

[1] https://mail.gnu.org/archive/html/guix-devel/2024-04/msg00210.html

Re: Fallout from recent nss-certs changes

[Ian Eure]

No, this is not a bug.  specification->package always returns the latest 
version of a package and has no way of knowing what variable(s) that package 
object is bound to.

On April 21, 2024 8:02:50 AM PDT, Felix Lechner  
wrote:
>Hi,
>
>On Sat, Apr 20 2024, Ian Eure wrote:
>
>> If an operating-system’s packages includes `(specification->package
>> "nss-certs")', this causes breakage, because that form selects version
>> 3.98, but %base-packages includes 3.88.1, which causes an error on the
>> next `guix system reconfigure' due to conflicting package versions in
>> the profile.
>
>Why does the unversioned stringy selector (specification->package
>"nss-certs") resolve to a version different from the unversioned
>variable nss-certs?  Is that a bug?
>
>Kind regards
>Felix
>
>P.S. I hoped to use the word "reified" but did not know how it fit in.

Thanks,

  — Ian

Re: Fallout from recent nss-certs changes

[Ian Eure]

The change is mentioned in the channel news, but it says nothing about needing 
to remove that part of the config.


On April 21, 2024 1:32:38 AM PDT, "pelzflorian (Florian Pelz)" 
 wrote:
>Hello Ian.  My understanding of the nss-certs etc/news.scm item had been
>that we should remove (specification->package "nss-certs"), which became
>unnecessary and clutters config.scm.  From what you write, this was
>actually not intended, but it is still not a bug IMHO.
>
>(I’m not involved with the change, though.)
>
>Regards,
>Florian

Thanks,

  — Ian

Re: System can no longer be reconfigured

[Development of GNU Guix and the GNU System distribution.]

Hi Ludo'

On Fri, Apr 19 2024, Ludovic Courtès wrote:

> Is it not hanging during Shepherd service upgrade?

Yes, thank you!  It was hanging during the Shepherd system upgrade due
to an invalid calendar-event specification.  In a service that uses both
#:days-of-month as well as #:days-of-week, I got confused because the
count starts with one in one, and with zero in the other. [1]

Thank you for your kind pointer in another forum! The issue is now
solved.

On this occasion, please allow me to mention for everyone's benefit that
your support level for the Shepherd is very generous---especially when
the complaints involve repeated user errors by the people bothering you.

> If that is the case, (1) that is not preventing upgrade from happening
> since that’s the very last step (it just means you’ll have to reboot),

Yes, but 'reboot' and 'halt' also stop working, which meant that I
issued 'sync' a few times and then, crossing my fingers, pressed the
reset button a few hundreds of a second later.  I wish there were a way
to force a reboot.

> (2) it’s a shepherd-related bug for which perhaps there are clues in
> /var/log/messages?

Thank you for that pointer, too.  I'm still learning about where to look
for error messages, whose destination is not always obvious to me.

Kind regards
Felix

[1] 
https://codeberg.org/lechner/system-config/commit/8639339dbd3ad4c51ceba239bf4aadc56223fb4a

Re: A capture-stdout wrapper procedure in (guix build utils)?

[Development of GNU Guix and the GNU System distribution.]

Hi Fabio,

On Sat, Apr 20 2024, Fabio Natali wrote:

> do you think it might be worth to add it (or a variation thereof) to
> '(guix build utils)'?

I use this [1] which gives the caller access to the exit status and is
also slightly shorter:

(define (command-with-output-to-string/status* command)
  (let* ((input-pipe (apply open-pipe* OPEN_READ command))
 (output (get-string-all input-pipe))
 (exit-val (status:exit-val (close-pipe input-pipe
(values output exit-val)))

It may be better, however, to finally fix Guile's 'system' and 'system*'
to work with 'with-output-to-string'. [2]

Kind regards
Felix

[1] 
https://codeberg.org/lechner/preambled-exec/src/commit/c5c498c3890f22cda070fe35b314f01982ebc885/test/simple-variable.scm#L28-L32
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43364

Re: Fallout from recent nss-certs changes

[Development of GNU Guix and the GNU System distribution.]

Hi,

On Sat, Apr 20 2024, Ian Eure wrote:

> If an operating-system’s packages includes `(specification->package
> "nss-certs")', this causes breakage, because that form selects version
> 3.98, but %base-packages includes 3.88.1, which causes an error on the
> next `guix system reconfigure' due to conflicting package versions in
> the profile.

Why does the unversioned stringy selector (specification->package
"nss-certs") resolve to a version different from the unversioned
variable nss-certs?  Is that a bug?

Kind regards
Felix

P.S. I hoped to use the word "reified" but did not know how it fit in.

Re: Guix bios installation: Grub error: unknown filesystem

[Franz Geffke]

Hi Ada,

I very much appreciate your detailed response.

For a moment I thought my email hadn't made it to this list, both because it 
didn't show up, and the lack of acknowledgment. After a day or so, I filed a bug 
report instead [1] - which produced the expected acknowledgement... Still learning.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866603

> Basically, there is a compatibility issue regarding the ext4 filesystem 
features that GRUB 2.06 supports and the features that `e2fsprogs@1.47.0` 
enables by default when creating your ext4 filesystem.


So this broke on 26th of March, with commit 
ce78f9cb668971954add5473c8549ebb00424f66.


> To fix this, you will need to make sure you create your ext4 filesystem with 
the following features: `mkfs.ext4 /dev/you-partition-here -O 
has_journal,ext_attr,resize_inode,dir_index,filetype,needs_recovery,extent,flex_bg,sparse_super,large_file,huge_file,uninit_bg,dir_nlink,extra_isize`


I didn't realize mkfs.ext4 would accept these directly, thank you.

Certainly hope the latest version of GRUB will be merged asap, so it doesn't 
affect more users. Not a great experience when the initial install requires an 
undocumented workaround - but then again, it does (still) work on the guix ISO 
from the homepage.


Have a great day!

Best,
Franz

Re: hello from a new commiter

[Janneke Nieuwenhuizen]

Zheng Junjie writes:

Hi Junjie,

> I have been granted commit access.

Yay!

> You might know me, Past few years I fix some error on riscv64, fix some
> cross-compilation, Add plasma-desktop, etc. I'm using this access to
> better improve these.

Welcome and keep up the good work!

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen   | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Re: hello from a new commiter

[宋文武]

Zheng Junjie  writes:

> hello! 
>
> I have been granted commit access.
>
> You might know me, Past few years I fix some error on riscv64, fix some
> cross-compilation, Add plasma-desktop, etc. I'm using this access to
> better improve these.

That's great, thank you for the work and looking forward for future
improvements!

Re: Fallout from recent nss-certs changes

[pelzflorian (Florian Pelz)]

Hello Ian.  My understanding of the nss-certs etc/news.scm item had been
that we should remove (specification->package "nss-certs"), which became
unnecessary and clutters config.scm.  From what you write, this was
actually not intended, but it is still not a bug IMHO.

(I’m not involved with the change, though.)

Regards,
Florian

hello from a new commiter

[Zheng Junjie]

hello! 

I have been granted commit access.

You might know me, Past few years I fix some error on riscv64, fix some
cross-compilation, Add plasma-desktop, etc. I'm using this access to
better improve these.

Here is my account:
https://savannah.gnu.org/users/Z572
https://mastodon.social/@Z572
https://github.com/Z572/
https://gitlab.com/Z572/

email:
zhengjun...@iscas.ac.cn
873216...@qq.com
zhengjun...@yandex.com

Here is my key

fingerprint: "7EBE A494 60CE 5E2C 0875  7FDB 3B5A A993 E1A2 DFF0"

-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGHVJjQBEADAhulsJzo70F1CaLPqTyii/VpXKMDTQUAoguc+kHZ22kxZrJkv
fAd8muru6FCKEH1S2341xnt+0MmyL/OmByKgsuSJ9XUilb05JnsAGhSovYjqGrR0
NPHNKEMHzXaIVR3MOwhpHTxxOVzh+AMhTtmc+wZ2QxSsW0tZMTUU/YCOSsWimYwq
N8mztRcmg/qC5HXTnO+hOFRNC+bBc64UN99MS8KSGCtf+piVEVdnOiFiZ/ErUs2a
kW+9bc/uDXes1ZzVrAZMzdf9rq6gFLpTfgMZ/eUi8ykOAKRj+rutzTQ6ExvV1g/D
iM/jwTfZg1SO/rTe/IQqYNFBTxAm4yODOUadrAHVOp3J0qm4HM5l/0px5tb0R8N8
BJKY+6T5yXgEQlT7KgMwcmMsG3IfsTtcsnpK8LwQjjOfNnNpyKVngKV94vaR1jPj
4wq5aVpv92YvrbW4brN7CdVGCBKnwwfGewuC5xW7XiDZMSYdLi0US1/bcVEbjhju
qPsd9KGAYvhgKlARb89WyICdxkyPtBWMuNFqa0tt8EccfRfqz0QDqkVg4Sc/yu5p
6C/XwmZu0CLWNAz6efAZltGfDPAtzAicrgmM31VrnYdyREuVdLEr6tsj+YM5REmw
FONfuVhIeg3LbqUp0pCZqZRAltLodg4uiCIr6zYpTduMN5y7rY8sevW4CQARAQAB
tBhaLTU3MiA8WjU3MkB6NTcyLm9ubGluZT6JAkkEEwEIADMWIQR+vqSUYM5eLAh1
f9s7WqmT4aLf8AUCYdUmNAIbAwMLCQgFFQoJCAsCFgACHgECF4AACgkQO1qpk+Gi
3/CnGxAAhqWLQEzw5FDYECdNgh/i+nH/ibJ7I9e/axmvWGo4cvqfDrqErbNgo7xj
zNIwWzp9jJlu4lC6UxQw/mbkrjkdPktlxMjZRA6hZ0iN2iIXxW3SgDqvo0kX+cGI
3OMLOcUqndGNvp4WIc0tyk+Ghpwac3NwNpX8IxMu+1j7K6gvPDmFGBRgzc5hrq4l
nq7WvHK8yjNKbfmODQXcUlLY1eeX8D1Bl/eb35iPIDCyyc9LxqH+Rmy2Jed4iXDC
fZQPeUmFL+ZqUrS81fzO+6z9T9dMG7jprXMNHfL1O+Kt5mQ/t0vuF23fQhfR/fFI
2Mjj+d13lKrxZCu1fXlPk5Kjpjb9i8STpJloQV0MONwbw98lz/CKMp9zu1co6pHL
8lDW7gce6fPU/zGCLDgr4+GuRrNNFRHZP3gDNbI0q5YTp0gbf/pjkph+fhGIa+H1
izs5KDlUu9BKf9Uj7+I7i3JQ65UCHTboTcGw5bcB4zakJcwW9KpnYyKNPm+FhB2U
fkIVzktGxkJnQ0CcLS1/YCsbxU1mZu19y6lt4DKypQ5rReMkkp3AfVIj6pjHTESj
gnXlzRveOiB9+VYzrMJVt2IDqlxElv4fJ0z1fU3/r8ZrTH1tiuZ1NDIVJ0iLH+hb
yzmDmj0gjezhFSYiq9iARWi4AB/eQx80dcosZNS1lEp+AleXzNK0H1poZW5nIEp1
bmppZSA8ODczMjE2MDcxQHFxLmNvbT6JAkkEEwEIADMWIQR+vqSUYM5eLAh1f9s7
WqmT4aLf8AUCZON60gIbAwMLCQgFFQoJCAsCFgACHgECF4AACgkQO1qpk+Gi3/Ac
4A/+IqTqvGaGEr+9L+/oU9TjMkEzDAqqeB7UU4LC1Wv8ZDa5+2TMCHhGgFmu0TL1
bW9SE7YtUm0kbp26x6neD5m+HPgCvib6x+r+RdhqhR8BM/KTa2j7ULHHquLC8xZk
9SFax9NnStjYp6oTD0EnFEPt197MbZcpmRgyHAraFsA5Od9xUhU4hmMKfeVYMuzW
91ieQEi41J+DPOBYdjcwOvHO90EdXh6mLraM1eViKX8FtUGkUiBOyhbO9OIIBIUo
jZMT1VXw4gHOHfFGHpFwetKKGprfoSOWnjpGrqSpnQiVJnMsFq+/r1unFxuT8k2j
VczFOGvRINx2/Or6eLtr7cSr52gue01Wl39uUFJ8Vge7/PuJm4QQI2Q5TkSqn8Kh
/SqvuOT1GU5KLxNOTeTFBEOtG52UkiZggEQbomMWoCYuzNagLb1XRFnz99PF/Qwu
BMM4Lne8mTFndCIIj2ffyX4Ja+hdR0wk18a5ePzYIVw3bYNsEZ3QvjFukTT9HD4b
nDXp3FTf738FMMJN06oZdYwm5rq5lOjzKshGTpyg6w3S0RTtuTeoNlOmxooGcPMF
LKrDK4gXlWVTrfM8gJpBP1hMNBb7+wNR4Oo6LQoXx3JvgybnIC0gGd8jWgTKz3al
VTnrnyM3RxESxDso7KWFfvlQMYnk+f4MMieapHlEeK6j7P65Ag0EYdUmNAEQALkL
bFjnwSbc3hFbqy+ZoroIk2hvO6MDbtTQ707d6p3ZnkIumcQauipp791e6BLOoZ/7
GZDewRdJWmM4V0imGZUvgdELRMkIdW6BubH2t5Kkek7n7OeCIC4Fxf/hzP5rshJc
Fsp3i0coWajpMuyNcf/bzx5bKY8NG3RBW6ehmi0xfxCbYBCOf1t+GP8ftDwD5FlQ
BbgQPzaQcu9cThH8uQ8TI7/YM/2J566wqrJfgrkxeTCO4t7gZLvhVLJvu3uNmBxa
iVmg+7bxcTmIeua/slEPcXMyYNnw13VQv0VLnSQDhazEyKlrYBou8uQSnrSJVWON
64ssgfkID4fSp0DrJqBJ5iWulmEYHSEVp3iKPj8ElB7d7XjNnZcFIKuFaOIHsIeq
wIoFv2fWLbXAQ+4O3gF0MKwrwXSwpVE0ui+ugSVed5p1Ql4vBmY05aQtVBUd0WLb
KS22dFhFMwTXkVrD7Ai+23Lh1joMPf9PQuJupjHJZEnu1Y/gYc5dOnTXTUJnkv9B
eFwpJMtPXsJLo8CO27tceKxLZpyojxReJcOZXxXy9Oxe0aAAkWDtHhYVpT1AeOC8
O1of1aP5W4jdQkGGJJg69Ztyri4GUfo08VSFKTTfu+1N+N3gmu1hpaJDQoiyhzZl
/52tvQjh9LvW2toEotNS+OnupgS47ur9+BrMmfMHABEBAAGJAjYEGAEIACAWIQR+
vqSUYM5eLAh1f9s7WqmT4aLf8AUCYdUmNAIbDAAKCRA7WqmT4aLf8E8YEACOx9M7
STsDp5S06GNH+2neOAqWDAkKuz+Qp7B045h94JLzK8a1VT1mg6dTkWKqaVW2932N
o8xVJGiw7atra9exy6mrjLR6RYFLan4WO0fS99SUyAG1dCSSkLkXUGg7Zvjs1n5g
4cHtlAxApUirVPyUC0UAwCy3evOH7H8/WqEx6/+QsvTKEQMKxCV3RWcPR6UAvY5r
8hBHyHUBq7fZLIEOg1vWqAhV+K+wTxEycO1qJal/RyUE5PPzeWULLtH/nvmkFZG1
Od8fWghe0KVhsL8Dk9DyNGeqo0mb5rvXRhKIwEqyDm8Pijl0zRXJGdjOzV6hpgP5
Wp/+FcqYrrJZOQucOpOpuU6AbQ9eJaQIE/Q0B3QEsVIs6UMv6+VAVNyWXcUiIAFd
trEZmKkaULEaQ0Mfp1+M8gzrF33nUJK3IYzLyuZWn7sb+RxGblwSZqJ384nzFfce
oztKmA9IGcLTOTzNa02aSz7FnB3toMQfXcTpBS5WvvMKUgQpwwwmwkFiXX6eN/Sl
uw3efkEG0hFMi7CMqFpwR4+7CN7Juo0MyiZdQmfWFKysliRDOdCpLWEZvZlX1wkv
M/WKtO6hNgiravkPzllh8ag1DzPw31S3HhqLUHCOk1/JPMk2InGvQn6jlznVvI3I
yhZIsifB12dtWFIcPTEynfb7XLq7nVr6Ni4FUA==
=zD7D
-END PGP PUBLIC KEY BLOCK-


signature.asc
Description: PGP signature

Re: Guix bios installation: Grub error: unknown filesystem

[Ada Stevenson]

Hi Franz,

On 4/19/24 2:24 PM, Franz Geffke wrote:

I'm having trouble installing guix in qemu, using a "fresh" guix ISO.

```
building 
/gnu/store/byjlc85abyjc3fjj9z982677skmda7ib-module-import-compiled.drv...
building 
/gnu/store/psw8xn9qpsjjnrqmjrfv0v3jj9fphq5m-module-import-compiled.drv...
building 
/gnu/store/a1zcrrcdwhb4wb2g4r0ph8mqclq7f5xn-install-bootloader.scm.drv...
guix system: error: 
'/gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install 
--no-floppy --target=i386-pc --boot-directory /mnt/boot /dev/sda' exited with 
status 1; output follows:

   Installing for i386-pc platform.
   /gnu/store/li1ic17hz460vp1sg0cx2dwgw8q7i8pj-grub-2.06/sbin/grub-install: 
error: unknown filesystem.
```

Here's what I've tried so far:
1. The ISO from 2022 
https://ftpmirror.gnu.org/gnu/guix/guix-system-install-1.4.0.x86_64-linux.iso: 
Success
2. Generated a new ISO today: Failure

These are the channels, on the booted ISO:

```
guix describe
   guix 65e8472
 repository URL: https://git.savannah.gnu.org/git/guix.git
 branch: master
 commit: 65e8472a4b6fc6f66871ba0dad518b7d4c63595e
```

Steps I used to install (1) and (2):

```
parted -s /dev/sda -- mklabel msdos mkpart primary ext4 1MiB 100%
parted /dev/sda set 1 boot on
mkfs.ext4 -L my-root /dev/sda1
mount LABEL=my-root /mnt
cp /etc/configuration/lightweight-desktop.scm /mnt/etc/config.scm
# adjust disk, bootloader
herd start cow-store /mnt
guix system init /mnt/etc/config.scm /mnt
```

Findings:

I didn't really dig too deeply yet; Only noticed that this command produces a 
different result, depending on whether the install succeeds, or not `grub-probe 
--target=fs --device /dev/sda`

- Success: `ext2`
- Failure: `grub-probe: error: unknown filesystem.`

I also tried using GPT instead of MBR, but it makes no difference.



I've encountered this problem too, and managed to solve it. I'm 85% sure 
you're experiencing the same problem as me, and I've been meaning to 
document it somewhere - its a super obtuse error and it is a showstopper 
when it comes to installing guix.


Basically, there is a compatibility issue regarding the ext4 filesystem 
features that GRUB 2.06 supports and the features that 
`e2fsprogs@1.47.0` enables by default when creating your ext4 
filesystem. When these features are enabled, it changes the structure of 
the filesystem enough that GRUB can't recognise it properly and it fails.


To fix this, you will need to make sure you create your ext4 filesystem 
with the following features:
`mkfs.ext4 /dev/you-partition-here -O 
has_journal,ext_attr,resize_inode,dir_index,filetype,needs_recovery,extent,flex_bg,sparse_super,large_file,huge_file,uninit_bg,dir_nlink,extra_isize`


These are the features that worked for me. I had to do a lot of trial 
and error, and I used `tune2fs -l` to see what features weren't 
supported. The ones I can remember are the metadata_csum features, and 
some other ones (they showed up as FEATURE_X when running `tune2fs` on 
my Guix installation image, so I used a Gparted Live CD to get rid of 
the features that weren't recognised by tune2fs).


This should allow grub to recognise your filesystem during the 
installation process. I think using a later version of grub would fix 
this, but that hasn't happened yet. I think there's a patch to upgrade 
it in `core-updates` somewhere, but I'm not sure.


Anyway, hope this helps!

Warmly,
Ada