Booted off of the NETINST iso[1[ via a usb thumb drive[2] attempted to navigate the UI ...got as far as choosing language/region before giving up as it was wayy too slow. all 4 interfaces (graphics, partial graphics, text, expert install) were more or less the same - but certainly the text/menu interfaces were...painfully slow. Many seconds between a keypress and the highlighted field moving, long enough that it's hard to be sure whether your keypress was successful which makes the interface unusable. [1] debian-hurd-2019-i386-NETINST-1.iso from https://cdimage.debian.org/cdimage/ports/current-hurd-i386/iso-cd/debian-hurd-2019-i386-NETINST-1.iso CPU processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping : 3 cpu MHz : 2992.71 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm pni dtes64 monitor ds_cpl est cid cx16 xtpr clflush size : 64 wicksell# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping : 3 cpu MHz : 2992.71 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm pni dtes64 monitor ds_cpl est cid cx16 xtpr clflush size : 64 processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz stepping : 3 cpu MHz : 2992.81 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm pni dtes64 monitor ds_cpl est cid cx16 xtpr clflush size : 64 memory: 1 GiB (didn't get to the point where I could mount swap) USB [2] Bus 001 Device 018: ID 154b:005b PNY Flash Drive other hardware : dmidecode output attached
this is for a "real" machine, not a virtualized environment
--- Please enter the report below this line. --- Having been aware of the GNU/HURD for some years and seeing that Debian offered it (and being subject to the general slow down in life in the era of COVID-19) I though it was worth having a go and trying to install it on a spare system. However, now I have found #959221 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, fortunately I was working on a spare machine with only a single, empty SATA hard-drive otherwise it would have been easy for unhandled but stacked up key presses to damage existing OSes installed elsewhere in the system. In effect you press a key, and... ... nothing happens, so you think "oh that wasn't valid there" and press another key, and again... ... nothing happens ... after a while ... nothing happens ... then suddenly! Nothing continues to happen ... finally, the first key that you pressed takes effect, then the next, then the next - but by then the "cursor" is in the wrong place and the wrong thing happens! Now I am aware of this Bug I will try again when I can get to the machine (it is elsewhere) and this time be very sure and deliberate about which keys I press and where - and try and note down which bits are okay and which are like wading through concrete. Stephen--- System information. --- Auto-generated details suppressed because this is not from the system concerned and I did not get far enough in to get much to report back. "Dell" something or other Desktop PC with 2.8GHz Pentium D 1GB Memory 2x SATA: 500GB HDD 2x PATA: DVD-ROM drive connected--- Package information. ----- Not applicable.
Hello, Stephen Lyons, le sam. 06 févr. 2021 02:30:43 +0000, a ecrit: I have to admit I had never noticed that bug report, I don't know why. 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
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
Stephen Lyons, le mar. 09 févr. 2021 05:12:01 +0000, a ecrit: It's not control+A alone, but control+A then space. As I answered privately, possibly the BIOS emulates your USB keyboard into the PC keyboard in a surprising way. Not something that somebody without the hardware can easily debug, unfortunately. Samuel
I guess that was the case - I resorted to jurying rigging the disk and DVD-ROM in my main system which had all the other drives disconnected and that one worked fine - though it did have a PS/2 keyboard. After returning them to the original system; booting from a Knoppix thumb-drive to correct the numbering in `/etc/fstab` and temporarily editing the GRUB entry to also compensate for the drive being differently numbered compared to when it was on the installation system I now have a bootable system - hooray! So I have worked around the problem - which seems to be confined to the installer and is a nuisance - but in the scheme of things I guess this issue for me can be relegated to a low priority. For the record the system concerned was a Dell Dimension 5150 with a BIOS version A05. Having read: https://en.wikipedia.org/wiki/USB_human_interface_device_class#Keyboards I think I start to understand why things might go wrong.
Stephen Lyons, le mar. 09 févr. 2021 23:32:00 +0000, a ecrit: So you mean that the installed system does not have the keyboard issue? That is very surprising since that is supposed to be about the same kernel. Which ISO image had you used exactly? Samuel
If I refer you back to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959221#15 it was the Debian Sid DVD image: https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/current/debian-sid-hurd-i386-DVD-1.iso which report that it is: "DVD Binary-1 20200731-17:45".
Stephen Lyons, le mar. 09 févr. 2021 23:52:43 +0000, a ecrit: Ok, sorry for the duplicate question. Could you try a more recent image such as https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/debian-sid-hurd-i386-NETINST-1.iso ? Samuel