Debian User Forums

Assuming all the hardware is good, like cables properly connected, then the following may be a start to look at the issue.

To check whether alsa can actually play through the speakers, one can run the command:

speaker-test -c 0

Or:

speaker-test -t wav -c 2

If alsa can play through the speakers, a white noise should be heard through one and then the other speaker. To stop the test before it runs it's full course in case it's not needed, use cnrl+c.

If sound can be heard at the level of ...

An initial look at the files which each application opens might be of interest. For that one can run, for example: and compare the number and nature of the files against the output of the command which opens the gnome system monitor. I'm not familiar with the gnome app but I guess it has a command to open it. If one can determine the PID of the gnome app, then the results of the lsof command can also be obtained from:

Perhaps consider the lpr command from the cups-bsd package. It's used here without printing extra pages. YMMV

dbus appears to be activated here: /etc/X11/Xsession.d/20dbus_xdg-runtime

Alternative to inversion is creating any number of colour calibrations, or a number of them that are preferred, and using them at will.
Here's one used here: Adjust to preference. To revert to default: xcalib -c

This works on the log file: and makes it quite readable.

Are you able to select the default card in alsamixer? I start alsamixer in the terminal, hit F6, and then can select the default card.

Some info here: https://www.kernel.org/doc/Documentation/fb/modedb.rst
Perhaps run: to see which drivers, if any, have been loaded that support modedb.

Couple of ideas: 1. change the sata cables; 2. try kernel option: libata.force=3.0Gbps
These were successful for some users online in the case of the error: "failed command: READ FPDMA QUEUED"
No guarantees, just reversible suggestions.

A file with the relevant contents in post #1 can be written, as root, to /etc/xdg/user-dirs.defaults as a configuration for new users.
The commented text in the current /etc/xdg/user-dirs.defaults is:

# Default settings for user directories
#
# The values are relative pathnames from the home directory and
# will be translated on a per-path-element basis into the users locale

which is followed by a listing such the one in post #1. If you want that listing, write the file. You can reboot to ...

On the .bashrc file, you most likely can copy the .bashrc file from here: /etc/skel/.bashrc, into your /home/$USER/ and you will then have the default .bashrc which you can have applied to a terminal by sourcing it: or logout and login in again.

On office packages and browsers not opening, perhaps try opening them from a terminal to see if error messages appear in the terminal output.

If /var/log/sysstat/sa21 is created, and sysstat is enabled in /etc/default/sysstat, and systemctl has enabled and started it, then a command like:

sar -u

would normally show output of the current CPU usage for the current day. If it's not working, the output will say that sysstat can't open the relevant file.

ACPI error messages are common in linux. The reason is that the linux kernel
follows the industry's open specification for the implementation of ACPI standards,
but the manufacturers of BIOS/UEFI don't always do that, rather they often issue
their wares with "stuff" that works. There's quite a bit of info on this issue online, e.g.
https://unix.stackexchange.com/questions/476600/acpi-errors-how-why-and-whats-the-deal
In the kernel docs, one finds comments such as:
"Complain to your platform/BIOS ...

You could try the same act of plugging in the cable after the machine has booted and see what dmesg says, e.g. what is the output of: Maybe something there.

Is the video card supplied with a proper driver and the updated firmware?
Perhaps run to check the driver and the module: Then, you can check if the latest firmware for that card is installed.

To see where the largest files in your home directory you could run:

Vangi wrote: 2024-01-02 21:33

lindi wrote: 2024-01-02 14:24 You Debian setup most likely does not use TPM for anything.

Thank you for the reply. Does that mean I can click reset? Or enter the BIOS and disable it entirely?

Yes to the second question.

ACPI error messages are common in linux. The reason is that the linux kernel follows the industry's open specification for the implementation of ACPI standards, but the manufacturers of BIOS/UEFI don't always do that, rather they often issue their wares with "stuff" that works. There's quite a bit of info on this issue online, e.g. https://unix.stackexchange.com/questions/476600/acpi-errors-how-why-and-whats-the-deal.
In the kernel docs, one finds comments such as:

Complain to your platform ...

You could try and have the volume set to 100%, or any percentage, using the amixer command in a start up file like .xsession, or failing that, create a systemd unit to run the amixer command at start up or write a simple /etc/rc.local file. A command like the following can be used:

Presumably the configure script is in the directory where you are trying to run it. Perhaps show bash the command by running: