SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm new with Slackware, working through my 3rd attempt at a minimalist installation. Now that slackpkg is working, I need to find out why I have no input at the XDM login screen. Ctrl-Alt-F3 does nothing too. Only REISUB works. It makes no difference whether /etc/X11/xorg.conf-vesa is present. Switching drivers from amdgpu to radeon doesn't help. Xorg is working just fine automagically, with a little kernel cmdline help from radeon.cik_support=0 amdgpu.cik_support=1, on Debian, Fedora, Mageia, Mint, openSUSE & Ubuntu on same PC. It looks like required drivers are all installed:
Code:
# ls -Gg /usr/lib64/xorg/modules/input/
total 368
-rwxr-xr-x 1 948 Feb 13 2021 evdev_drv.la
-rwxr-xr-x 1 69480 Feb 13 2021 evdev_drv.so
-rwxr-xr-x 1 913 Feb 13 2021 kbd_drv.la
-rwxr-xr-x 1 31256 Feb 13 2021 kbd_drv.so
-rwxr-xr-x 1 955 Jan 25 00:57 libinput_drv.la
-rwxr-xr-x 1 81984 Jan 25 00:57 libinput_drv.so
-rwxr-xr-x 1 925 Feb 13 2021 mouse_drv.la
-rwxr-xr-x 1 54648 Feb 13 2021 mouse_drv.so
-rwxr-xr-x 1 944 Feb 13 2021 wacom_drv.la
-rwxr-xr-x 1 131808 Feb 13 2021 wacom_drv.so
Code:
# ls -Gg /usr/lib64/dri/
total 412859
-rwxr-xr-x 11 26060656 Jan 28 15:23 crocus_dri.so
-rwxr-xr-x 6 16335688 Jan 28 15:23 i830_dri.so
-rwxr-xr-x 6 16335688 Jan 28 15:23 i915_dri.so
-rwxr-xr-x 6 16335688 Jan 28 15:23 i965_dri.so
-rwxr-xr-x 11 26060656 Jan 28 15:23 iris_dri.so
-rwxr-xr-x 11 26060656 Jan 28 15:23 kms_swrast_dri.so
-rwxr-xr-x 11 26060656 Jan 28 15:23 nouveau_dri.so
-rwxr-xr-x 3 12693912 Jan 28 15:23 nouveau_drv_video.so
-rwxr-xr-x 6 16335688 Jan 28 15:23 nouveau_vieux_dri.so
-rwxr-xr-x 6 16335688 Jan 28 15:23 r200_dri.so
-rwxr-xr-x 11 26060656 Jan 28 15:23 r300_dri.so
-rwxr-xr-x 11 26060656 Jan 28 15:23 r600_dri.so
-rwxr-xr-x 3 12693912 Jan 28 15:23 r600_drv_video.so
-rwxr-xr-x 6 16335688 Jan 28 15:23 radeon_dri.so
-rwxr-xr-x 11 26060656 Jan 28 15:23 radeonsi_dri.so
-rwxr-xr-x 3 12693912 Jan 28 15:23 radeonsi_drv_video.so
-rwxr-xr-x 11 26060656 Jan 28 15:23 swrast_dri.so
-rwxr-xr-x 11 26060656 Jan 28 15:23 virtio_gpu_dri.so
-rwxr-xr-x 11 26060656 Jan 28 15:23 vmwgfx_dri.so
-rwxr-xr-x 11 26060656 Jan 28 15:23 zink_dri.so
Code:
# ls -Gg /usr/lib64/xorg/modules/
total 862
drwxr-xr-x 2 1024 Dec 26 17:51 drivers
drwxr-xr-x 2 1024 Dec 26 17:51 extensions
drwxr-xr-x 2 1024 Feb 13 2021 input
-rwxr-xr-x 1 925 Dec 26 17:51 libexa.la
-rwxr-xr-x 1 105192 Dec 26 17:51 libexa.so
-rwxr-xr-x 1 919 Dec 26 17:51 libfb.la
-rwxr-xr-x 1 113608 Dec 26 17:51 libfb.so
-rwxr-xr-x 1 938 Dec 26 17:51 libfbdevhw.la
-rwxr-xr-x 1 22808 Dec 26 17:51 libfbdevhw.so
-rwxr-xr-x 1 963 Dec 26 17:51 libglamoregl.la
-rwxr-xr-x 1 217168 Dec 26 17:51 libglamoregl.so
-rwxr-xr-x 1 937 Dec 26 17:51 libint10.la
-rwxr-xr-x 1 146112 Dec 26 17:51 libint10.so
-rwxr-xr-x 1 932 Dec 26 17:51 libshadow.la
-rwxr-xr-x 1 39064 Dec 26 17:51 libshadow.so
-rwxr-xr-x 1 955 Dec 26 17:51 libshadowfb.la
-rwxr-xr-x 1 14456 Dec 26 17:51 libshadowfb.so
-rwxr-xr-x 1 914 Dec 26 17:51 libvbe.la
-rwxr-xr-x 1 31112 Dec 26 17:51 libvbe.so
-rwxr-xr-x 1 937 Dec 26 17:51 libvgahw.la
-rwxr-xr-x 1 35960 Dec 26 17:51 libvgahw.so
-rwxr-xr-x 1 925 Dec 26 17:51 libwfb.la
-rwxr-xr-x 1 138184 Dec 26 17:51 libwfb.so
Code:
# ls -Gg /usr/lib64/xorg/modules/drivers/
total 846
-rwxr-xr-x 1 959 Jul 30 2021 amdgpu_drv.la
-rwxr-xr-x 1 156760 Jul 30 2021 amdgpu_drv.so
-rwxr-xr-x 1 935 Feb 13 2021 ati_drv.la
-rwxr-xr-x 1 14528 Feb 13 2021 ati_drv.so
-rwxr-xr-x 1 983 Dec 26 17:51 modesetting_drv.la
-rwxr-xr-x 1 115352 Dec 26 17:51 modesetting_drv.so
-rwxr-xr-x 1 967 Feb 13 2021 radeon_drv.la
-rwxr-xr-x 1 497944 Feb 13 2021 radeon_drv.so
-rwxr-xr-x 1 966 Feb 13 2021 vboxvideo_drv.la
-rwxr-xr-x 1 39864 Feb 13 2021 vboxvideo_drv.so
-rwxr-xr-x 1 921 Feb 13 2021 vesa_drv.la
-rwxr-xr-x 1 31808 Feb 13 2021 vesa_drv.so
Does anyone know or can anyone tell from Xorg.0.log why amdgpu, libinput & glamor generate load fail messages, libinput in particular?
You think are a god of linux making minimalistic installation , good luck with that.
Been doing it with other distros more than two decades.
Quote:
You have a lot of missing libs ...
Turns out the culprit was libinput apparently depends on libwacom. I never noticed that was so before. I have never had any kind of wacom device. *aylan* is not required.
It works now automagically, no need for xorg.con*:
What are you hoping to gain with a minimalist installation? Right now, it seems like a lot of headache to only save a few GBs.
It's not just a few, nor is it not just a few only once, but because of updates, there are repeats, both of bandwidth consumption, write consumption, and time consumption. I don't need 18GB for any other distro I've installed. Why should Slackware be provisioned differently?
BTW, those / partition sizes are the largest I use except on my 24/7 box. On most systems here, roots are 4G, 4.4G, 4.8G, 5.6G or 6.4G. All those 7.7Gs above as listed in my partitioner are sized 8.0G. All installations include Samba, none include web browser (except Konqueror), *Office or build environments.
It's not just a few, nor is it not just a few only once, but because of updates, there are repeats, both of bandwidth consumption, write consumption, and time consumption. I don't need 18GB for any other distro I've installed. Why should Slackware be provisioned differently?
I mean, you downloaded the iso which is under 4.3GB (3.6GB) and updates aren't that much. Write consumption is laughable as pretty much any NAND from the last decade can support far more writes than a normal person would ever write to it... orders of magnitude more.
Also, Slackware is unique compared to the other distros you mention because it doesn't document dependencies and it's designed to be installed as a full installation. Other distros make it easy to slim down by showing what packages require what. Trying to uninstall a critical dependency will tend to show what might break from it. Slackware does not do that. You're expected to have a fundamental understanding of dependencies and the knowledge on how to track down missing ones when you run a partial install. Your posts here have shown you don't contain that understanding yet. (BTW, libinput has defaulted to requiring libwacom since 1.8.0, which was released in 2017; it's up to 1.19.3 in 15.0.)
pretty much any NAND from the last decade can support far more writes than a normal person would ever write to it... orders of magnitude more.
That's the theory, but not my experience. I haven't been using SSDs 5 years yet, and have had to replace 3, a total failure rate of more than 10% among a pool of drives most of which are not run every day or even every week or month, and that doesn't count any partial failures, those whose performance has quite noticeably deteriorated or is erratic.
Quote:
Also, Slackware is unique compared to the other distros you mention because...it's designed to be installed as a full installation.
I didn't pick up on that until after choosing to install it, and then only by inference from using its installer's package selection system.
That's the theory, but not my experience. I haven't been using SSDs 5 years yet, and have had to replace 3, a total failure rate of more than 10% among a pool of drives most of which are not run every day or even every week or month, and that doesn't count any partial failures, those whose performance has quite noticeably deteriorated or is erratic.
Those failures would likely be unrelated to excessive writes unless you're using garbage-tier NAND devices. The most in depth test that I'm aware of was completed back in 2015 (started in 2013, so the drives are using almost decade old technology). With that test, even the lowest drive wrote 700TB before dying (it was rated for 22TB). 700TBs! That's 383GB/day for 5 years. If it were to write even 100GB/day (which is a LOT), the NAND would last 19 years. It was able to write almost 32x it's rated endurance. 2 of the tested drives surpassed 2PB of writes.
Current drives have increased their rated endurance and are likely capable of hitting 3PB or more if pushed. My Samsung EVO 960 1TB NVMe drive is rated for 400TB (introduced in 2017). I feel I'm a pretty heavy user of it and I'm using a whopping 4% of my rated endurance capacity. I've written ~25TB to the drive in about 20K hours of operation (surprisingly, I've only read 15TB). That's about 30GB written per day. If I keep that usage up, this drive's NAND should last for another 34 years before exceeding its rated write capacity. The more modern EVO 980 1TB is rated for 600TB.
It is far more likely for a flash device to have hardware failure than to exceed the write capacities of NAND devices. Hardware failures for NAND devices are usually tied to heat or power failure.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
