Odd overnight issue [4.2.1]

I did a moderately intensive hardware upgrade last night. Upgrades from 32gb 3400 mhz memory to 64gb, well it was supposed to be 3000 according to the packet but it’s been nearer 2200 so far. I also installed pci express bifurcation device (allows multiple nvme m.2 to be install in a pcie slot). I put an extra network cable into my dual nic network card snd plugged in a usb pci cardin. I also installed a ps2 mouse on a y adaptor with my ps2 keyboard al though it seems these y cables are not as plug and play as they used to be back the day because my alreadybin situ keyboard promptly stopped working…

I didn’t touch the core os drive nor, for that matter did I use the main rig to upgrade any other sw. Last I used it was about 7h ago when i did a memtest on the 4x8gbbdimms memory that uninstalled and replaced by 4x16gb dimms about an hour or so later.

The machines behavior since plugging the power back in has been rather odd. Firstly the machine booted into a windows install I don’t recall having but i assume from ine of the newly bifurcated nvme drives booted up. But despite now having two plugged in nics neither was available. And the ps2 keyboard stopped working although the usb optical scroll mouse was still functioning. Upon a reboot the automatic 1st boot win 10 drive magically failed back to my default system qubes login.

But it’s all screwed up inside. The bios isn’t working how it was earlier. It seems e had rolled back to an earlier version qubes were inlinre with expectations but different. The usb service wubes were missing and so my mouse nonlonger works. The picture on my desktop no longer works. I have no nics working.

I’m going to quickly rip out as much of the hardware as I can in case it’s causing an interaction somehow. Removing the ram isn’t as straightforward without completely dismantling the pc. But I’ll run mem test on it in the meantime.

It’s hard to put my finger on the issue but everything seems different. There’s no network or sys usbs. All I can think imof iscto do a fresh install and restore from the previous backup, even though I’m not sure where it is.

I have been investigating this issue in detail overnight and it really is most perplexing.

At first I did a complete system revert to see if that unfucked my install and/or allowed me to use my keyboard and mouse to at least backup the qubes that I deemed more important. At first this line of investigation seemed promising, because the bios issues I was experiencing concurrently seemed to be working themselves out. Then all of a sudden I saw a screen I had not seen before in the bios; somehow the bios itself had become corrupted and upon seeing several recommendations to buy a new motherboard wondered if it was the early onset of this issue (perhaps when doing the hardware upgrade the day before) that had predicated the issue I was experiencing with my Qubes OS.

Fortunately I managed to recover from this issue, despite the lack of a dedicated reflash button on my motherboard (won’t overlook the need for one of those next time I buy one though). This BIOS led to several false flags as I tried a host of hdd permutations because initially when I reverted the bios to default settings I forgot that I needed to re-enable the 3 virtualization settings within my bios, one of which (IOMMU), to my great surprise, could only be located via the search function.

Eventually I began to wonder if it might be possible to reinstall a new version of Qubes on a seperate drive, and then bckup some of the necessary qubes from the non-functional install and port them across to the new. By now this non-working install would not boot into qubes at all, and despite trying the recovery software on my various qubes install usbs did not seem to be getting anywhere fast.

Yet my having deleted the windows install via the bios utility amost immediately it wouldnt stop flagging as a bootable system after every install. Eventually the installs on my drives began rustling in vast pages of error messages which to my untrained eye seemed to be implying the dom0 itself was no longer on the system. Clearly my efforts to troubleshoot the problem were exacerbating the unknwon issue I was trying to resolve, rather than fix them. Although I exported the journalctl logs, I could not get them to export to my attached pen drive, and wound up exporting them to the /boot folder as suggested by system in the terminal shell that was the only thing by now surviving from the original install.

Fixing on a new install/portage sgtrategy as seemingly the only thing left I could try I removed the original nvme to avoid any potential contamination from the subsequent re-install I planned to undertake. But first I chose to use a live install to attept to save the log files so they could be hosted here. But try as I might, the live install (Mint chip xfce) I believe could not locate the two log files I had previously saved in the /booth folder of the oribinal install. Even worse, the boot folder itseld no longer appeared to be there because the only one showing up in my searches was the pne attached to my live install.

If Ifelt a little disgruntled that two files I had been so careful to save were no longer where they were mere moments before, the lack of an entire boot directory promulgated a sudden sliver of fear into my belly. Had I been onfected with a vris? was somebody pentesting me? It seemed difficult to know what to do other than investigate further.

Despite this extra previously bifurcated windows install (by now wiped) being the only one now on my system at all, the issue remained as intractable as when first it manifested itself. Furthermore, it seemed to be haviing an effect on my ventory disks because all of a sudden gparted, itseld installed in memory began to throw a wobbler before susbequently refusing to boot at all.

