Hello!

About 3-4 days ago my PC (running FC32+KDE) started failing at boot
with message that it's entering emergency mode and suggesting
to copy "/run/initramfs/rdsosreport.txt" to /boot or USB stick
after I mount them. However, I can't do this as I'm not getting
to a shell: it requests a root password but refuses to accept it
and pressing "CTRL-D" to exit the shell returns with the same
error few seconds later.

The stage in boot process when this error happens is: after entering
the GRUB2 menu stage and selecting one entry, first the PC enters the
graphic mode with white dots on a black background and below
the round "in progress" indicator starts spinning and after few seconds
the PC returns to the text mode with the "emergency mode", etc.

The first time this happened was only a week after I copyed
the contents of the "/boot" and "/" (LVM) to a new disk (again,
thanks for all the help with that) and at first I thought that
something is wrong with the files on the new boot disk (but for
a week it was booting OK). Since
I haven't yet removed the old disk, I rebooted, entered the
Adaptec utility, changed the order of boot disks so that the old
one will return to be bootable, rebooted... and got the same
problem. So I changed back the bootable disk to be the new one
and selected in the GRUB2 menu the "resque" option... and got
the same problem.
At that stage I started suspecting the RAM. I booted from
the FC32 installation DVD, went to the RAM test and it failed
the first test immediately after the first 4GB (the PC has
16 GB, 4 DIMMs 4 GB each, DDR2-800. MB: Asus M3A79T Deluxe
bought in 2009). So I thought, the DIMM is faulty,
powered down the PC, removed the second DIMM, rebooted from
DVD, went to the RAM test and if failed again at exactly
the same address. I also noted that the MB renumbered the
slots to be consequtive. I continued removing one DIMM at a time
and running RAM test - all failed above 4 GB untill only a single
DIMM remained, at which point thr RAM test passed. I removed
the DVD, rebooted...and got the same "emergency mode" problem.
After that I replaced the CPU, the MB (identicals, I have
them spare) - same problem. At that point I replaced the 4 GB
DIMMs with very old 4 * 1GB dimms which were unused for about
10 years and things got even worse - the MB refused to power up.
I replaced the PSU - same, so I went back to the 4GB DIMMs
and now, at least, the MB started to power up. I checked two
different 4GB DIMMs (each time one) - RAM test passes but
attempt to boot normally results in the same "emergency mode".
I don't have another 4GB DIMMs to try (I think that's the only
remaining hardware to try replacing) but before I start searching
for such old DIMMs in computer stores, a though came to me: maybe
it's not hardware at all?
From the moment the GRUB2 menu item is selected and until the
"emergency mode" failure I can see a very brief activation of
the disks LED so it doesn't looks like the PC accesses only the RAM.
When I boot from the DVD and start "Fedora live", I can view the
physical and logival volumes, I can "mount" the "/boot" partition
and the "/" LV of the disk and it seems the files are there.
So, why is the "emergency mode" failure? How can I debug it?

TIA,
kaza.

Does it behave the same if you boot a prior kernel? If it behaves normally, I would start by rebuilding the the possibly bad initramfs, or remove and reinstall that kernel. It could be you have a bad memory controller that caused a bad initramfs to be built, and the live boot process hasn't put the bad spot(s) to work.

Remove from the kernel command line quiet and splash=silent in order to show more boot messages.

I have more faith in memtest86 than I do in memtest86+, particularly with DDR4. The M3A79T Deluxe uses DDR2, so it's pretty old RAM. It could be if all 4 sticks are identical that you've simply got a bunch that have been going bad.

IME, Asus boards of that vintage (e.g. P5B Deluxe, P5B SE) can be pretty picky about the DDR2 RAM used. They also have BIOS option(s) to determine how low memory is utilized. Making a change there could change the behavior experienced.

Thanks mrmazda,

I'll try removing the "quiet" and "splash=silent" when I'll get home (about 12 hours from now, I estimate).

