No, it looks like they both have the same problem
Pcie bus error
I would try pulling out the cards from the bus slots, and reseating them … take static precautions. Power off of course.
Other than that there is not much you can do… It is not a rogue process, at least I dont think so, it looks like hardware .
Yep. That’s why I figured something is wrong with motherboard, cards, cables, something hardware.
I will try reseating but won’t I need to do a fresh install to test it fully? This one is too full to install anything else, even after trying to empty the syslog.
Thanks.
If reseating fixes it, it should boot and run without writing further errors.
Then you should be able to clean out the logs.
I dont think you need a reinstall… but if you do use normal MX.
Do you know which device on the bus is giving the error… or is it the controller?
Whats this liquorix kernel?
Get rid of that.
You want a normal Debian kernel
I have no idea how to interpret the logs to hardware components. I only know PCI-e is one of the slots, maybe the Nvidia card I installed a year or so ago. I upgraded the RAM before giving it to my Mom, but it tested fine in those logs.
AHS uses the liquorix kernel for newer hardware…how new, I do not know. I do know I could not even find the flatpaks to install in the MX install. Searched and was told I had to enable them in repos and doing so, then installed the same thing for all those testing and flatpaks. I thought at first that installing those caused an issue. So that is why I reinstalled with them in the initial kernel.
But after reseating, I will test with reg MX and if it still does it, it is a hardware failure unknown to me. And it’s not like I need this computer 
I have 5 in use now. I just wanted to fix it if it was possible. Never know when someone might need one.
But I have checked on motherboards, AMD chips, etc. and it is not cheap. So if it still has issues, I will just store it for now.
Thanks,
Sheila
Something to check when you re-seat everything is that the RAM chips are fully clipped in. Years ago I had a computer that was intermittently misbehaving. It took me weeks to discover that I hadn’t fully locked the clips around the corners of one of the RAM chip boards. This resulted in it having poor contact with the socket from time to time.
Question:
I unplugged the PCI-e Nvidia gpu just to see if that was causing the issue first. I have now rebooted with the hdmi in the integrated gpu port. But for some reason, I can’t see anything on the monitor. So first, wouldn’t it automatically switch from the missing port to the other HDMI port in use now? I would think the BIOS would at least come up.
So I powered down, reinserted the discrete card and tried again. This time it wanted to recover BIOS settings. So while I knew it was booted into BIOS, I tried switching the HDMI cable back to integrated but without success. So I went back to the discrete port and hit F1 and BIOS was restored.
I know the reset was due to removing the Nvidia card, but it seems like I cannot use the desktop without it as the port in the igpu is not working.
But of course, now MX installed will not boot as computer reports the disk is full. So running live session. But BIOS only shows the USB (it shows 2 because there are 2 3.1 ports to boot from) and the one I chose returned the same error message MOK disk is full and choosing one of the USBs returns the message to hit OK to boot next device. I do and then it returns the MOK error message.
So I guess this computer is done.
Thanks for the help, at least I know now.
Sheila
@Sheila_Flanagan
Remove or unplug all drives and the gpu, power up the Asus MB and see if the post screen comes up!! If it does not, then you have a mobo or PSU issue!!!
Looks like you have a similar issue:
IMaybe try to add pcie_aspm=off to kernel boot parameters.
This one I could not answer from my phone 
I had to check first, wether i5-6400 does have an iGPU at all…
Yes, it has
So my guess is, once upon a time when the discrete GPU was placed into that computer, the iGPU was probably disabled in BIOS.
Now when you remove that nVidia, the motherboard operates without any graphics. That’s fine for a headless server, but not for a desktop
So BEFORE you remove the nvidia, check the BIOS, and enable the iGPU.
Remove the discrete GPU only afterwards.
You do not need to disable the iGPU for using discrete GPU.
There should be an option in BIOS, which graphic to init first when powered on.
If this is set to PCIe, the discrete card will be used as primary graphics, so the BIOS and its messages will appear on that, however, the iGPU (as secondary) will still be functional and usable.
(I also have iGPU enabled on my desktop, no monitors are attached to it, but that makes me the quicksync video codecs available)
Disable secure boot.
MX is a modified Debian. My first move, when trying a derivative distribution, is to boot the newest ‘mother’ distribution, which helps distinguish a software (MX) problem from a hardware problem.
I’m about ready to dual-boot Debian and Fedora and only do virtual installations of any derivative distros. You two are way smarter than I am: I have to use the KISS principle.
I dont want to criticise the choice of MX linux I am sure its a good product … but there does appear to be several issues with it causing all sorts of problems. Unless there is good reason to keep it over another debian linux version perhaps its time to jump ships and go with a more robust system
Sorry just my 2p thrown in the hat.
I do read the back and forth offering suggestions and appreciate how much goes into solving …
I have no issue with MX.
Used it for a while and not failed me so far.
All distros have their issues. MX is not immune.
Most issues end up being users fault… eg my switching from an MXahs to a normal MX kernel
Perfect statement.
Of course…duh. I always disable this but since it reset the BIOS it -reenabled it. But even though I went into Advanced>Trusted Computing (I thought that was how I disabled it before) it only says TPM20 Device Found and options are Security Device Support “Enable” and TPM State I chose “Disabled” and rebooted. Back in BIOS, under BOOT there is a section called Secure Boot. Selecting that shows Secure Boot state “Enabled” and Platform Key (PK) state “Unloaded” The only thing I can change there is OS Type. So I chose Other OS instead of Windows UEFI Mode.
But I do not remember how I got it disabled before.
Believe me it took forever to find it in a submenu of SA Configuration. WT?? And under that iGPU was disabled.
Thanks for that.
I still have to try Daniel’s suggestion to test the motherboard, but I put back in the old SSD that I thought was bad, and system booted. MX Linux is on that old SSD as well.
I will have to use my disk enclosure on another computer to wipe the new SSD and get it parted so that I can put it back in the ASUS and try again with a fresh install of Linux. Just to be sure, this time I am going to put a basic Sparky Linux and see if I get the same results of PCIe messages filling up syslog now that I have removed the dGPU card from its slot.
Will report back as I make progress. Working during the week, not a lot of time to work on this thing.
Sheila
Just wanted to update status so far. After I booted to MX on the old SSD, GRUB appeared and I selected it. Then I guess it hung, screen went black and when I finally rebooted, logo flashed and nothing.
So after attempting to use the new SSD to format and install an OS without success (even Sparky froze), I put back in the old SSD that was also full and got Debian 12.7 to actually work by erasing entire disk and installing. So far, so good. But, I went into the journal and this first line I had seen in a message upon each boot, but never got to read it all.
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR contact BIOS vendor for fixes
DMAR: Your BIOS is broken; bad RMRR [0x000000008d800000-0x000000008fffffff]
BIOS Vendor: American Megatrends Inc.; Ver 1102; Product Versoin: Sytem Version
That is the only error showing and I am wondering if this could be the issue. Now to shut down the system, unplug all USBs and SSD (already removed dGPU before attempting to install new OS) and see if motherboard and PSU are okay.
UPDATE: I did as @kovacslt suggested, using that article to insert the phrase in grub file. Then my research on the BIOS error said it had something to do with secure boot and windowesque things when running Linux. So an article listing the methods to modify grub to disable secure boot:
On Linux:
Locate the Boot setting in the boot manager or GRUB configuration.
Edit the GRUB configuration file using a text editor (e.g., Nano or vim).
Add or modify the append option to disable secure boot: append safe-mode-allowcslist=none
So added that and rebooted. I have not installed anything and as I am unfamiliar with Debian-Mate DE, the package installer is foreign to me compared to MX Linux AHS GUI. I first tried to install Barrier (input-leap was not available) and that returned errors about connecting to pkg repos. So used the terminal for updates and got a rather strange output:
E: Release file for http://security.debian.org/debian-security/dists/bookworm-security/InRelease is not valid yet (invalid for another 3h 8min 7s). Updates for this repository will not be applied.
Thanks,
Sheila
Adjust your computers time. It is somewhat off by few hours.
Probably the Debian repo was updated recently, say at 20:00.
Your computer thinks it is 17:00 so the signing of the repo is invalid yet.
Yup. Due to the time being in the upper right corner, never even saw that it said 7 hours later than timezone. Strange, because I set the time in the install. And after BIOS was reset, I noticed the time was off there as well. So I adjusted that, too.
I had left the computer off until just now, to ensure I did not get a full disk while sitting overnight. Upgrades in Debian with a couple of issues:
The “append” that I added (instructions were for Mint, I believe) to GRUB was apparently not recognized in Debian
Set the RESUME variable to override this. /etc/ernel/postinst.d/zz-update-grub:
/usr/sbin/grub-mkconfig: 11: /etc/default/grub: append: not found
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 127
Job for systemd-journald.service failed because a timeout was exceeded.
See "systemctl status systemd-journald.service" and "journalctl -xeu systemd-journald.service" for details.
Errors were encountered while processing:
linux-image-6.1.0-31-amd64
linux-image-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
Not sure if any of that is helpful, but will update after work today. Currently drive space used is 433.8 GB not too bad so far since it started with 448.4 GB
Sheila
You could have a problem with the cmos battery if the clock is off … may be worth replacing if you can. May not be related just a thought.