Cassini Nova Live Disk fails to boot with Nvidia drivers on an older AMD Ryzen system with the following error: error preparing initrd: device error

Hi all,

So some time in the second half of last year, I acquired 2x Nvidia RTX 3090s (will be relevant to the problem I’m now facing). I was dualbooting Windows 10 and Arch Linux. First, Arch Linux had some booting issues which I posted about before and arch-chrooting in via a Live Disk and running yay -Syu to run mkinitcpio with a new kernel update fixed the situation. Unfortunately, not too long afterwards, I believe an Nvidia driver update nerfed my Windows 10 boot. I tried to create and use a recovery USB and it ended up wiping the EndeavourOS installation instead of my Windows 10 installation. Still shaking my head.

Anyways, so I decided to download the newest EndeavourOS live disk. By this time, you all had switched to the systemmd boot system instead of Grub (I guess because the bug last year that affected me), and for whatever reason both the Cassini Neo and Cassini Nova Live Disks fail to boot regardless of the option I select.

Selecting EndeavourOS x86_64 UEFI Default or EndeavourOS x86_64 Fallback (nomodeset) both return to my EFI boot menu.

Selecting EndeavourOS x86_64 UEFI NVIDIA (latest cards only) gives me the red error:

error preparing initrd: device error

Even though I’m running a Ryzen 2950X CPU on an ASRock Taichi x399 motherboard, I even tried editing this option to include the correction suggested here: Latest Nvidia Cards do not boot Installer LiveISO . I got to that page from the information from the latest release web page: https://endeavouros.com/latest-release/

Anyways, I get this error with both Cassini Live Disks.

I’ve had Artemis Neo and Artemis Nova Live Disks work in the past on this system before and after installing the 2x rtx 3090s (using the NVidia drivers), which I used to arch chroot the fixes to the Grub bug and the other booting error I had posted about earlier. There have been a lot of updates since both systems, and I’m worried about installing from them and then trying to upgrade. I haven’t tried the Artemis Live Disks since the Windows Recovery wiped my EOS install, however.

To see if the Windows Recovery installation had messed up my system more than I thought, I downloaded the Garuda Linux Dragonized Edition Live Disk (03/19/23) and tried to boot into it. The option that had me loading NVidia drivers stalled at a point mentioned by someone else here: https://forum.garudalinux.org/t/install-stuck-after-livemedia-keyring-setup/27458 but selecting the free drivers and the Live Disk booted up properly.

So I was hoping to get some help on figuring out what’s going on with the failure to boot into the Cassini Live Disks.

Btw, I’m a bit old school, and I burn these Live Disks onto blank DVDs instead of bootable USB drives.

As to other info (I designed this system to do a mix of bioinformatics/data science work and the occasional gaming), I have 4x 32 GB memory modules running in quad channel mode at DDR4-3200 settings. I have SMT enabled. TPM is disabled (secure boot is disabled), and SVM is enabled. IOMMU is enabled. For PCIe settings, I have Resizeable bar enabled, and SR-IOV is disabled.

Unfortunately selecting any of the options fails to return anything verbose, so I’m reaching out for help on here again.

this looks more like an issue with the dvd or drive ?
There is always a newer ISO rebuild here:

this includes Nvidia 530 version so will not need the ibt=off anymore.
The ISO itself should boot burned to DVD i do testing this before releases.

3 Likes

Is there anyway to troubleshoot this further by making it more verbose? I suppose I can mess with flashing the image onto a bootable USB drive. I’m not having any error though with the Garuda Linux Live Disk. By the way, I always verify the disks after burning them, and I haven’t received any errors.

Do you think it has anything to do the systemd-boot process vs. whatever bootloading process the Artemis live disks use (GRUB I assume)?

Anyways, I’m going to try the newest ISO on both DVD and USB and report back. Thanks for the help so far, joekamprad.

By the way, while I have you, I’ve kinda had an idea mulling around of a way to make funding the developers of the Linux Desktop stack (including the EndeavourOS team) easier by mixing the PBS/NPR/local public radio and tv station model of community funding via the Open Collective (please excuse my American bias) with the Humble Bundle model of being able to choose how you allocate the funding along the stack. As a sort of prototype, I wanted to write a script that mined one’s pacman database at /var/lib/pacman/ and the various packages associated git repositories to kinda give the user and an organization like Open Collective a list of developers that need to be supported. I figure tracking the github could give you an idea of the amount of continued work that’s happening on a project, and one of the suggested allocation methods could based on how active the project is. Another suggested way could be crowdsourced/crowd voted (so allocation based on community expertise). Another could be OS developers (like the EndeavourOS team) suggested allocation. And like in Humble Bundle, the user could decide between a custom allocation and the various suggested ones. And I figure an organization like Open Collective could pull in the developers to participate and reduce the number of transaction fees once enough users participated. Anyways, would the EndeavourOS team be interested in my building a prototype of what I’m talking about and/or developing the idea further, and if so, where on the forum would be an appropriate spot to discuss it? The goal on my part would be to build a prototype of how this might work, get EndeavourOS and Open Collective (or another organization) talking, and then let the powers that be and that know better take it over and make it happen at scale.

You were right. I burnt it to the DVD using the native Windows application and I flashed it to USB using Rufus as suggested in the link in the latest releases page The DVD didn’t work, but the USB did. I’ll try to see if I can use one of the suggested methods to burn it to DVD at a later time and see if that makes a difference, or if there’s something weird with my ancient DVD disks or my DVD drive. Thank you, Joe!

Let me know your thoughts on my idea/suggestion. I think Linux Desktop user should support not only the people who work on putting together the OS like you guys do, but also the entire stack, like Arch Linux, pacman, KDE Plasma (or GNOME) and its various set of software, the individual packages on AUR (and the people who maintain the packages on AUR). I think if we make funding the entire stack both easy and privacy protecting and make more of a push to get more of the community to buy into this, developers of the Linux Desktop can spend more time on it and make it even better than it already is. The allure for the user who can afford it should be having an open source stack that’s community driven and supported rather than having a desktop that costs the user no money.

after your post i was curious and bought a spindle of dvd+RW burned the ISO and use it for a test install without issues… only see it is very slow on loading apps and stuff when using the livesession…
And to complete the test cycle… burned one from windows one with brasero and one with k3b under linux… plus one using no gui burner and instead raw copy the file using growisofs all working the same.

just came back from some work and wanted to share this… i will came back on you later…

I got the install to work, so I’ll try using k3b to burn the live disk onto my ancient DVD-Rs and report back.

I’m back in business!

1 Like

skcll

skcll

1m

I burnt the image to one of my ancient DVD-Rs using K3b, making sure that I requested that the burnt disk be verified. It burnt successfully and the verification came back as successful. I tried both my DVD drive and my Blu-ray drive (which I had used to burn the disk), and they both loaded up the boot menu. When I selected the Nvidia option, I got the same old error that I originally reported, whichever drive I used. I’ve never had this problem before with either the Artemis Live Disks, a recent GParted Live Disk, or this weeks Garuda Linux Live disk.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.