[SOLVED] Let me keep you busy while you wait the release of Slackware 14.2

kjhambrick · 05-30-2016, 05:47 AM

Didier --

I can't vote yet because I've only lookes at 'slint64-current-isolinux-vesamenu-background-image+elilo-mini.iso' <G>

I booted both BIOS and UEFI ( Win7 ) Modes.

I really like your BIOS background image ! Very nice !

The <F1> key works in both boot Modes.

I still see the problem pressing the '1' Key at the post-boot select keyboard prompt but here's an additional tidbit.

If I wait 'long enough' to enter the '1' at the select keyboard prompt, the text is immediately echoed to the console as expected ( I waited 10 sec ).

OTOH, if I try to immediately type at the prompt, there is a lag and I had to press the 1 Key exactly six times before I saw an echo.

Anyhow. Screenshot of `dmesg |grep -i keyboard` is attached.

-- kjh

Here's the keyboard stuff on the same ZBox running CentOS 6.8 from /dev/sda:

Code:

# dmesg |grep -i keyboard

Command line: ro root=UUID=7c942daa-9d16-4458-90bc-328a162d113d rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet libata.force=3.0Gbps
Kernel command line: ro root=UUID=7c942daa-9d16-4458-90bc-328a162d113d rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=129M@0M  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet libata.force=3.0Gbps
usb 3-10: Product: USB Keyboard
input: CZW USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.0/input/input11
generic-usb 0003:0E8F:0021.0002: input,hidraw1: USB HID v1.10 Keyboard [CZW USB Keyboard] on usb-0000:00:14.0-10/input0
input: CZW USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-10/3-10:1.1/input/input12
generic-usb 0003:0E8F:0021.0003: input,hidraw2: USB HID v1.10 Device [CZW USB Keyboard] on usb-0000:00:14.0-10/input1

laprjns · 05-30-2016, 05:58 AM

I tied all three of your mini iso, and they all booted without problems, both Legacy BIOS and UEFI, here on my Asus laptop (which normally has problem booting UEFI with grub)
One of them, I believe it was the iso with the background picture only has on boot option in UEFI mode. As far as my preference, although I like the look of the background wallpaper,I believe that for an install iso it should be a branded background, as a picture is too personal and may not be appealing to all.
I ended up "voting" for the slint64-current-isolinux-menu+elilo-mini.iso because it has a clean and simple look. I found the vesamenu to bea bit "blocky" and didn't care for the 3D look of the font. I would have voted for the background iso, it the background was more generic.

kjhambrick · 05-30-2016, 06:06 AM

Didier --

Attached is the full output of dmesg from the slint64-current-isolinux-vesamenu-background-image+elilo-mini.iso

-- kjh

Didier Spaier · 05-30-2016, 09:21 AM

Thanks kjhambrick for these useful info. I am still puzzled as I don't seem to observe this lag here. Maybe you could check if you see it also using a recent Slackware-current ISO? That would tell us if this is specific to Slint.

Meanwhile, later today I will compare the boot messages using a genuine Slackware installer (just removing the kernel parameter "printk.time=0" that suppress the time stamps in the kernel logs) and using a Slint installer to see what I come up with.

Just a thought: maybe the fact that you use an USB keyboard can come into play?

kjhambrick · 05-30-2016, 12:14 PM

Quote:

Originally Posted by Didier Spaier

Thanks kjhambrick for these useful info. I am still puzzled as I don't seem to observe this lag here. Maybe you could check if you see it also using a recent Slackware-current ISO? That would tell us if this is specific to Slint.

Meanwhile, later today I will compare the boot messages using a genuine Slackware installer (just removing the kernel parameter "printk.time=0" that suppress the time stamps in the kernel logs) and using a Slint installer to see what I come up with.

Just a thought: maybe the fact that you use an USB keyboard can come into play?

Didier --

I do believe it is related to the USB keyboard but not why.

I just made an ISO and burned Last Friday's Current to the same thumb drive.

No lag entering '1' at the select keyboard prompt.

