I recently an install of Nobara Linux and there seems to be an issue during boot. Sometimes it fails to boot correctly and the screen looks glitchy with random noise and colors with no obvious way to move past it, forcing a manual shutdown via the power button (a couple times it seems to have failed complete and the system automatically booted in Windows 10). When this doesn’t happen, Nobara appears to boot normally and have no issues once I reach the login screen.
I only have a few weeks of experience with Linux with Linux Mint. I did not encounter any boot problems with Mint so I don’t think there are any hardware issues. I suspect I must have made an error somewhere with the Nobara installation or with how I set up the partitions. I tried to follow with advice I found online, but maybe the info was incomplete or out of date.
I installed Nobara-39-Official-2024-01-24 and finished running all system and driver updates.
Nobara Partition setup:
• /boot/efi = 600 MB, FAT32, flags: boot & bios-grub
• /boot = 1 GB, EXT4
• / = 50 GB, EXT4
• / home = 110 GB, EXT4
• no mount (label: games) = remaining SSD space ~273GB, EXT4
The remaining portion of my 1TB SSD is dual boot Windows 10.
If anyone could diagnose this, it would be a great help.
Check your memory. Also, if you’re seeing graphical glitches, check to see if the machine actually did boot still by pinging or sshing’ in. Could be a bad graphics card.
If you do get a clean boot, check dmesg and syslogs to find any potential errors that are happening in the background.
It seems that your boot partition is ext4, not sure about that
I wonder if this is because you decided to go with ext4 instead of btrfs, since Fedora based systems use btrfs out of the box. Logically it shouldn’t matter since both are Linux file systems, just putting a “what if” here.
I would test RAMs though, seems like a RAM issue.
Why do you have a /boot as EXT4 and a /boot/efi as FAT32 ?
I would have installed it with only a 500MB /boot as a FAT32 partition. There is no need to mount a partition in another one.
Next time it does that, run the “journalctl | tee journalctloutput.txt “command and see if it has lines from before the boot. If it does, paste the output of the lines from that boot to see when and how it’s failing or succeeding.