What puzzles me is that for a week since I copied the "/boot" and "/" from one disk to another the PC booted
just fine. When I boot from the live DVD, mount the boot disk and "ls -l" various files,
I see that change date/time of most files is no later than Dec 31 2021 around 20:00 (that's when I copied the "/boot", "/")
but yesterday I saw one file: "grubenv" (pointed by a link with "EFI" in it) having the date of Jan 6 2022, which is about when the boot problems started.
Looking at the contents of that file I saw the "saved_entry" (I hope I remember this correctly, I'm not home now)
has the version of the existing kernels.

What can change this file?

TIA,
kaza.

Booting.

OK, I removed the "quiet" and got few full screens scrolled by very fast then graphic mode starts as I described
initially then back to text mode with the remaining half a screen
visible and dealing mostly with the video card (ATI Fire GL V5600) initialization and after that - "emergency mode"

I've attached the screen image and the whole command.

Is there any way to slow down the display of the various lines of status?

TIA,
kaza.

Attached Thumbnails

   

Try removing the video card. Get a standard VGA card and test it. If it works, it is a driver issue.

I have a spare V5600 card, just tried switching them - same error.

what is in /run/initramfs/rdsosreport.txt

https://www.reddit.com/r/Qubes/comme...o_a_usb_drive/

I can't see the contents of the /run/initramfs/rdsosreport.txt
because I can't get into any shell: I'm in an endless loop of
being prompted for a root password but when I give it
it isn't recognized.
And pressing "CTRL-D" to exit the shell returns with the same error
few seconds later.

TIA,
kaza.

Some more info: I attempted to add "sleep 10" between various
lines of the boot command but always the 10 seconds delay
was before all the fast scrolling of few screens. I managed to see there few green "OK" at the
left side. Had there been a failure, should I see something red scrolling by?

I also attempted to pause the scroll using the "Scroll lock" key or "Pause" key - no effect,
the fast scroll doesn't stop.

As for the possibility of bad initramfs being built: I had about a week of successfull reboots
(the PC is not 24/7), is the initramfs being built at every boot or only once when setting things up
and left unchanged after that?

Also: does the size of the RAM matters to initramfs? When I set the things up (Dec 31 2021) I had
16GB (4 DIMMs) installed but now, after experimenting with the ramtest+ I only has one DIMM installed.

TIA,
kaza.

It might go by too fast to notice. A failure might not be reported fast enough to show before the screen stops showing anything more.

Any number of different package updates can trigger a rebuild of the initramfs. Were there any updates installed after the week of successes?

No.

Did you ever try to boot the prior kernel?

It's been a long time since I was in a Fedora dracut shell. It might contain the less command. If it does, you could peruse or photograph /run/initramfs/rdsosreport.txt using it even if you can't manage to copy it somewhere from which to paste here. You should at least be able to see its tail using the cat command.

During the week of successfull reboots I didn't install any new package.

As I understand, I'm not getting into the dracut shell: I'm endlessly prompted for a root
password but when I give it, it's not accepted.

TIA,
kaza.

That was not my question. Did you do no updates of already installed packages that week?

I cannot claim to have faced the exact same problem but my defective initial ramdisks came from missing space on /var and the fact that I have overlooked the errors upon generation of the ramdisk-image. I do however not understand most of the error-descriptions in this thread, for the time.

Here's my guess, with respect to all.
Back in post #5 you posted a photo asking for root passwd. That tells you

1. The kernel has loaded
2. The initrd has loaded
3. Some error occurred during the kernel boot.

So it threw you into a busybox shell stored in the initrd and asked for the root password, which it could verify if root was mounted read only. So what might be going on is that it has an issue with the / filesystem. Your standard boot line is going wrong in the second half, 'root=/dev/sdX ro'. Further, /dev/sdX must be correct, or it would throw a different error.

Get the root filesystem checked somehow.

1 members found this post helpful.