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.
karthik_holla, it is probably wise to insure the intel module is loading with "lsmod | grep foo" and then including that Intel driver in xorg.conf. Also you can always temporarily use
Code:
Section "Device"
Identifier "VESA Framebuffer"
Driver "vesa"
#VideoRam 4096
# Insert Clocks lines here if appropriate
EndSection
as a backup, always working (just no acceleration), X11, if you prefer editing from X..
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.
At least it is good that you have an error that you can repeat and even better that you can repeat success. If you are lucky, some log entry will explain what goes wrong when it fails.
You probably have two log files that could be interesting to study:
/var/log/Xorg.0.log
and
/var/log/Xorg.0.log.old
Are you able to find any interesting relevant difference between those two files when you successfully have started X and the previous attempt failed?
karthik_holla, it is probably wise to insure the intel module is loading with "lsmod | grep foo" and then including that Intel driver in xorg.conf. Also you can always temporarily use
Code:
Section "Device"
Identifier "VESA Framebuffer"
Driver "vesa"
#VideoRam 4096
# Insert Clocks lines here if appropriate
EndSection
as a backup, always working (just no acceleration), X11, if you prefer editing from X..
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.
WHAT?
The usage of an initrd is the greatest solution for making hard drives easy to move between machines. By using UUIDs for partitions. In fact, the single way to use UUIDs in the boot stage is to use an initrd, because it's init script translate them to the real devices.
It's a so great solution for this, that I use it to create Slackware full installations in external USB hard drives, supposed to boot anywhere, with the boot drive randomly changing between /dev/sda and /dev/sdz , depending on host box.
You are kind to tell me more about where you heard/read that "you would get installations where it is not so easy to move harddrives between machines" ?
Last edited by LuckyCyborg; 06-04-2022 at 03:54 AM.
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.
Excuse me, BUT about what 2 steps vs. 1 step you talk?
The tipicall kernel update is upgrading the huge kernel and modules packages and runing LILO or ELILOCONFIG. Means: 2 steps.
What I do is upgrading the generic kernel and modules packages and running this particular script. Means: 2 steps.
The complexity of upgrading the kernels is equal for me.
Oh, wait! According with you, it's building a custom tailored kernel "substantially simpler" to handle than adding a line in a bootloader config file? That's substantially simpler?
Don't understand me wrong - I consider the usage of huge kernel a quite bad habit, just like is the smoking. Out of respect for your freedom of choices, I will never tell you to quit smoking, BUT I truly disagree with the smoking advertising.
Last edited by LuckyCyborg; 06-04-2022 at 04:06 AM.
For the Intel Iris graphics you should use the "modesetting" driver, not the "intel" one.
So, remove all files from /etc/X11/xorg.conf.d or any /etc/X11/xorg.conf files and create a file /etc/X11/xorg.conf.d/20-intel.conf with this contents:
From reading that it seems everything is just dandy and should work just fine..
Seems to me the Kernel loads the driver correctly, and Xorg uses it correctly. And pretty much everything else seems fine as well, at least nothing that would prevent startx from working as it should.
What happens if you start with runlevel 4? Same thing?
Can you start Wayland? (dbus-launch startplasma-wayland)
Just FTR Lucky Cyborg, I don't use Huge or Generic plus initrd except for the very first boot, if then. I build a custom newer kernel and usually keep it for more than a year. All my boxen are multiboot, and I can copy "/usr/src/linux, /lib/modules/foo, and the 3 files in /boot and they just work with very high performance, more accurate CPU instruction, lower latency, faster timing and very few unnecessary modules. I don't care a whit that some people (probably more than don't) prefer generic + initrd. It is individual choice after all but there are alternatives. Granted geninitrd is substantially better than mkinitrd IMHO but I know I am going to build a custom kernel anyway for increased performance so why not just eliminate an initrd while I'm at it?
increased performance so why not just eliminate an initrd while I'm at it?
I make a Kernel for each computer, I'm not super great at optimizing, but even so it is far more optimized for my situation(s) and my computer. Not sure that is the reason it boots so much faster than with Initrd, but it could partly be a reason.
Just feels rock solid stable as well (and likewise does Slackware15), never any trouble and booting is uncomplicated, if things go wrong I can only blame myself.
You are kind to tell me more about where you heard/read that "you would get installations where it is not so easy to move harddrives between machines" ?
I meant that if you would create a slimmed initrd which only contained the modules needed for your current machine such a drive would not be easy to move around different machines.
Of course it is also possible to create a full featured initrd matching all the hardware support you get from a huge.s kernel, but then, what would be the point of using initrd instead of a huge kernel?
It seems to only be one log file from xorg. To find the difference between when things go right and when things go wrong you will need to compare the log file from a failed startx with a log from a successful startx.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
