Let's test Slackware-current.

Didier Spaier · 09-02-2014, 12:42 PM

Maybe it's not too early to help debug -current in gathering here bugs/oddities/inconsistencies/issues that we know of. This could help insure that the next Slackware release will be the best ever, again

I suggest that we state only things that don't work as expected, leaving added features for other threads, and that we give as many practical details as possible, including ways to reproduce, effects, causes, and suggested ways to fix, attaching or linking to patches if possible.

Let's prime the pump with two issues (all patches applied on Slackware{,64}-current as of Thu Aug 28 23:17:47 UTC 2014).

1. The script /var/log/setup/setup.80.make-bootdisk works as expected in installed system but not when called from the installer.

This is because the called syslinux binary rely on mtools that fails by lack of IBM850.so in the installer. As stated in "info mtools"

Code:

`codepage'
     Describes the DOS code page used for short filenames. This is a
     number between 1 and 999. By default, code page 850 is used. [...]

Possible fixes: ship /usr/lib{,64}/gconv/IBM850.so in the initrd, or replace syslinux by syslinux-nomtools line # 208 of setup.80.make-bootdisk. I have tested the latter.

2. In Slackware64-current, an USB stick processed with /usb_and_pxe_installers/usbimg2disk.sh doesn't boot in case of EFI firmware

Once mounted, the partition created on the stick has following layout:

Code:

.
`-- syslinux
    |-- EFI
    |   `-- BOOT
    |       |-- BOOTX64.EFI
    |       |-- elilo.conf
    |       `-- message.txt
    |-- f2.txt
    |-- huge.s
    |-- initrd.im
    |-- ldlinux.sys
    |-- memtest
    |-- message.txt
    |-- setpkg
    `-- syslinux.cfg

But under "3.4.1.1 Removable Media Boot Behavior" the UEFI specification version 2.4 (errata B) states:

Quote:

If FilePathList[0] points to a device that supports the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, then the system firmware will attempt to boot from a removable media FilePathList[0] by adding a default file name in the form \EFI\BOOT\BOOT{machine type short-name}.EFI

So maybe some firmwares *could* attempt to find the PE32+ image BOOTX64.EFI[1] in /syslinux/EFI/BOOT/ but all compliant firmwares *should* find it in /EFI/BOOT/.

=> We need to move the directory EFI/ up one level.

Also, paths to the kernel and initrd in /syslinux/EFI/BOOT/elilo.conf are:
image=/huge.s
initrd=/initrd.img
but these files lie in /syslinux not at the root of the partition.

=> In the paths, / should be replaced by /syslinux/

Attached patch against usbimg2disk.sh closes both issues (tested in a vmplayer VM with firmware="efi").

[1] in case of x64 architecture the machine type short name looked for is BOOTx64.EFI.

moisespedro · 09-02-2014, 07:52 PM

Althought I can provide something as complete as the OP's post I had another problem with the installer: it looks like it doesn't format existing partitions at all. I had some ext4 partitions from a previous install that I wanted to format and the installer says "Formatting" but it doesn't actually do anything. I even tried setting it to another file system (btrfs) but it still didn't do anything. I ended up having to using another tool to format it (gparted).

ReaperX7 · 09-02-2014, 09:09 PM

One issue I have seen firsthand is that if you attempt to install /(root) onto a BtrFS partition, the install will crash usually around trying to install /d. All other file systems install without issue. Only BtrFS crashes. I tried this with a -Current ISO using AlienBOB's script, and it failed using even the current kernels, tools, etc.

Didier Spaier · 09-02-2014, 11:04 PM

A small tip: it can help to gather error messages in a file, especially when they don't display on screen or too fast to be read. For instance if something doesn't seem to work during installation as expected, typing setup 2>/tmp/err.txt instead of just setup then having a look at that file before rebooting could give some clue -- in case this file be not empty, of course

ReaperX7 · 09-02-2014, 11:32 PM

I'll retry with that maybe in a VM, but I'm not in a position to sacrifice a system at the moment. Need to get another hard drive.

The only error I ever got back with 14.1 was something like this:

"Read/Write on Block Device /dev/sda4 failed. Failed to access filesystem. Unable to continue with operation. Exiting."

I tried BtrFS back on 14.0 and it worked okay. Wasn't bootable, and required a /boot partition but it worked okay.

slackass · 09-04-2014, 07:08 PM

A problem I've been having with 64-Current with the Nvidia blob on 3 boxes now is that if I try to shutdown from run level 4 from within kde by right clicking on the desktop is that it hangs with what appears to be a stuck x server.
It works perfect from Xfce.
If I right click and select log out and then select shutdown or reboot from the KDM screen it works perfect.
If I set inittab to “3” then everything works perfect.
I have reproduced this several times with new installs and the problem only pops up after the Nvidia blob install.
Currently using:
Slack64-Current with or without multilib.
NVIDIA-Linux-x86_64-340.32.run
Was unable to install older Nvidia driver to test if the problem was still there..

Didier Spaier · 09-05-2014, 01:58 AM

@slackass: do you see something in the logs that could give a clue on what goes wrong?

lems · 09-05-2014, 06:44 AM

I'm running Slackware -current on a Thinkpad T60 (32 bit machine). It uses the following graphics adapter according to lspci:

Code:

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)

I run KDE 4.14.0 (no KDE Frameworks/Plasma 5.0.1 installed), and noticed that when opening the logout/shutdown menu the screen starts to flicker. Though when opening/closing this a few times it seems to go away (right now I just disabled the specific effect via the KDE system settings and re-enabled it, and it went away). This is not really serious, but something I noticed when switching to -current.

edit: Just logged out: it seems the screen flickers only once. The next time the dialog is opened it behaves like it did in 14.1.

slackass · 09-05-2014, 07:38 AM

Quote:

Originally Posted by Didier Spaier

@slackass: do you see something in the logs that could give a clue on what goes wrong?

No, nothing.
It does shutdown if I log out first and shutdown from the KDM screen.

ricky_cardo · 09-05-2014, 08:03 PM

Maybe this will help, I've got the nvidia blob, and current and using i3 window manager. When I logout using [win-shift-e]
I get this:

Code:

Exiting due to signal.
xinit: connection to X server lost

waiting for X server to shut down (EE) Server terminated successfully (0).
Closing log file.
..........
xinit: X server slow to shut down, sending KILL signal

waiting for server to die

All is well but I've never seen this delay. (actually 5 or 6 seconds) for me it is cool, just thought I'd bring it up never experienced this before. Not too accustomed to NVIDIA, since I had been using ATI and slack14.0

here is the end of /var/log/Xorg.0.log

Code:

[266377.480] (II) evdev: HP WMI hotkeys: Close
[266377.480] (II) UnloadModule: "evdev"
[266377.480] (II) evdev: Speakup: Close
[266377.480] (II) UnloadModule: "evdev"
[266377.480] (II) UnloadModule: "synaptics"
[266377.480] (II) evdev: PS/2 Generic Mouse: Close
[266377.480] (II) UnloadModule: "evdev"
[266377.480] (II) evdev: AT Translated Set 2 keyboard: Close
[266377.480] (II) UnloadModule: "evdev"
[266377.480] (II) evdev: HP Webcam [2 MP Macro]: Close
[266377.481] (II) UnloadModule: "evdev"
[266377.481] (II) evdev: Sleep Button: Close
[266377.481] (II) UnloadModule: "evdev"
[266377.481] (II) evdev: Video Bus: Close
[266377.481] (II) UnloadModule: "evdev"
[266377.481] (II) evdev: Power Button: Close
[266377.481] (II) UnloadModule: "evdev"
[266378.369] (II) NVIDIA(GPU-0): Deleting GPU-0
[266378.380] (EE) Server terminated successfully (0). Closing log file.

If anyone can think of other logs to check ill post.

Didier Spaier · 09-08-2014, 08:59 AM

Quote:

Originally Posted by moisespedro

Althought I can provide something as complete as the OP's post I had another problem with the installer: it looks like it doesn't format existing partitions at all. I had some ext4 partitions from a previous install that I wanted to format and the installer says "Formatting" but it doesn't actually do anything. I even tried setting it to another file system (btrfs) but it still didn't do anything. I ended up having to using another tool to format it (gparted).

What "setup" actually does is installing a file system in a partition.

If you want to format an existing partition, you should run fdisk or cfdisk (assuming that you want to use MBR, not GPT, of course) to:

delete the existing partition,
then create a new one in the freed space of type Linux (83).

Then "format" it while running setup with your preferred file system.

Just changing the partition type won't work, at least in some cases. For instance here I had to delete an ext4 partition, then create a btrfs partition using the freed space and that worked. I didn't have to use gparted for that.

You can check the file system of a partition, including during installation, with

Code:

 lsblk -o NAME,KNAME,FSTYPE

Of course if you do that for / but didn't make a separate non-btrfs /boot partition lilo will still fail, but that's a limitation of lilo and/or btrfs, not of the installer.

While we are speaking of btrfs: I was able to make a full (only kdei put aside) installation of Slackware64-current as of Thu Aug 28 23:17:47 UTC 2014 using a btrfs partition as target without a hitch (apart from the lilo issue, of course), so I couldn't reproduce the issue stated in post #3.

ReaperX7 · 09-08-2014, 08:41 PM

I'll rsync a new copy and see if it works Didier. My last disk was a few months back so maybe it has been fixed(?) since then somehow (possibly via a kernel update?).

However, I'm still wary of BtrFS, and still won't recommend it openly.

linuxtinker · 09-09-2014, 12:07 AM

Just wanted to say Slackware64-Current is working great for me. Just did 2 installs of 14.1 x64 and changed the repo's over to current, installed-new, upgrade-all, and had no issues. My AMD-a6 6400k seems to be working well with the new kernel & Mesa as well.

Citramonum · 09-13-2014, 09:54 AM

Dear Sant^WPatrick, please upgrade tzdata as Russia shifts its time zones again at the end of October.

elyk · 09-18-2014, 12:27 AM

I've acquired an old machine for testing. It has SiS graphics:

Code:

01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter

If I startx, it will run momentarily and then segfault. I have found a couple of patches to fix the problem. I've tried both and they both work for me. This first one fixes the root of the problem:

https://bugs.freedesktop.org/show_bug.cgi?id=35763#c4

Comments #8 and #9 indicate that it's working for several people. However comments #5 and #6 indicate that someone has problems with it. That could be a different bug. Here is an alternate patch that just disables the broken functionality, in case the first patch causes problems for some:

https://projects.archlinux.org/svnto...xf86-video-sis

These could also be applied to Slackware 14.1. It behaves the same way.

EDIT: Those patches are for xf86-video-sis, if it's not obvious.