The slackware dmesg output is attached. It does include the printk.time=0 kernel parm so the Slackware Current dmesg file does not include time stamps.

more stuff

Maybe the reason is in the slackware vs slint boot parameters:

# sed --posix -e 's/^.\{15\}//' /tmp/slint.dmesg.txt |diff -Naur /tmp/slack.dmesg.txt -

Code:

--- /tmp/slack.dmesg.txt        2016-05-29 06:59:06.000000000 -0500
+++ -   2016-05-30 12:32:06.834506781 -0500
@@ -2,7 +2,7 @@
 Initializing cgroup subsys cpu
 Initializing cgroup subsys cpuacct
 Linux version 4.4.11 (root@hive64) (gcc version 5.3.0 (GCC) ) #2 SMP Thu May 19 02:05:49 CDT 2016
-Command line: initrd=initrd.img load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0 nomodeset SLACK_KERNEL=huge.s BOOT_IMAGE=/kernels/huge.s/bzImage 
+Command line: LANG=en_US.utf8 initrd=initrd BOOT_IMAGE=linux 
 x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
 x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
 x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'

still more stuff

I appended load_ramdisk=1 and prompt_ramdisk=0 and there is no lag now ...

The following dmesg output includes printk.time=0 but it worked fine without it too.

I also tried with nomodeset all by itself ( no change -- still a lag ) and along with the ramdisk parms ( no lag but there was also no lag without it )

Code:

# sed --posix -e 's/^.\{15\}//' slint.dmesg.txt |diff -Naur - slint.dmesg.txt2
    
--- -   2016-05-30 13:11:44.614266322 -0500
+++ slint.dmesg.txt2    2016-05-29 08:06:54.311891829 -0500
@@ -2,7 +2,7 @@
 Initializing cgroup subsys cpu
 Initializing cgroup subsys cpuacct
 Linux version 4.4.11 (root@hive64) (gcc version 5.3.0 (GCC) ) #2 SMP Thu May 19 02:05:49 CDT 2016
-Command line: LANG=en_US.utf8 initrd=initrd BOOT_IMAGE=linux 
+Command line: LANG=en_US.utf8 initrd=initrd load_ramdisk=1 prompt_ramdisk=0 printk.time=0 BOOT_IMAGE=linux 
 x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
 x86/fpu: Supporting XSAVE feature 0x01: 'x87 floating point registers'
 x86/fpu: Supporting XSAVE feature 0x02: 'SSE registers'

<<snip>>

HTH

-- kjh

Didier Spaier · 05-30-2016, 01:17 PM

About kernel parameters:

prompt_ramdisk=0 in Slackware command line is superfluous as it is the default as stated in /usr/src/linux/Documentation/blockdev/ramdisk. For the records, this just says that as the kernel and the iniramfs are on the same floppy disk (!) there is no need to give the user some time to switch floppy disks before trying to load the ramdisk.
load_ramdisk=1 just says that a ramdisk should be loaded. I believe that this was only needed when using floppy disks as well.
So these kernel parameters are useless now if I understand well, that's why I removed them.
Anyway when you are asked to type "1", the initrd (more exactly the initramfs) has been loaded in RAM long ago, so these parameters can't matter.
Maybe omitting "rw" can hurt? Honestly I don't see why, though. Any clue appreciated there.

