bug#30589: serial login not working

[George myglc2 Clemmer]

The recent move of agetty-service into #base-services caused serial
login to stop working here. Previously this worked ...

(agetty-service (agetty-configuration (tty "ttyS1")
(baud-rate "115200")))

First I tried removing the lines above. Then I tried ...

(define %my-services
  (modify-services %base-services
   (agetty-service-type config =>
(agetty-configuration
 (tty "ttyS1")
 (baud-rate "115200")

I can confirm that ...

root@g1 /home/g1# sudo echo 123 > /dev/ttyS1

... produces "123" on the serial line.

guix (GNU Guix) 0.14.0.2487-58246

config attached (my G54)

TIA - George

sys.scm
Description: Binary data

bug#30537: glibc 2.26 refuses to run on CentOS 6.8

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

> I have a bad day.  After the upgrade to glibc 2.26 none of the
> Guix-installed software runs on the HPC cluster running CentOS 6.8.

Bah.  :-(

> The glibc 2.26 expects a minimum kernel version of 3.x on x86_64, but
> CentOS 6.8 only comes with a heavily patched 2.6.32.

It’s annoying, but we can surely apply the patch you sent (though rather
by passing ‘--enable-kernel’ if possible, as Danny suggested.)


personality(2) has a knob to change the kernel version reported by
uname(2) to 2.6.  Here it’s a case where we’d need the reverse:
reporting 3.2 instead of 2.6.  That doesn’t seem to exist.

Looking for other hacks (or kludges), I found the kernel module below at
,
which could be adjusted to report a different kernel version:

--8<---cut here---start->8---
#include 
#include 
#include 

#ifndef UNAME_DUMB_STEPPING
#define UNAME_DUMB_STEPPING '5';
#endif

MODULE_AUTHOR("The one who invented the uname hack");
MODULE_DESCRIPTION("Changes the uname output");
MODULE_LICENSE("GPL");

static int uname_hack_init() {
save = system_utsname.machine[1];
system_utsname.machine[1] = UNAME_DUMB_STEPPING;
return 0;
}

static void uname_hack_cleanup() {
system_utsname.machine[1] = save;
}

module_init(uname_hack_init);
module_exit(uname_hack_cleanup);
--8<---cut here---end--->8---

Another option would be to ptrace processes, handle the first ‘uname’
call, and then PTRACE_DETACH.  Ugly.

Ludo’.

bug#30537: Grafts vs. early bootstrapping packages

[Ludovic Courtès]

Hello,

Mark H Weaver  skribis:

>> Ricardo Wurmus  writes:

[...]

>>  (define glibc-final
>>;; The final glibc, which embeds the statically-linked Bash built above.
>> -  (package (inherit glibc-final-with-bootstrap-bash)
>> +  (package/inherit glibc-final-with-bootstrap-bash
>>  (name "glibc")
>>  (inputs `(("static-bash" ,static-bash-for-glibc)
>>,@(alist-delete
>
> We seem to be oscillating on the question of whether to graft these
> early GLIBCs.  In June 2017, I switched to using 'package/inherit' here
> in commit 13f7f2fd2b208c29361ef2290f55911879a6adf2, and in October those
> changes were reverted in commit 848f550f2c105326dc3be4033c8aaf35ec21cde4
> by Efraim, although I'm not sure why.

I doesn’t make sense to graft “glibc-intermediate” because it’s only
used in ‘static-bash-for-glibc’, which statically links against it.  The
situation is similar with the “-boot0” packages: they are not referenced
by the packages we use.

So I think 848f550f2c105326dc3be4033c8aaf35ec21cde4 was a good idea.
f00b85ff8d34df0a1879e593d4a85629b8586af7 does something similar.

Ludo’.

bug#30505: Starting console/terminal Unicode support

[Ludovic Courtès]

Hello!

Danny Milosavljevic  skribis:

> On Wed, 21 Feb 2018 23:21:34 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>
>> >> This ‘unicode-start’ procedure is essentially a port of the
>> >> ‘unicode_start’ script from ‘kbd’.  I suppose the justification is to
>> >> make sure we’re using UTF-8 input regardless of what the kernel defaults
>> >> or command-line options are.  
>
> Yeah, but the only way to have it not use utf-8 would be to explicitly pass
> "default_utf8=0" as a command-line parameter.  I think at that point the
> user deserves what he personally asked for :P

(He or she.)  But yeah, that makes sense.

>>In
>> other cases (custom kernel build with different defaults, different
>> kernel command-line settings, etc.), we’d just get it wrong with things
>> breaking down the path, no?
>
> Yes, it would just default to ASCII.  In the big scheme of things it's not so 
> bad.
>
> I just thought that if it causes trouble *and* it's not needed anymore, the
> simplest way is to just remove it.

Yeah.

>> Also, FWIW, systemd’s vconsole-setup.c does exactly that:
>> 
>>   
>> https://github.com/systemd/systemd/blob/master/src/vconsole/vconsole-setup.c#L94
>
> Huh, I wonder why they do it.  systemd is quite new.  I understand that older 
> stuff
> (like kbd) did it because they had to in the Linux 2.4 days - but this?
>
> We should ask them...
>
> Aha, they also have
>
> static int toggle_utf8_sysfs(bool utf8) {
> int r;
>
> r = write_string_file("/sys/module/vt/parameters/default_utf8", 
> one_zero(utf8), 0);
> if (r < 0)
> return log_warning_errno(r, "Failed to %s sysfs UTF-8 flag: 
> %m", enable_disable(utf8));
>
> log_debug("Sysfs UTF-8 flag %sd", enable_disable(utf8));
> return 0;
> }
>
> so we could in fact directly force the VT driver to do our bidding, or even
> check what's up before trying to write the 'G' (the latter sounds like a hack
> hiding the actual problem, though).

Yeah, we could simply write “1” to that file I guess.

Let’s do that?

Thanks for explaining,
Ludo’.

bug#30467: GuixSD fails to display login prompt on headless server

[George myglc2 Clemmer]

On 02/22/2018 at 11:41 Danny Milosavljevic writes:

> Hi George,
>
> On Wed, 21 Feb 2018 20:35:34 -0500
> George myglc2 Clemmer  wrote:
>
>> I think we got side-tracked to the serial port when my real issue is
>> with the VGA port. Maybe my bug report was not clear. Let me clarify ...
>
> Oh, that changes things.  Ludo is debugging some silly UTF-8 problem
> with the virtual terminals on the VGA port right now - might be related,
> or not.  Who knows...

Well this problem goes back to November. The problem first appears in
my generation 19 ...

 19GNU with Linux-Libre 4.14.2 (beta)   61 2017-11-30 
19:18:15
 18GNU with Linux-Libre 4.13.12 (beta)  62 2017-11-11 
13:05:56

... which  correspond to ...

19 (GNU Guix) 0.13.0.5042-6e385
18 (GNU Guix) 0.13.0.4589-74bea6

Note: The results cited below are WRT my most recent build done
yesterday, guix (GNU Guix) 0.14.0.2455-26737.

>> GNU with Linuxlibre ..." for a couple seconds, and then 4) a blank.
>
> Is there still a cursor?

NO.

> What happens when you don't use the serial (so no console=...)

The VGA displays ...

- BIOS prompt
- grub menu
- 'Booting GNU linux-libre ...'
- ~1 seconds of messages
- Blank screen w/ no cursor

... which differers in that there are a couple seconds of boot messages.

> and then
> try to write something to /dev/console ?  It should show up somewhere.
> Where?  On the VGA port?

/home/g1# echo 123 > /dev/console

... shows nothing on the VGA or serial.

bug#30311: efi-less grub install fails

[Marius Bakke]

Ricardo Wurmus  writes:

> Marius Bakke  writes:
>
>> Ricardo: Can you post the output of `find /sys/firmware/efi -maxdepth 1`
>> on the affected machine?  With luck, we'll find a variable that is only
>> present on "real" EFI.
>>
>> Can you also post the contents of '/sys/firmware/efi/runtime'?
>
> Now that I have GuixSD installed on that machine I don’t have
> /sys/firmware/efi at all.  /sys/firmware contains “acpi”, “dmi”, and
> “memmap” only.
>
> The problem occurred when I tried to install GuixSD (after booting from
> a GuixSD installer USB drive), not when reconfiguring.  I don’t have a
> USB drive with me at the moment, so I cannot check the contents of
> /sys/firmware in the installer GuixSD now.

In this case I'm certain that the installer booted in EFI mode, crushing
my dreams of a proper fix.  So we'll need one of the proposed
workarounds to prevent this problem in the future.


signature.asc
Description: PGP signature