BIOS problem . System stops booting

As said in the title , there is a bios problem

I must have done something by accident

anyway the error msg

i can’t run "/run/initramfs/…

"journalctl " is endless

any idea … please :worried:

You don’t run the /run/initramfs/... as a command, it’s a text file that logs what happened. The suggestion is to copy it to an external storage device so you can share it for diagnosis.

If you have an external storage device mounted, you can pipe the output of journalctl to that as well.

How do i initiate the shell ?

commands not known.

thanks

Enter your root password to start the shell.

Beyond that, what commands are you entering?

…yes , done that got the files ready to move to usb-stick

but

fdisk and lsblkl does not work , or better

how do i mount Usb ?

what are the commands ?

thanks

Try lsscsi. If it doesn’t work, share what the specific error message is.

What you should see is something like this:

In this case, I don’t have a device connected to the VM, but if I did it might show that it’s connected at /dev/sde. You then should be able to run fdisk -l /dev/sde.

Then you’ll see the partitions on the device. Use mount /dev/sde1 /mnt to mount it. Then copy the indicated file (/run/initramfs/rdsosreport.txt) to /mnt, and if you want to copy the output from journalctl, just redirect by appending > /mnt/journal.txt.

Then umount /mnt and you can safely remove the device.

If the commands don’t work, don’t say “it didn’t work” - provide the error message for further diagnosis. We can’t see what you’re seeing, so the more detail you can provide, the better.

…for eg fdisk , lsscsi the msg is

:/# lsscsi
sh: lsscsi: command not found
:/#

eg. cat, ls, mv is working …but dir => command not found

If the prompt doesn’t show the hostname, then you’re probably only seeing the internal commands in the shell.

Do you see any output from mount? If it also returns a command not found error, then let’s see the output from cat /proc/mounts. A picture is sufficient since the device isn’t on the network.

A separate image of cat /proc/partitions might also be useful.

I don’t expect that this is actually a BIOS error - the messages you see are related to the video and high definition audio devices, and are basically just a “this device already exists” message. That is not likely to prevent the system from booting - I would guess those messages have been there all along, but you never saw them because they scrolled off the screen quickly.

If you just cat /run/initramfs/rdsosreport.txt, what’s shown on the screen? (Again, a picture is fine, though we may miss earlier messages, but it’s probable that what we need to know is towards the end of the file).


cat /proc/partitions


what I found in rdsosreport => btrfs error

re Vga in rdsosreport

and journalctl

both files are rather large. I picked what I found noticeable

thanks

Yeah, the ACPI VGA messages are nothing to be concerned about. The btrfs error is the cause of your problem here. As I noted before, this isn’t a BIOS issue. Yes, you noted what you’re seeing is “during bootup”, but it probably happened before this issue and you never saw it because it’s at the very start of what’s shown on the screen, and during kernel startup, those messages scroll pretty quickly.

There is a problem with the partition on nvme0n1p7 (which you can see shows a Failed to mount /sysroot message, which is consistent with not being able to run standard utilities in single-user mode.

You’ll need to grab a rescue ISO image and write that to a USB drive (possibly using someone else’s computer if you don’t have one), boot that, and then see if you can repair the filesystem on nvme0n1p7.

hmmm … ok, I boot up with a rescue system. done that
Even yast is available
what am I looking for ? How do I repair a file system ?

I found one partition 100% full . Its not the btrfs partition

/dev/sdc2 …/run/initramfs/live 100% full
as far as I can see it is a Riad1 partition

I am out of my depth :worried:

The live filesystem should be 100% full - it’s in memory and is the rescue system.

Let’s start with basic info: lsscsi output so we can verify seeing the device.

misinterpretation , please disregard

lsscsi

df

cat /proc/mounts

cat /proc/partitions

cheers

OK, it’s still being identified as nvme0n1p7. None of the internal drive partitions should be mounted, so you wouldn’t see anything useful with df or the other commands.

This is a nondestructive command, should give us some idea as to what’s going on.

btrfs check /dev/nvme0n1p7

This isn’t going to fix anything, but it should give output (probably a bit, I’m guessing) indicating there are structural issues.

Do you know if your system’s /home is on its own partition? The reason I’m asking is that the worst case scenario is that it isn’t and the partition is unrecoverable. Otherwise, if the repair doesn’t work, you should be able to reinstall the system, but you’ll need to take care not to overwrite anything other than the root partition. If it reformats your /home partition, then you will lose your personal files.

If you run fdisk -l /dev/nvme0n1, that will give us an idea what the partition table looks like, and that would be helpful information.

YES ! has its own partition

btrfs check /dev/nvme0n1p7

fdisk -l /dev/nvme0n1
no it is …n1p7 …n1 is comming or I guess you meant …n1p7 ?

I get it anyway

here it is

Interesting, the btrfs check didn’t show any issues, though it didn’t verify the data (step 6/8).

Before we look at repairing it, let’s make sure the hardware isn’t failing. Try running:

smartctl -a /dev/nvme0n1

For the fdisk command (as well as the above smartctl command), I meant what I wrote. nvme0n1p7 is a partition identifier, and nvme0n1 is the device name, which is where the partition table lives.

It’s good news that your home is separate.

reply
-bash: smartctl : command not found

typo ?

No, not a typo. It must not be installed in the rescue image you’re using.

You can try running this filesystem check (still not using any options that will make changes) - this will probably take a while:

btrfs check --check-data-csum /dev/nvme0n1p7

This will check the block checksums for the filesystem. Because we’re not running in repair mode (and I would not do that just yet), this won’t attempt to fix anything, but will give us an idea as to how much of the data is potentially corrupted.

zypper install smartmontools

will give you “smartctl”

btrfs check --check-data-csum /dev/nvme0n1p7

…a bit later

The good news is that the drive doesn’t appear to be reporting hardware issues.

What happens if you try:

mount /dev/nvme0n1p7 /mnt

If that works, before rebooting, make sure you run umount /mnt (it should unmount cleanly anyways, but I usually do that anyways just to be sure when working in a rescue system).

We should see the same error that you see on boot.

1 Like