Other than that, initrd is simply the name I give to what Slackware calls initrd.img (but they differ of course, see below) and I just call the kernel linux (and it is in /isolinux as I don't ship the /kernels directory in the ISO)

So I think that the difference in behavior is more probably due to something that differs between the genuine Slackware initrd in the one shipped in Slint.

I will investigate tonight, thanks again for reporting.

EDIT: After having read your addendum "still more stuff" I am puzzled as I really do not know how these parameters come into play... Anyway I will compare kernel logs adding them or not to make sure.

Didier Spaier · 05-30-2016, 02:43 PM

Comparing slack.dmesg and sint.dmesg I see that in Slint case the module xhci_hcd is loaded before ehci-pci, but after in Slackware case.

I am also wondering if that cause this lag in Slint case.

I am wondering why. I will compare initrds, although I do not think that the kernel or modules differ.

Just to be 100% sure: were all removable devices, including the USB keyboard, plugged in the same slots in all cases?

kjhambrick · 05-30-2016, 03:35 PM

Quote:

Originally Posted by Didier Spaier

Comparing slack.dmesg and sint.dmesg I see that in Slint case the module xhci_hcd is loaded before ehci-pci, but after in Slackware case.

I am also wondering if that cause this lag in Slint case.

I am wondering why. I will compare initrds, although I do not think that the kernel or modules differ.

Just to be 100% sure: were all removable devices, including the USB keyboard, plugged in the same slots in all cases?

Didier --

Yes they were. Thumb Drive, Keyboard and mouse were in the same slots each time.

-- kjh

kjhambrick · 05-30-2016, 04:32 PM

Didier --

I thought I attached the dmesg output for the session where I appended extra boot parameters.

I don't see it ... here it is.

This was for 'load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0'

-- kjh

kjhambrick · 05-30-2016, 04:35 PM

Dooh !

I see why ... `mv /tmp/slint.dmesg.txt2 /tmp/slint.dmesg-2.txt`

sorry.

Didier Spaier · 05-30-2016, 05:14 PM

Well, I see that the end of all logs is similar.

I also see that the keyboard is registered near the end "input: CZW USB Keyboard..." followed by "hid-generic..."
(why these two lines are repeated in all cases is a mystery for me).

I assume that your keyboard in some (but not all) cases is just not yet registered at time of typing "1".

I am not sure that the kernel parameters have an influence, it could be just a coincidence.

I am in doubt about that for two reasons:

I fail to see a logical link between their setting and the lag.
I checked that booting the same ISO image twice (a fresh Slackware-current on an USB stick in that case) leads to register the same devices in a different order, as shows the attached unified diff of the respective logs.

So maybe that's just entropy's fault, after all...

Didier Spaier · 05-31-2016, 05:17 PM

@kjhambrick: In the installer, /etc/rc.d/rc.S is the first script to run

I see that in Slint the dialog whose title is "<OPTION TO LOAD SUPPORT FOR ANOTHER KEYBOARD>" runs slightly sooner in that script that in Slackware.

I will check if the time needed to get there differ significantly in Slint vs Slackware and if that is the case will insert a "sleep <time>" before.

kjhambrick · 05-31-2016, 05:20 PM

Thanks Didier.

Let me know when you've got another ISO file ready and I'll try it out

-- kjh

Didier Spaier · 06-02-2016, 12:03 PM

Quote:

Originally Posted by kjhambrick

Let me know when you've got another ISO file ready and I'll try it out

Thanks.

You will find it here: http://slint.fr/testing/

It is named slint64-current-sleep-mini.iso

My tests show that it takes around one second less for Slint than for Slackware to get to the point where you see the dialog titled "<OPTION TO LOAD SUPPORT FOR NON-US KEYBOARD>".

The new ISO allows you to set an additional delay before displaying this dialog.

To do that in Legacy mode, just boot the installer, choose your language and hit [TAB], then append to the command line:
sleep=n
where n is the number of seconds added before displaying the dialog (hence the name of the ISO).

In UEFI mode, just type sleep=n (this will be written in the green field) instead.

Please try with say, 1, 2, 3, 4 and 5 seconds and report from which delay your keyboard works regularly (i.e., three times in a row) as soon as you see the dialog, and do not make other changes to the command line.

Thanks in advance.

PS You can see at which point in the boot sequence the dialog is displayed. For that press Alt+F4 after it appears (you won't see it in dmesg).

kjhambrick · 06-02-2016, 12:11 PM

Didier --

I am in the middle of a Data Conversion this minute and for the remainder of the day.

I'll download ASAP and test it this evening / early tomorrow morning.

Thanks !

-- kjh

edit: got a good one ... will let you know as soon as I can shut down the problem-box and boot the .iso

Code:

# md5sum -c slint64-current-sleep-mini.iso.md5
  slint64-current-sleep-mini.iso: OK