Dear Samuel;
Sorry for messing the posting of the message up; I think my mail client
is misconfigured and only picked up your address and not the mailing
list one. To keep my post and your reply in the list I'm
forwarding/including them here. Apologies to all if I am not following
the correct placement for quotes/replies.
In response to the replay under the message above, below:
<Ctrl>+A eventually toggles only between screen 1 (installer) and screen
4 (log); I think the absence of a '-' between the number and the word
"shell" in the other two indicates that they are not active. In use the
'(' and ')' are in red and they and the '*' move between the two screens
1 and 4 to show the currently active view.
However it seems like pretty much all key strokes seem to be piling up
somehow in parts of the installation process. To simplify things I went
back and via a bootable thumb-drive with a copy of Knoppix on it I
completely cleared the partitioning of the HDD I am using so that I can
accept with an <Enter> the default choice in each place that I have to
make a choice.
I have gone through this process several times now, but it messes up
consistently at the point where the choice of where to put GRUB needs to
be made - unfortunately I can never manoeuvre through getting it
installed into "/dev/hd0" - the stacked keypresses mean that I get
shunted to the place where I have to specify it manually but by that
time whatever I might want to put in there is not at the front of the
keyboard buffer and the first keystroke ends up being interpreted as a
<Enter> - which is immediately accepted - but there is no place
specified so GRUB does not get installed AFAICT and the HDD is
unbootable. I have managed to use the GRUB installed on the DVD to try
and invoke the installation following the sort of thing in:
https://www.gnu.org/software/grub/manual/grub/html_node/GNU_002fHurd.html
I thought I had everything entered but after "boot" execution reaches
the point where the two modules mentioned in that URL ("/hurd
/ext2fs.static ext2fs" and "/lib/ld.so.1 exec" - I am not yet familiar
with the GNU/Hurd to fully identify which bit does what) seem to be
started - but then, nothing happens...
If I could just expand on how the keyboard is behaving for me, it is as
if the key presses are being stored in an expanding buffer, with each
key press being input is appended (written) to the end of this (maybe
not hypothetical) buffer but the process of reading them is not keeping
up with it, the reading pointer is generally being advanced at the same
time as the writer pointer (so it interprets the keypress at the same
time as I input another one) but it also keeps being rewound so that the
key it sees and acts on is one that has already been used and not the
one I just pressed.
As it is, it is getting increasingly frustrating having gone through
nearly the entire installation process only for it to fail to complete
successfully.
Stephen
-------- Forwarded Message --------
Subject: Re: Bug#959221: [hurd] install UI slow to point of unusable,
even text UI for me too
To: Samuel Thibault <sthibault@debian.org>
Message-ID: <7674b041-39b0-0631-5755-3943b37db0f1@virginmedia.com>
Date: Mon, 8 Feb 2021 18:26:34 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <[🔎] 20210206093835.tnwjoqcmtttajboy@begin>
Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
boundary="D5d1ZzxJFmlLqxLdqtg4mU6ovLrbI45Cx"
Dear Samuel;
To be honest I am not able to access the other consoles ctrl-alt-f2 to
ctrl-alt-f4 just do not do anything - I can see at the top of the screen:
[ (1*installer) 2 shell 3 shell 4-log ][DATE TIME]
which suggests that there should be terminals (of some sort) on two and
three and a log display on four - however they are inaccessible.
As far as I can determine the keyboard (USB only on the hardware I have
to hand) is not being handled correctly. It seems that keypresses are
not being cleared/consumed from an "input" buffer instead in some (or
all, I can't reliably determine) keypresses that should have been "used"
to cause something to happen are staying in the input queue and end up
taking effect when the next key is pressed - which gets nasty very
quickly. For instance I realised that I might be able to toggle the
numlock key to register a keypress with no effect - they piled up in the
buffer and at one point I was pressing the <enter> key but instead of
that initiating anything the num-lock LED switched on or off for each
press of the <enter> key.
In my most recent attempt I just pressed <enter> to accept the default
value in each case - I did manage to enter a user name {so entering
something in a multi-character string entry field worked to a limited
extent} but as soon as I reached a point where arrow keys were needed to
select from a list of options it became difficult/impossible to navigate
- and that was at the point where I was trying to select the PATA HDD I
was using to install to instead of the DVD-RW (a 1.7GB partition & a 3.0
GB spare on) that the installer works from but thinks it can use!
Right now it is installing the base system - I'll see how much further
it gets but I will likely repeat the process after removing the remnant
(a 32GB FAT partition) of a previous use of the drive.
It would be useful if someone who knows the guts could review the
low-level keyboard handling in the installer to see what bugs might be
there. It would be useful if there is a way that the number of
keystrokes "pending" in the keyboard queue could be displayed
temporarily in the installer (ideally with what they are) and/or if
there was a way that it could be forcibly cleared - perhaps an unused
key could be reserved so that so when it is seen, instead of queueing it
up, it immediately flushes itself and all others from the queue. The
most obvious one would be the "Windows" or equivalent key if that can be
handled.
Sorry that I can not be more specific about the details about what is
going on - however I am not giving up just yet! 8-P
Regards
Stephen
On 2021-02-06 09:38, Samuel Thibault wrote:
> Hello,
>
> Stephen Lyons, le sam. 06 févr. 2021 02:30:43 +0000, a ecrit:
>> However, now I have found #959221
>
> I have to admit I had never noticed that bug report, I don't know why.
>
>> I have to say that trying to install
>> onto a real machine with this later and different image does not seem
>> any better. Some parts of the UI work acceptably fast but others, like
>> around disk partitioning are dangerously unresponsive,
>
> That's odd, I had never seen such behavior, be it in virtual environment
> or bare metal. Since you mention disk partitioning, I would guess a bad
> interaction between the ahci disk driver and the disk device. Nothing I
> can work on personally since on my systems I don't have the issue. Are
> there timeout logs being printed?
>
> If you got to the second console with ctrl-alt-f2, and run there
>
> ps | grep R
>
> which processus show up?
>
> Samuel
>
--
To mitigate against EFAIL attacks email messages will be handled only as
plain text, please do not send emails in an HTML form to this recipient!
Attachment:
signature.asc
Description: OpenPGP digital signature