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.
Startx doesn't load kde as soon as boot my laptop it gives an error after sometime.And only on the second time it loads my GUI.
Code:
waiting for X server to shutdown (II)Server terminated successfully (0).Closing log file.nable to connect to X server: Resource temporarily unavailableocol specified.N
xinit: server error
You may need to express an "/sbin/modprobe (appropriate Intel GPU module)" in rc.d/rc.modules.local to insure it has loaded early or, if you use one, in initrd.
I dont use a generic Kernel. Can you please tell me what should I include ?
This could be the root cause of your issues...
Anyway, the huge kernel is supposed to be used only as a "recovery/emergency" solution - I strongly recommend you to use the generic kernel and an initrd.
Please do not tell me that's complicated. It's only a bit more complicated. And, after all, the Ubuntu, openSUSE and Fedora lives well with their initrds since ages - still I do not think they are (in average) smarter than us? or they are?
And please attach the full dmesg and X.org log files if you want meaningful responses.
Last edited by LuckyCyborg; 05-31-2022 at 04:09 AM.
And, after all, the Ubuntu, openSUSE and Fedora lives well with their initrds since ages - still I do not think they are (in average) smarter than us? or they are?
Anyone who finds a Linux distributions which is not a Slackware derivative that neither ships with a pre-built initrd nor builds one during the installation process wins a reputation point from me
PS Distributions that do not provide an official installer do not count.
Last edited by Didier Spaier; 05-31-2022 at 04:41 AM.
I'm with OP. I don't like and rarely use initrd on any system where i can avoid it. I'd rather build a custom kernel and forget about it than mess with the added steps and complexity introduced by initrd since I don't use encryption (the main compelling reason for initrd).
So I'd try various means to identify the best kernel module to modprobe maybe starting here
Or I would look through /boot/config for framebuffer devices and HD devices entries to see what's available. If they are checked for inclusion as modules just modprobe or insmod. If they are not, rebuild the kernel. Done.
BTW in the meantime one might have luck with X11 if the xorg.conf files demands "VESA" as driver until success with the actual Intel module.
I'm with OP. I don't like and rarely use initrd on any system where i can avoid it. I'd rather build a custom kernel and forget about it than mess with the added steps and complexity introduced by initrd since I don't use encryption (the main compelling reason for initrd).
About what "complexity introduced by initrd" you talk, man? There's no such thing - as Slacker you do many much more complex tasks than handling an initrd.
And aren't the Slackers the Bash Masters of Known Universe? What stops you to write a convenient script to automatize the "burden" to handle an initrd?
There's mine:
Code:
#!/bin/sh
KVERSION=`ls /boot/vmlinuz-generic-5.15.* | cut -d- -f3`
BOOTDISK=$(mount | grep 'on / ' | cut -d' ' -f1 | tr -d '[:digit:]')
#
KMODULES="bfq:uas:xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4"
ROOTDEV="UUID=fde92342-b611-41ac-9a42-8bd3b4df7ce0"
ROOTFS="ext4"
SWAPDEV="UUID=89eb4bf5-85c4-4e1d-a297-a3ce0d848e7d"
# Create the base initrd.
mkinitrd -c -k "$KVERSION" -r "$ROOTDEV" -f "$ROOTFS" -m "$KMODULES" -h "$SWAPDEV" -u -M -s /boot/initrd-generic-${KVERSION} -o /boot/initrd-generic-${KVERSION}.gz
# Symlink the final initrd.
(cd /boot; ln -sf initrd-generic-${KVERSION}.img initrd-generic.img)
# Update the kernel and initrd on the EFI boot.
echo "Updating the kernel and initrd on EFI partitition..."
cp -f /boot/vmlinuz-generic-${KVERSION} /boot/efi/EFI/Slackware/vmlinuz-generic
cp -f /boot/initrd-generic-${KVERSION}.img /boot/efi/EFI/Slackware/initrd-generic.img
# Run the LILO.
lilo -P ignore -b ${BOOTDISK}
This script I execute after upgrading a kernel, to update both the BIOS MBR's and UEFI's bootloader files.
So, this is "complexity" ? To put several commands in a script?
Anyway, after updating the kernel, you should update the bootloader(s) somehow, then you should execute something, either a script like this, or lilo or eliloconfig, or God knows what.
IF you bother to thinker a bit, the initrd handling introduces exactly ZERO additional complexity.
PS. This script was made years ago by an Ubuntunian tinkering with Slackware as a novice: me. The titrated Slackers certainly can make much better scripts.
Last edited by LuckyCyborg; 05-31-2022 at 11:41 AM.
About what "complexity introduced by initrd" you talk, man?
Actually he's right. With initrd you basically boot twice, so double the amount of things that can go wrong. Initrd is great for distributions, but for private users it's not needed, slows down the boot and increase the risk of things going wrong if you have a habit of doing custom Kernel/bootmanager stuff (which is often needed, and part of the game if you like fiddling).
I do like that there is the Kernel Huge in Slackware, it's quite a unique thing actually
But in this case, when something like that is wrong, the first thing to try is the Kernel-generic
About what "complexity introduced by initrd" you talk, man? There's no such thing - as Slacker you do many much more complex tasks than handling an initrd.
And aren't the Slackers the Bash Masters of Known Universe? What stops you to write a convenient script to automatize the "burden" to handle an initrd?
There's mine:
Code:
#!/bin/sh
KVERSION=`ls /boot/vmlinuz-generic-5.15.* | cut -d- -f3`
BOOTDISK=$(mount | grep 'on / ' | cut -d' ' -f1 | tr -d '[:digit:]')
#
KMODULES="bfq:uas:xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4"
ROOTDEV="UUID=fde92342-b611-41ac-9a42-8bd3b4df7ce0"
ROOTFS="ext4"
SWAPDEV="UUID=89eb4bf5-85c4-4e1d-a297-a3ce0d848e7d"
# Create the base initrd.
mkinitrd -c -k "$KVERSION" -r "$ROOTDEV" -f "$ROOTFS" -m "$KMODULES" -h "$SWAPDEV" -u -M -s /boot/initrd-generic-${KVERSION} -o /boot/initrd-generic-${KVERSION}.gz
# Symlink the final initrd.
(cd /boot; ln -sf initrd-generic-${KVERSION}.img initrd-generic.img)
# Update the kernel and initrd on the EFI boot.
echo "Updating the kernel and initrd on EFI partitition..."
cp -f /boot/vmlinuz-generic-${KVERSION} /boot/efi/EFI/Slackware/vmlinuz-generic
cp -f /boot/initrd-generic-${KVERSION}.img /boot/efi/EFI/Slackware/initrd-generic.img
# Run the LILO.
lilo -P ignore -b ${BOOTDISK}
This script I execute after upgrading a kernel, to update both the BIOS MBR's and UEFI's bootloader files.
So, this is "complexity" ? To put several commands in a script?
Anyway, after updating the kernel, you should update the bootloader(s) somehow, then you should execute something, either a script like this, or lilo or eliloconfig, or God knows what.
IF you bother to thinker a bit, the initrd handling introduces exactly ZERO additional complexity.
Since 2 steps (at the least) is more complex than just 1, the difference isn't ZERO. Having to repeat it only adds to it. Your way ids fine for you. Mine works for me and I find it substantially simpler. I avoid automation whenever I can. Step-by-step the end result is simpler, less complex. Small steps, Brother.
About what "complexity introduced by initrd" you talk, man? There's no such thing - as Slacker you do many much more complex tasks than handling an initrd.
The complexity comes when you are running your Slackware installations on more than one machine. For me, a custom huge.s kernel is the generic thing that fits on every machine regardless if they have IDE, SATA, SCSI, NVME or some more or less obscure RAID card to boot from. When a kernel upgrade is necessary, I can simply push out a new kernel package to all machines in the network and know that those custom packages doinst.sh have done their jobs with lilo on MBR machines and extlinux on UEFI machines so that the boot will work the next time any machine is rebooted.
I don't se any point in attempting doing the "one size fits all" configuration using a kernel together with an initrd. You would still end up pushing support of a lot of hardware to all machines.
Yes, you could probably make a custom kernel package where a more complex doinst.sh also creates the slimmed initrd, but then you would get installations where it is not so easy to move harddrives between machines.
Tried running the generic kernel too but the startx does only give me a blank for the first time.I have to press ctrl+alt+backspace and retype startx again to load the GUI properly.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
