Yesterday I upgraded 4.10.6 to 4.10.7 taken from experimental
Linux hermes 4.10.0-trunk-686-pae #1 SMP Debian 4.10.7-1~exp1
(2017-03-30) i686 GNU/Linux
and had a bit of hope to see this issue fixed because of
commit f9955dcaceae3a6d5c747b065e1d9da1be50b5ba
Author:
Anything else I can do to get this issue looked into ?
Thanks,
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
On Sun, Mar 26, 2017 at 08:18:16PM +0200, Karsten Hilbert wrote:
> One thing I *haven't* tested yet is whether earlier kernel
> would make a difference -- not that I would think but who
> knows.
Just for kicks I booted all kernels installed on this machine
(all prior experimentation was done
On Sun, Mar 26, 2017 at 08:18:16PM +0200, Karsten Hilbert wrote:
>
> > Maybe this happened because cached_setup_font.sh was run while / was
> > still read-only?
>
> Possibly. Suspecting that is why I chose / in the hope it'll
> get mounted rw real early :-)
I think for early logs
On Sun, Mar 26, 2017 at 08:42:43PM +0300, Anton Zinoviev wrote:
>> I have done some more experimentation and it shows fairly
>> strange results.
>
> Thanks a lot! :)
That is what I can contribute.
> > Sometimes cached_setup_font.sh does not seem to get run AT
> > ALL -- the log file simply
On Fri, Mar 24, 2017 at 11:52:32AM +0100, Karsten Hilbert wrote:
> I have done some more experimentation and it shows fairly
> strange results.
Thanks a lot! :)
> Sometimes cached_setup_font.sh does not seem to get run AT
> ALL -- the log file simply does not exist after a clean boot.
Maybe
One more data point:
> I edited the file /etc/console-setup/cached_setup_font.sh
> to look like this:
...
> the idea being to prevent it from running in parallel.
...
> When the log file DOES exist it does indeed show
> cached_setup_font.sh to run in parallel "early" in the boot
> process and
I have done some more experimentation and it shows fairly
strange results.
I edited the file /etc/console-setup/cached_setup_font.sh
to look like this:
#!/bin/sh
# added
SEMAPHORE="/cached_setup_font.sh.running"
LOG="/console-cached_setup_font.sh-tracing.log"
On Thu, Mar 23, 2017 at 11:36:20AM +0100, Karsten Hilbert wrote:
>
> Directly after boot, during which no VT switch occurred, I
> will see the login manager for KDE. When I now switch to the
> first console and then ALT-RIGHT through my other consoles up
> until vt6 they don't have a getty
On 2017-03-23 14:12 -0300, Felipe Sateler wrote:
> However, I see the following in cached_setup_font:
>
> setfont '/etc/console-setup/cached_Lat15-Fixed16.psf.gz'
>
> if ls /dev/fb* >/dev/null 2>/dev/null; then
> for i in /dev/vcs[0-9]*; do
> { :
> setfont
On Thu, Mar 23, 2017 at 02:12:44PM -0300, Felipe Sateler wrote:
>
> As mentioned by Michael, this is not done by udev or systemd.
I think systemd runs getty which opens a console. Then the kernel
creates virtual consoles on demand.
> > From my tests it seems that the font used
> > for this
On Thu, Mar 23, 2017 at 10:58 AM, Anton Zinoviev wrote:
> On Thu, Mar 23, 2017 at 02:37:48PM +0100, Michael Biebl wrote:
>>
>> In Debian, we don't enable the systemd-vconsole component [1].
>
> This is good, but...
>
>> So there should be no console configuration happening from
On Thu, Mar 23, 2017 at 03:30:36PM +0100, Michael Biebl wrote:
> >
> > ...suppose udev creates a new console. Then it has to be initialized
> > with some font, hasn't it?
>
> udev does not create any consoles. That's a misconception.
Well, whoever does it... :)
Anton Zinoviev
Am 23.03.2017 um 14:58 schrieb Anton Zinoviev:
> On Thu, Mar 23, 2017 at 02:37:48PM +0100, Michael Biebl wrote:
>>
>> In Debian, we don't enable the systemd-vconsole component [1].
>
> This is good, but...
>
>> So there should be no console configuration happening from systemd's
>> side.
>
>
On Thu, Mar 23, 2017 at 02:37:48PM +0100, Michael Biebl wrote:
>
> In Debian, we don't enable the systemd-vconsole component [1].
This is good, but...
> So there should be no console configuration happening from systemd's
> side.
...suppose udev creates a new console. Then it has to be
Am 23.03.2017 um 14:04 schrieb Anton Zinoviev:
> My tests of how systemd works show that it does the following:
>
> 1. It reads the curent font of the current console.
>
> 2. Then it does some things to the console(s) (configuration).
>
> 3. When a new console is created it loads on it the
On Thu, Mar 23, 2017 at 03:04:37PM +0200, Anton Zinoviev wrote:
> Since systemd makes some configuration of the console, maybe the
> following scenario might explain what we observe:
... lengthy analysis ...
> So, if this scenario is possible, a natural question is what can be done
> in order
[I am sending a CC to pkg-systemd-maintain...@lists.alioth.debian.org]
On Thu, Mar 23, 2017 at 11:07:14AM +0100, Sven Joachim wrote:
>
> There might be a third possibility which seems to happen on one of my
> systems: the cached_setup_font.sh script does not work correctly when
> run during boot
On Thu, Mar 23, 2017 at 11:07:14AM +0100, Sven Joachim wrote:
> >> > ls -l /etc/console-setup/
> >>
> >>-rwxr-xr-x 1 root root 465 Mar 22 11:20 cached_setup_font.sh
> >>-rwxr-xr-x 1 root root 358 Mar 22 11:20 cached_setup_keyboard.sh
> >>-rwxr-xr-x 1 root root73 Mar 22
On 2017-03-22 15:02 +0200, Anton Zinoviev wrote:
> On Wed, Mar 22, 2017 at 01:00:17PM +0100, Karsten Hilbert wrote:
>>
>> > ls -l /etc/console-setup/
>>
>> -rwxr-xr-x 1 root root 465 Mar 22 11:20 cached_setup_font.sh
>> -rwxr-xr-x 1 root root 358 Mar 22 11:20
On Wed, Mar 22, 2017 at 08:48:16PM +0200, Anton Zinoviev wrote:
> > 2017-03-22 13:05:13.364493514 +0100 /etc/console-setup/cached_setup_font.sh
> > 2017-03-22 13:05:13.364493514 +0100
> > /etc/console-setup/cached_setup_keyboard.sh
> > 2017-03-22 13:05:13.364493514 +0100
> >
On Wed, Mar 22, 2017 at 05:56:04PM +0100, Karsten Hilbert wrote:
> 2017-03-22 13:05:13.364493514 +0100 /etc/console-setup/cached_setup_font.sh
> 2017-03-22 13:05:13.364493514 +0100
> /etc/console-setup/cached_setup_keyboard.sh
> 2017-03-22 13:05:13.364493514 +0100
>
On Wed, Mar 22, 2017 at 04:49:27PM +0200, Anton Zinoviev wrote:
> Thanks. :) Well, can you report the state of the affairs before you run
>
> systemctl restart console-setup.service
>
> ls --full-time /etc/default/{console-setup,keyboard}
> /etc/console-setup/cached_*
Attached.
Full
On Wed, Mar 22, 2017 at 03:19:57PM +0100, Karsten Hilbert wrote:
> On Wed, Mar 22, 2017 at 03:02:28PM +0200, Anton Zinoviev wrote:
> >
> > 2. the bug still exists and each time the system boots, it recreates
> > these three files. In this case we have to find out the cause of this.
>
> The
On Wed, Mar 22, 2017 at 03:02:28PM +0200, Anton Zinoviev wrote:
> > > ls -l /etc/console-setup/
> >
> > -rwxr-xr-x 1 root root 465 Mar 22 11:20 cached_setup_font.sh
> > -rwxr-xr-x 1 root root 358 Mar 22 11:20 cached_setup_keyboard.sh
> > -rwxr-xr-x 1 root root73 Mar 22
On Wed, Mar 22, 2017 at 01:00:17PM +0100, Karsten Hilbert wrote:
>
> > ls -l /etc/console-setup/
>
> -rwxr-xr-x 1 root root 465 Mar 22 11:20 cached_setup_font.sh
> -rwxr-xr-x 1 root root 358 Mar 22 11:20 cached_setup_keyboard.sh
> -rwxr-xr-x 1 root root73 Mar 22
On Wed, Mar 22, 2017 at 02:18:51PM +0300, Anton Zinoviev wrote:
> > is there anything I can do/provide to help get this resolved ?
>
> Yes, thanks! The output of the following commands:
Here you go:
> ls -l /etc/console-setup/
total 164
drwxr-xr-x 2 root root 4096 Mar 7
On Wed, Mar 22, 2017 at 11:29:48AM +0100, Karsten Hilbert wrote:
>
> is there anything I can do/provide to help get this resolved ?
Yes, thanks! The output of the following commands:
ls -l /etc/console-setup/
cat /etc/console-setup/cached_setup_font.sh
cat
Package: console-setup
Version: 1.163
Followup-For: Bug #857132
Hi,
is there anything I can do/provide to help get this resolved ?
Thanks,
Karsten
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'),
(500,
29 matches
Mail list logo