Damn Small Linux Forums

Sorry for my previous hurried post.

If X crashes without writing any log file I haven't any error to read and post.

Also, plop shows "device connected" and then freezes without further messages, so I haven't any error to post as well.

Assuming that at least vesa should work, I set it in the xorg.conf and run "X -config ./xorg.conf". It crashed without writing any log file.


Next, the "plain old" apt-get install is new to me since all the debian stuff is new. As is, it doesn't work.
It has probably to point to a different repo than the default one.

Tried "noaccel" as well.

I'm too ignorant about debian and Xorg and I had promised it.

I want to say thank to all of you for the time you have devoted to me.

OK thanks for the patience and apology for kernel problem.  First --- hopefully @John can see this because I don't know the answer but I *assume* it's legal (recommended) to adhere to the AntiX directives:

[attachment=30]

"28 April 2024 - URGENT - Expired GPG Key errorFix:
Option 1:When prompted type your user password, press enter"

I wrote that kernel stuff from the repo in RC3 and it seems different.  It is definitely preferable to have the normal apt-get process do these things instead of doing it manually.  I'm inquiring at the mothership about it momentarily. 

FWIW, the old kernel & header .debs are retrievable here:

https://repo.antixlinux.com/bookworm/poo...2-486-smp/

EDIT: It's in the http://la.mxrepo.com/antix/bookworm repo in my RC4, too--it should "just work"--somehow I didn't find it browsing last night.

I don't know which RC you installed or whether repos are different (deleted my old ones), but if you

cat /etc/apt/sources.list.d/antix.list

you can see what you are using. To search, you could

sudo apt-cache search linux-image-4.19

but

sudo apt-get install linux-headers-4.19.276-antix.2-486-smp_4.19.276-antix.2-486-smp-1_i386 linux-image-4.19.276-antix.2-486-smp_4.19.276-antix.2-486-smp-1_i386

should "just work".

It's probably worth repeating that if grub doesn't run during inst, update-grub needs to be run and that the new kernel will not be the default at boot but rather need to be selected from the Advanced grub line.

I installed RC 4, and it reminded me how slow the video configuration is the first time, and your system is much older than mine. Try again from the beginning, and wait quite a long time before concluding that something didn't work and giving up.

Ok, I used the above xorg.conf set to the vesa driver without any other config files and waited 50 minutes.
It stopped after about 10 minutes, here is the log:


My RC is 3 anyway.

So you reinstalled your RC3 from scratch and used your preceding conf file?

I reinstalled it from scratch 11 days ago, since it's clean no need to repeat it.
I used the vesa xorg.conf that is supposed to work, and waited a long time as suggested by Yan.

You could try the monitor part from this page:

https://www.marmotte.net/linux/laptop/asus/XF86Config


You might be fine with multiple modelines as long as they actually work.

I doubt the vendorname and modelname matter other than to distinguiah one screen from another
but if these modelines work for the panel in your laptop it would be better to specify it than wait for it to search.

https://en.wikipedia.org/wiki/XFree86_Modeline

some nice details there

Haven't gone away, just awaiting updates.

In the meantime, when you are at grub menu screen at bootup, hit c for a command line and when you get one, type

vbeinfo

and note the modes (pic would be great as I don't know how to get a screenie right there).

Either way, that'll tell us what the thing supports for modes.

ESC to get out/back to grub menu, BTW.

Also BTW, did you know Plop has their own forum...as does X (which is likely where we're heading).

EDIT: cli-aptiX seems the easiest way to get kernel changes/upgrades (or old kernels) as searching can be confined to antiX kernels easily, FWIW.

Did some attempts: added some modeline entries but the siliconmotion driver rejects them while the vesa driver ignore them.

Here are the relevant Xorg.log files:

siliconmotion

---

vesa

And here is the output of vbeinfo:

Adapter Vesa BIOS Extension Video Driver:  VBE ver. 2, OEM software rev. 2
Total mem: 4096 KiB

1280x1024x24, x16 (direct color), x8 (paletted)
1024x768x24, x16 (direct color), x8, x4 (paletted)
800x600x24, x16, x8, x4
640x480x24, x16, x8

Adapter Cirrus CLGD 5446 PCI Video Driver: no info.
Adapter Bochs PCI Video Driver: no info.

Thank you for all that. So did the vesa one hang there? There's no exit code, you know? It almost looks like it's running? If it's not, reduce the depth from 16 to 8--or 4 and take a hack to see if any 1024 stuff runs.

There's a lot to look at, here, given the previous results as well. I still wonder if, in post #54, it was still trying to complete another "RedMaskSize" and the 50 minutes wasn't enough (can you let one thrash overnight?). And I don't think (guessing only--please correct @Yan) he meant to use any config file but to let it all go with only the default xorg.conf.in as in a fresh installation. Ending day/need to review this with fresh head--thanks again.