Can't boot trisquel 10
- Login o registrati per inviare commenti
Hi, I can't boot trisquel 10, and even not the 9 on one computer.
I can get the bootmenu on the usb key, but then selecting "Try without installing" or "Install trisquel" leads me to a black screen. I was able to install trisquel 10 in text mode, but same problem when I try to boot it.
On the usb key the boot process stops after "assuming drive cache write through"; on the installed system screen is totally black and console mode is unreadable, I can barely see white pixels blinking. The usb key works well on another computer, so it is not a file integrity issue.
I tried antix and got the same issue in modern kernel mode but works well in legacy kernel mode, so I supect the issue is from hardware suport being out of the new kernel. Is it possible ? How can I be sure ?
Graphics card is Nvidia Geforce GT440 and Genuine Intel(R) CPU 2140 @ 1.60GHz.
If you are familiar with the process of replacing/installing memory modules, you could try
switching or swapping them in case one of a pair (if present) is bad. I'm suggesting this
because your Live thumb drive puts its operating system data into that memory and not on
any internal HDD. I have no experience with any of your hardware though ...
"assuming drive cache write through" appears every time I boot one of my Trisquel_10 O/S's,
and it completes the boot process every time with no further complaint.
If it was a ram memory issue, then I would not be able to use any other live system, but antix linux with legacy kernel works well and so did trisquel 8 on the hard drive btw.
I guess I should manage to reach the logs on trisquel 10 system partition to get an error message, but I don't know how to do that from the live system, and I don't know which logfile to look at. I mean I can mount sda1 and access /var/log, but the files are unreadable and I don't know which one is relevant.
I should manage to reach the logs on trisquel 10 system partition to get an error message, but I don't know how to do that from the live system, and I don't know which logfile to look at.
Identify the root partition of the installed system. Let us imagine it is /dev/sda3. To get a terminal in that system, execute:
$ sudo mount /dev/sda3 /mnt
$ sudo chroot /mnt
journalctl is the command to read the journal.
Ok, it seems newer kernels are at least seriously considering dropping support for a bunch of CPUs
https://www.phoronix.com/news/2021-Linux-Drop-Old-CPUs
The question becomes : what is the kernel version in use in Trisquel 9 and 10 ? I know this setup works with 4.9.
Trisquel 9 Etiona : 4.15.x
Trisquel 10 Nabia : 5.4.x
Trisquel 11 Aramo : 5.15.x
Of course, one can always try more recent versions of Linux-libre, but I believe these are the default versions that come with the iso, as told by:
uname -r
Ok thank you. Is there some way to install an older kernel from live session in my installed trisquel 10 instance so I can select it at boot time ?
Use the chroot method I have just explained you.
Ok thank you very much. Chroot worked well, and I was able to see some cpu and nouveau related issues at boot time.
I wanted to try kernel 4.19 from jxself's repository but I wasn't able to download any package from the chrooted filesystem. I have "Temporary failure resolving fr.archive.trisquel.info". Networking is ok on the host system.
It looks like one should copy resolv.conf from the host to enable dns resolution, but I can't manage to find it on trisquel's filesystem.
Maybe fr.archive.trisquel.info was down when you tried. ping tests whether a machine on the network is reachable:
$ ping gnu.org
Here is the output
ping: gnu.org: Échec temporaire dans la résolution du nom
It seems normal that the mounted filesystem can't reach the network https://unix.stackexchange.com/questions/280500/unable-to-reach-network-from-chroot
but I don't understand web protocols well and the files are not in the same locations. For instance, in trisquel there is a symlink /etc/resolv.conf whose source I can't edit.
ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 37 oct. 3 21:44 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf
vi /run/systemd/resolve/stub-resolv.conf
And when I try to save the file
"/run/systemd/resolve/stub-resolv.conf" E212: Can't open file for writing
On the page you linked to it says: cp /etc/resolv.conf /mnt/etc/resolv.conf
Have you tried that?
It says (translating from french)
cp: no writing through the dangling symbolic link '/mnt/etc/resolv.conf'
You may want to try with --remove-destination
as suggested there:
https://askubuntu.com/questions/551537/force-cp-to-copy-on-dangling-symlinks/551539#551539
cp --remove-destination /mnt/etc/resolv.conf /run/systemd/resolve/stub-resolv.conf
cp: impossible d'évaluer '/mnt/etc/resolv.conf': Aucun fichier ou dossier de ce type
But it worked well with sudo unlink /mnt/etc/resolv.conf
Thank you for the suggestion. I now have networking. I will try a few kernels
It works !
Here are the steps I followed :
- updating and upgrading the system
- installing linux-libre 4.19 and 4.9 from https://www.fsfla.org/ikiwiki/selibre/linux-libre/freesh.en.html
- as /dev wasn't mounted the kernels installation process couldn't update grub, so I used the recovery mode from the installed system to finish the job with apt
- booting from a functional kernel : 4.9 works well as expected and everything above doesn't
- finishing trisquel's installation from the commandline
Now I need help to check whether the issue comes from my graphic card's support being dropped from the kernel or not. How could I do that ?
Here are the errors I found with journalctl
oct. 03 22:13:37 domus kernel: nouveau 0000:01:00.0: DRM: core notifier timeout
oct. 03 22:13:39 domus kernel: nouveau 0000:01:00.0: DRM: base-0: timeout
You can try Linux 5.13 by installing the package named linux-image-generic-hwe-20.04 and rebooting. For version 5.15 or even 6.0, see https://www.fsfla.org/ikiwiki/selibre/linux-libre/freesh
For 5.15 you can upgrade to aramo too :)
Unfortunately I don't see upgrading to aramo as a solution by now. I tried 5.13 and 6.0 and none of them worked, I will try 5.15 but I doubt it will solve the issue. Nevertheles I want to find a workaround because 4.9 will soon reach its end of life.
Depending on the kernels used I sometimes have a blue pixelized line in the middle of the screen instead of the black screen. All the recovery modes give a basic resolution, but 4.9 adapts the resolution to the screen, which points to the graphics card issue, but how to be sure ? If it proves to be a nouveau related issue, in a way or another I should install the proper driver.
The nouveau driver is in the kernel...
I know that. If the issue comes from nouveau, I will have to compile it isn't it ?
Unless there are compilation options and the binaries you got were not built with the proper settings for you, compiling will make no difference.
You mean one cannot make his own version of linux-libre-6.0 for instance with selected drivers ? Maybe it is possible but requires very specific knowledge and experience ?
If you compile nouveau from the same source and in the same way (same options) as those who built the Linux binaries you tested, I do not see how it could solve your problem. Maybe jxself, who is expert in compiling Linux, will confirm/infirm.
Yes Magic Banana has it. If there are specific kernel config changes that are needed I'd be happy to discuss those.
Well I should first figure out where the issue comes from. I guess my graphics card (Nvidia Geforce GT440) is no longer supported but I don't know how to check it out. I did search on that wiki (https://nouveau.freedesktop.org/index.html) but wasn't able to find precise information
https://nouveau.freedesktop.org/FAQ.html#index15h3
Maybe should I check inside the bios, but I lack precise knowledge.
> graphic card's support being dropped from the kernel
What does this mean exactly? The phoronix article does not mention GPUs, but CPUs, so as long as your CPU is supported I would be inclined to believe that your GPU should be too. Of course, I may have missed a crucial detail.
EDIT: After closer reading, I realized that the article is in fact about "ARM platforms that could be removed following Linux 5.10 LTS as well as other CPU architectures without any real signs of life." There is no mention of any Intel CPU.
Well, so it may come from the CPU, I had CPU related errors at boot too. I don't know how to analyze the logs and determine what causes the freeze at startup with newer kernels. Maybe I could run some tests for the graphic card ? Maybe inside a VM ?
If your plan is to customize a newer kernel in order to solve the problems you are currently experiencing, this looks like a red herring, as both MB and jxself seem to be pointing to. You should not take my word on it, though, I have no further experience in dealing with Trisquel kernels than obediently using the one that comes with each upgrade.
Longterm 4.9.x kernel is indeed supposed to reach its EOL in January 2023, from what kernel.org says. It looks to me that you are already playing the best card in your hand, which is to use the highest working longterm kernel.
Actually I don't know where the problem comes from and I am desperately asking help to identify it.
Maybe it is just some trivial boot parameter, or xorg misconfiguration. Please help me to identify it I don't know what to do .
I am no expert in Nvidia stuff at all, but possibly the driver for your GPU may not have support for newer kernels than 4.9.x? As frustrating as this may feel, there is not much you can do if this is the wall you are actually hitting.
You may still want to try and answser jxself's invite: "If there are specific kernel config changes that are needed I'd be happy to discuss those." Maybe ask him how to modify the kernel config in order to force an older version of the nouveau driver? If that even makes any sense, that is.
There is absolutely no proof that the problem comes from the GPU. I lack specific technical knowledge to investigate. I only saw some red lines in a logfile that I don't understand. There where other red lines about other things and I need help to investigate, run some tests, etc.
What I am asking is : could someone help me to identify where the issue comes from ? Maybe it is just a trivial configuration parameter in a Xorg config file or such.
Isn't there a commandline test program that could help me to check how well is supported the hardware ? I could use it while booting in recovery mode from the latest kernel.
You may still want to try and answser jxself's invite: "If there are specific kernel config changes that are needed I'd be happy to discuss those."
In order to do some config changes, we should first identify with certainty where the problem comes from.
What if you use a newer kernel and try nomodeset? Is there a difference?
Wow thank you, with nomodeset it just works. Well the resolution is stuck to 640x480, but it works. I tried with kernel 6.0.1
I did some search about nomodeset and as far as I understand we can now be sure the issue comes from the GPU's driver isn't it ?
Isn't there a tweak that would allow me to use a greater resolution with nomodeset ? I tried xforcevesa but saw no difference.
El 2022-11-01 10:25, name at domain escribió:
> Wow thank you, with nomodeset it just works. Well the resolution is
> stuck to 640x480, but it works. I tried with kernel 6.0.1
>
> As far as I understand we can now be sure the issue comes from the GPU
> isn't it ?
Yes.
Perhaps loading the right drivers will make things better after entering
X-window system. If you want to keep yor freedom, don't load drivers
from external sources. Use Trisquel repositories. The package is
usually called nouveau. But it depends on your graphics card chipset.
That seems an improvement at least. I might just replace the graphics card with something else.
If you do lcpsi -v with and without nomodeset, what does it say for "kernel module in use" in your card?
Sometimes it's just a lot of experimentation based on what worked for others. I wonder if these ideas work?
https://askubuntu.com/questions/761149/how-to-set-display-resolution-while-having-to-use-nomodeset-on-boot
https://askubuntu.com/questions/1246482/i-got-a-black-screen-every-time-ubuntu-boots-and-i-cant-get-to-the-grub-menu
If you do lcpsi -v with and without nomodeset, what does it say for "kernel module in use" in your card?
I tried with 4.9, 6.0.1 recovery mode and 6.0.1 with nomodeset. They all say "Kernel modules: nouveau".
I discovered something very interesting : If I choose the option "resume to normal boot" during 6.0.1 recovery mode boot process, I obtain the normal GUI with a resolution of 1024x768. I don't know what it means but it seems very interesting.
I might just replace the graphics card with something else.
I will first try your suggestions to see if I can improve the resolution with nomodeset. I may find a GPU that suits the mainboard in my house but it will be quite old too. I don't have money to invest in a new graphics card right now.
I think that support for older hardware should be maintained as long as possible. I really find it odd thinking that my GPU would have been removed from nouveau's support list. I think there must be a configuration tweak inside nouveau that would make me able to still use that card longer.
Not necessarily but I am working on a theory. Can you try Linux-libre 4.14 from my repository and let me know how that works? It's not clear if you've tried 4.14. I understand 4.9 = good and 4.19 = bad but 4.14 = what? :)
4.14 works very well ! Thank you for the suggestion ! I obtain a normal desktop with a proper resolution of 1360x768. In case you need that information lspci -v also indicates "Kernel driver in use: nouveau"
OK - That extends out your kernel support for another year then.
What I'd like to see would be that 4.19 does work and 5.4 and later don't. That would be consistent with my theory but if 4.19 really isn't working then that breaks my theory.
OK - That extends out your kernel support for another year then.
Yes thank you for that. That will give me some more time to figure out what's happening or to find a suitable new GPU.
Unfortunately 4.19 isn't working. I checked again and I obtain the usual blue lines just after the Gnu/linux-libre logo, and the screen freezes.
Hmm. Well, that kills my theory.
It might be interesting to try the mainline Ubuntu kernel builds purely as an experiment (and promptly removed later.) If the mainline one also don't work then this could be a bug to report upstream to the Linux kernel people to be addressed in a future version.
Yes I was thinking about asking nouveau's team, but if I should rather send a message to linux kernel people, then I will do that.
I will try that nomodeset resolution tweak and various kernels. I had to find a new lowlatency kernel anyway, so I'm on my way. Thank you very much for your help, it was very useful and greatly appreciated. Thank you also for maintaining linux-libre kernels.
> I tried antix and got the same issue in modern kernel mode but works well in legacy kernel mode
Do you have a link about this "legacy kernel mode" of the antix installer? I am asking because it looks like the most promising thing according to what you wrote but I failed to find what this refers to.
I did a search on the internet, and apparently this means using kernel 4.9.
Yes that's what it means. They do it to maintain a good compatibility with older hardware, while being able to easily use it with newer hardware.
https://www.antixforum.com/forums/topic/modern-kernel/
El 2022-11-01 11:23, name at domain escribió:
> Yes that's what it means. They do it to maintain a good compatibility
> with older hardware, while being able to easily use it with newer
> hardware.
> https://www.antixforum.com/forums/topic/modern-kernel/
No. They do it to gain more users. They do not care about their user's
freedom.
- Login o registrati per inviare commenti