Boots into emergency mode leap 15.3; acpi issue

First of all I am on Leap 15.3. There is no tag for that rev.

I was going to run Clonezilla which may have created the problem. I had the iso on a sd card in a reader and a usb hd that was not bootable, However the system went into 15.3 anyway. I can see all the files in emergency mode so I am not totally freaked, just partially freaked! For instance I could find my forum password. I am on the windows partition at the moment on a dual boot system,

I ran the journalctl -xb. The last 200 lines are relevant but I don’t know how to save them to a place where windows can see the data otherwise I would post it.

The first “red” text that is new reads:
acpi PNP0C14:01 duplicate WMI GUID {long number} (first instance was used on PNP0C14:00PNP0C14:01
The line is repeated four times for PNP0C14:01 PNP0C14:02 PNP0C14:03
PNP0C14:04

Suggestions?

15.3 is EOL and no longer supported.

Sorry, but it’s rather unclear what you actually did… Perhaps elaborate in more detail.

That may be a red herring, see:
https://bugzilla.kernel.org/show_bug.cgi?id=201885

It does not mean everyone suddenly stops using it and asking questions.

1 Like

Technically false before Sunday:
https://lists.opensuse.org/archives/list/announce@lists.opensuse.org/thread/OCJDZIP63AUG4TW4W5JKR6TVWZ6N2TMT/
https://en.opensuse.org/Lifetime

This is all clear as mud. Where is Clonezilla? Did you copy its .iso to a USB filesystem? Did you burn the .iso to a USB device? Did you start it from a 15.3 boot? From a USB boot?

Do you have 15.3 installed on a PC or laptop? Under what conditions does something boot to emergency mode? A USB stick boot? An internal storage boot? When you have bootable USB devices connected? Plug USB devices in after booting internal storage if they are causing boot trouble.

If you mount a FAT formatted USB device or HDD or SSD filesystem you can redirect command output to a file on it for Windows to read.

No (and tannington is trying to answer), but it does not harm to remember people that they are skating on ice that gets thinner and thinner.

Of course… but that wasn’t what I said, was it?

Well, what’s 24 hours in the great scheme of things…

In recent years I’ve see numerous updates arrive on the mirrors two or more weeks following the last month of official Leap support. Besides, we here constitute unofficial support. :slight_smile:

You replied to “there was no tag for Leap 15.3” with “Leap 15.3 is out of support” which sounded like “you are not expected to ask questions about Leap 15.3 so no tag is needed”. Tag is still missing :slight_smile:

1 Like

To me it sounds like “there is no tag because it is out of support”. Just an explanation. Which is acknowledged by the fact that tannington tries to give support and nowhere gives the impression that that is something he thinks it should not be done.

The error message is new. It was hard not to miss because it causes a 90 second delay when booting.

Well it was 3AM local time and I was screaming at the windows nags that kept interrupting me. I rarely use the windows boot except to flash certain devices that need windows.

I put Clonezilla on a sd card using Opensuse Imagewriter. I have done this on thumbdrives in the past. I don’t think using a SD card reader in the loop makes a difference.

I know how to image drives. You boot off of Clonezilla or similar. I have done this for years. The Lenovo t495 I cam using should be set up to boot off of USB but I suspect when I ran windows updates the Lenovo updates snuck in as well. It probably changed my bios. So the goal was a USB boot but in practice 15.3 was booted with the SD card and an external HD connected. The external HD was not bootable.

Now at this point I can boot into 15.3 emergency mode. So I attached the SD card reader with another SD in it to with the goal of dumping the last 200 lines of the journalctl -xb output. However I don’t know how to mount the external drive.

Obviously the goal here is to backup before updating. I was having internet connectivity issues which I have now fixed which is why I delayed the update.

  1. Boot without it connected.
  2. dmesg -w
  3. plug it in
  4. note device name(s) kernel gives it
  5. select an appropriate filesystem for copying to and mount it using mount command, e.g. mount -t auto /dev/sdf6 /mnt

If you can’t tell from dmesg output which filesystem to pick, use lsblk -o NAME,FSTYPE,LABEL to get a nice list, or lsblk -f to get extra detail.

Did you try booting a bit farther than emergency mode, such as using the default Grub stanza with nomodeset appended to the linu line, or with nomodeset 3 appended, and/or with the resume= parameter removed? If any of these work, you should have network and can use susepaste for data sharing, as well as possibly narrowing down the problem.

The file exceeds the character limit. Apologies in advance for the ads and cookies on pastebin.

This is the last boot.

pastebin

How about answering comment #14?

First serious message in the log portion provided is:

Subject: A start job for unit dev-disk-by\x2duuid-4CFE\x2dD97E.device has failed

Does 4CFE-D97E match anything in /etc/fstab? If it matches the ESP mount on /boot/efi/, something pretty fundamental has gone wrong, such as an absent nvme driver. Can you boot a prior kernel normally?

Catching cat /etc/fstab output and/or lsblk -o NAME,FSTYPE,LABEL,UUID,FSAVAIL for paste here could be helpful. Errors regarding USB devices shouldn’t help with getting the installed system working correctly.

It’s impossible to guess the importance of what was not uploaded. What was imposing a character limit? Susepaste.org to my knowledge doesn’t have any such limitation on plain text sent via susepaste command, or pasted directly. If the output is truly gargantuan, grep ailed from it and upload that result.

Yes, I see it could be construed in that manner, although that was not my intention. Apologies to the OP if they also interpreted my comment in that manner.

Nonetheless I still don’t believe that warning message is relevant to your issue, (see the bug report I linked to), also I suspect it’s not a “new” message, if you’re able to access the journal for previous working boots I feel sure you’ll find it there also.

Those can be avoided by using https://paste.opensuse.org/

I think we are getting somewhere now. Here is /etc/fstab. It seems to have a sda entry when the only usb device attached is the sdb1 device. I included the commented out sda device for completeness. You could have beat me with a rubber hose and I would have sworn I never tried to run Kali live.

UUID=ebaab11a-7a1a-43b6-b860-c4409ee032fd  /                         ext4  acl,user_xattr               0  1
UUID=5C13-813E                             /boot/efi                 vfat  defaults                     0  0
UUID=092af4f3-2a54-4de4-851c-706a6e635897  /home                     ext4  data=ordered,acl,user_xattr  0  2
UUID=611b9e33-764b-4935-b0d6-1e2da8df74eb  swap                      swap  defaults                     0  0
UUID=4CFE-D97E                             /run/media/mrg/A73D-17C0  vfat  utf8                         0  0
#/dev/sda1                                  /run/media/mrg/Kali\040Live  vfat  iocharset=utf8               0  0

So is the plan to comment out or delete the 4CFE-D9&e
I forgot to check /boot/efi and will do a second reply.

Here is the lsblk output.

NAME        FSTYPE LABEL   UUID                                 FSAVAIL
sdb                                                             
└─sdb1      vfat           9016-4EF8                              29.5G
nvme0n1                                                         
├─nvme0n1p1 vfat   SYSTEM  5C13-813E                               224M
├─nvme0n1p2                                                     
├─nvme0n1p3 ntfs   Windows 30E216C1E2168AEC                     
├─nvme0n1p4 ntfs           42FA98D8FA98C995                     
├─nvme0n1p5                                                     
├─nvme0n1p6 ext4           ebaab11a-7a1a-43b6-b860-c4409ee032fd   18.2G
├─nvme0n1p7 ext4           092af4f3-2a54-4de4-851c-706a6e635897  103.2G
└─nvme0n1p8 swap           611b9e33-764b-4935-b0d6-1e2da8df74eb 

The answer is no. This would be a research project that I am willing to do but I think the getting rid of the entry in fstab will fix the problem. Here it is repeated:

UUID=ebaab11a-7a1a-43b6-b860-c4409ee032fd  /                         ext4  acl,user_xattr               0  1
UUID=5C13-813E                             /boot/efi                 vfat  defaults                     0  0
UUID=092af4f3-2a54-4de4-851c-706a6e635897  /home                     ext4  data=ordered,acl,user_xattr  0  2
UUID=611b9e33-764b-4935-b0d6-1e2da8df74eb  swap                      swap  defaults                     0  0
UUID=4CFE-D97E                             /run/media/mrg/A73D-17C0  vfat  utf8                         0  0
#/dev/sda1                                  /run/media/mrg/Kali\040Live  vfat  iocharset=utf8               0  0

The /boot/efi directory structure has a lot of files and I am not sure which file you want.