By now it was nearly 6am and I had once again worked through a period of the early morning hours I have dubbed porn-o’clock. The family would soon be up and my opportunity to onanistically abuse myself had once again been dashed by this blasted issue. Time to bring out the big guns I thought reaching for some disk santising software that I tended to see as a nuclear optuion given it negated the ability to recover anything at all.

Yet even whatever it was affecting this hard drive simply laughed off the sanitising software with the system crashing shortly after the system had installed. As I rebooted it again I noticed that the configuration files were suddenly now missing or corrupted; I swear, I hald expected to see a Mossad flag rise up over my computer. nothing, it seems could fix this issue. And when I tried a final time I discovered that the boot drive of the ventoy disk had now been removed as well.

Despite this nvme only being 3 months old, I am beginning to think the only solution might be to rip it out and throw it away. Cant think of what else to do… not if I want to be sure of not missing porn-o’clock for a third nght running.

As I say, not sure this is really a qubes issue any more, but i simply leaving a book half-read or, for that matter, a story left half told. And as I say, the log files from journalctl are no longer where I had saved them earlier. But as I sit here reflecting on what happened with the various qubes installatrion usbs, installed drives, and live linux disties of other origins on other usb disks a single unifying thread looms large in my head. It is something to do with initramfs. That was something that seemed to be happening in everything i read a log for. What that means, however, is beyond my ken nor wit to interpret.

It has been a most perplexing day, given that no matter what version of wubes I install, nor the recency of the kernal, or even the hdd configuration, Hdd medium, nor even it more lattrtjy seems even the Os type (drbian/windows) or even install type (to disk or as a live usb) in every single permutation then shortly after whichever install begins the system resets. And continues to loop in such a manner repeatedly.

At the same time. Since reinstalling the mobo drivers after they were corrupted yesterday whilst trying to get a stable overclock, the mobo appears perfectly happy. Similarly when the installers and storage mediums are ported over to my intel laptop they seem fine.

I even discovered a backup file from about 3 days ago which implies there might not be any serious data loss.

I think I may have uncovered the problem, but I’m not too sure how to resolve it given that I think I need to edit either the kernal or the initfsram on my rig to inject something called cpu_microcode. Because one of the few times I have gotten any error messages on screen today it was talking about the following error:

**

‘Speculative Return Stack Overflow: WARNING: Kernal not compiled with CPU_SRSO’

**

I surmise that I may have had this installed within my firmware but when my mobo memory was exorcised after its corruption incident this patch was no longer within the replacement firmware, even though it had the same most recently updated version number (5302, for the B450-F / 5800x cpu combination I use).

My question is really this. Given that I cannot get anything to install, what would be the best way of bootstrapping? It into the qubes installation file? Given I’m not a long term linux user I remain unfamiliar with what the kernal actually is although I do hear of its importance regularly. Similarly initramfs… I can hazard a guess at it’s functionality, but to manipulate it directly feels a little nerveracking despite the fact that my system is, ostensibly, bricked already.

Any advice suggestions you might have l would be gratefully received. Even if that advice is that my system issues seem unlikely to be caused by this problem. Because I really have no idea one way or the other. It’s just the only tangible issue I have thus far found, and not managed to overcome on my own.

amd whitepaper

Wiki on archlinux

github

debian forum stating the microcode comes from kernal repository and lost at shutdown anyway.so how come I’m only now experiencing an issue and why I seem to be thevonly one? Maybe because i was using the test install as of when i last reinstalled on Tuesday? .

Until now I thoughtbit was a storage issue. Perhaps bifurcation related or something in the bios. But I’m really at a loss to know what to think now.

I woke up today intending on leaving this to one side for a bit, after many hours scouring the internet for solutions in the past couple of days I thought perhaps a rest might prove fruitful.

Yet after a short while I found myself wondering whether AMD might have released a driver package not included within the latest Asus driver releas, and while that turned out not to be the case, I did then wonder whether there was another driver on the ASUS suport page that I might have overlooked; a chipset driver package distinct from the general driver utility perhaps. After all, it was only at the very end of many fruitless hours of troubleshooting that it even occurred to me that it might not be the storage issue I had first surmised.

And indeed, as luck would have it, it turns out that there had been a NEW motherboard driver release issued on the ASUS webpage; by my reckoning mere hours after I had downloaeded and installed version 5302, Asus uploaded a new 5404 version.

So I downloaded it and flashed it across to my motherboard and I have just managed to reinstall Ubuntu from one of my ventoy disks. I am hesitant to be too excited, after all, the install is not of Qubes, nor on one of my removed nvme drives but on a seperate SSD drive left in there when I went to bed after failing to overcome the issue this morning.

But given I was unable to get past the bootloader for any OS at all yesterday, this does seem a promising turn of events. And should there be no further replies to this topic you can safely assume that the issue has been entirely resolved!