On 12/1/18 5:24 AM, Carlos E. R. wrote:

On 01/12/2018 11.32, George from the tribe wrote:

...

So I ran the distribution upgrade for tumbleweed, the latest one being as of yesterday, Nov 30.

It will not boot on the current kernel, which is 4.19.4-1. It also will not boot on kernel 4.19.2-1, the last upgrade a week ago, which is when this problem started. I was hoping that the new upgrade, which I did yesterday, would fix the problem, but it didn't.

However, it will boot on kernel 4.18.15-1, and that is what I am on at the moment.

Watching it boot, it hangs at around 30-35 seconds on the following line, right after it says "[  OK  ] Reached target Initrd Root Device.": [**      ]A start job is running for dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device (35s / 1min 30s)

I think that device number is the device number for the initrd, because it does not show up on my device list when I run ls -l /dev/disk/by-uuid.

Can't be. Initrd doesn't have such a thing.

...

[ TIME   ] Timed out waiting for device dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device.

[ DEPEND ] Dependency failed for Resume from hibernation using device /dev/disk/by-uuid/d3224276-28fa-44ad-b96e-cd3d84fd2e6e.

It might be swap.

Maybe your initrd refers to that partition

It's not the swap, according to this: # blkid /dev/sdb7 /dev/sdb7: LABEL="swap" UUID="78e12fe1-1805-475f-bd43-ed40c991fc6e" TYPE="swap" PARTLABEL="swap" PARTUUID="08891476-54b5-4b4f-a3c3-243a6f80b2dc" I don't know if knowing what exactly has that UUID is the key to figuring out why the system hangs on boot at 30seconds in trying to start that device. But that UUID does not match any of my partitions on either my SSD or my regular main HD for this laptop. -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: TW | Plasma 5.13 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: TW | Plasma 5.13 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/1/18 2:24 PM, Andrei Borzenkov wrote:

01.12.2018 22:15, Felix Miata пишет:

...

The following looks like a FAT or NTFS partition:

[** ]A start job is running for dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device (35s / 1min 30s)

FAT or NTFS have entirely different UUIDs.

Yes, but here's the thing. The line items I have pasted up there from the boot log are for the system that IS working and IS booting. So it is impossible that the system is looking for a non-existent file and that becomes the reason for it hanging. In the case of those line items posted from the boot log, the system is actually NOT hanging. Now perhaps the file with that UUID doesn't actually exist, and that is why it times out on the boot sequence for 4.18. But at least with 4.18 it makes it past that and doesn't hang. (Sorry for the CAPS - I am not trying to be unpleasant. Just in the text only version of this email I have no other way to indicate emphasis. I do appreciate everyone trying to help.) However, the system that is hanging at around 35 seconds, which includes both versions of kernel 4.19, the boot process never even makes it to the point where it initializes the boot log and writes those line items into the boot log. The only reason I know that it is the same UUID on the boot sequence that hangs is that I took a photo of it with my cell phone and compared the UUID to the UUID in the boot log for the system that worked. The difference is that whether or not that file exists, when I boot tumbleweed with the 4.19 kernel, it hangs while running the start job for that file/device and never boots up, but with the 4.18 kernel, it times out when looking for that file/device and then proceeds to continue to boot. Again, thanks for everyone's help. I hope we can come up with more insight, because this particular problem seems pretty tough. -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: TW | Plasma 5.13 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: TW | Plasma 5.13 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/12/2018 23.06, George from the tribe wrote:

On 12/1/18 2:24 PM, Andrei Borzenkov wrote:

...

01.12.2018 22:15, Felix Miata пишет:

...

The following looks like a FAT or NTFS partition:

[**      ]A start job is running for dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device

(35s / 1min 30s)

FAT or NTFS have entirely different UUIDs.

So I checked the UUID of all my partitions, even the hidden windows partitions, and none of them match.

tribetrekDellbig:/home/george # cd / tribetrekDellbig:/ # blkid /dev/sda | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sda1 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sda2 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sda3 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sdb | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sdb1 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sdb2 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sdb3 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sdb4 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sdb5 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sdb6 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sdb7 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sdb8 | grep fd2e6e tribetrekDellbig:/ # blkid /dev/sdb9 | grep fd2e6e

all empty

I also tried it on a stick that I have used to install leap on another partition, and its not that one either. Stumped.

I know it doesn't exist, but your boot files *think* that it does, search for it, wait for it, and fail. So, again, look *inside* your initrd file and find that UUID. Then find out who/what writes it. The initrd file is just a (compressed?) cpio archive. You can open it with mc by changing the extension temporarily to cpio. Also look other files in your /boot. Grep them. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 12/2/18 8:21 AM, Felix Miata wrote:

Carlos E. R. composed on 2018-12-02 14:56 (UTC+0100):

...

So, again, look *inside* your initrd file and find that UUID. Then find out who/what writes it.

...

The initrd file is just a (compressed?) cpio archive. You can open it with mc by changing the extension temporarily to cpio.

Or use the lsinitrd command (since 10 years ago[1]) with less or grep.

[1] https://bugzilla.opensuse.org/show_bug.cgi?id=439103#c9

I don't seem to be able to find that uuid, or in fact any uuid in the initrd file: tribetrekDellbig:/boot # lsinitrd | grep disk tribetrekDellbig:/boot # lsinitrd | grep d3224 tribetrekDellbig:/boot # lsinitrd | grep fd2 tribetrekDellbig:/boot # lsinitrd | grep uuid -rwxr-xr-x 1 root root 30840 Nov 14 07:48 usr/lib64/libuuid.so.1.3.0 lrwxrwxrwx 1 root root 16 Dec 1 03:30 usr/lib64/libuuid.so.1 -> libuuid.so.1.3.0 Is there another way to read the initrd file? I did, however find this when running in the 4.18 kernel: # lsinitrd | grep initrd Image: /boot/initrd-4.18.15-1-default: 16M systemd-initrd lrwxrwxrwx 1 root root 25 Dec 1 03:30 etc/initrd-release -> ../usr/lib/initrd-release lrwxrwxrwx 1 root root 14 Dec 1 03:30 etc/os-release -> initrd-release -rwxr-xr-x 1 root root 1275 Nov 6 08:38 lib/dracut/hooks/cmdline/99-parse-suse-initrd.sh -rw-r--r-- 1 root root 167 Dec 1 03:30 usr/lib/initrd-release lrwxrwxrwx 1 root root 14 Dec 1 03:30 usr/lib/os-release -> initrd-release lrwxrwxrwx 1 root root 13 Dec 1 03:30 usr/lib/systemd/system/default.target -> initrd.target -rw-r--r-- 1 root root 674 Nov 20 15:54 usr/lib/systemd/system/initrd-cleanup.service -rw-r--r-- 1 root root 593 Nov 16 04:27 usr/lib/systemd/system/initrd-fs.target -rw-r--r-- 1 root root 842 Nov 20 15:54 usr/lib/systemd/system/initrd-parse-etc.service -rw-r--r-- 1 root root 561 Nov 16 04:27 usr/lib/systemd/system/initrd-root-device.target -rw-r--r-- 1 root root 566 Nov 16 04:27 usr/lib/systemd/system/initrd-root-fs.target -rw-r--r-- 1 root root 593 Nov 20 15:54 usr/lib/systemd/system/initrd-switch-root.service -rw-r--r-- 1 root root 754 Nov 16 04:27 usr/lib/systemd/system/initrd-switch-root.target drwxr-xr-x 2 root root 0 Dec 1 03:30 usr/lib/systemd/system/initrd-switch-root.target.wants lrwxrwxrwx 1 root root 30 Dec 1 03:30 usr/lib/systemd/system/initrd-switch-root.target.wants/haveged-switch-root.service -> ../haveged-switch-root.service lrwxrwxrwx 1 root root 25 Dec 1 03:30 usr/lib/systemd/system/initrd-switch-root.target.wants/plymouth-start.service -> ../plymouth-start.service lrwxrwxrwx 1 root root 31 Dec 1 03:30 usr/lib/systemd/system/initrd-switch-root.target.wants/plymouth-switch-root.service -> ../plymouth-switch-root.service -rw-r--r-- 1 root root 763 Nov 16 04:27 usr/lib/systemd/system/initrd.target drwxr-xr-x 2 root root 0 Dec 1 03:30 usr/lib/systemd/system/initrd.target.wants lrwxrwxrwx 1 root root 29 Dec 1 03:30 usr/lib/systemd/system/initrd.target.wants/dracut-cmdline-ask.service -> ../dracut-cmdline-ask.service lrwxrwxrwx 1 root root 25 Dec 1 03:30 usr/lib/systemd/system/initrd.target.wants/dracut-cmdline.service -> ../dracut-cmdline.service lrwxrwxrwx 1 root root 27 Dec 1 03:30 usr/lib/systemd/system/initrd.target.wants/dracut-initqueue.service -> ../dracut-initqueue.service lrwxrwxrwx 1 root root 23 Dec 1 03:30 usr/lib/systemd/system/initrd.target.wants/dracut-mount.service -> ../dracut-mount.service lrwxrwxrwx 1 root root 27 Dec 1 03:30 usr/lib/systemd/system/initrd.target.wants/dracut-pre-mount.service -> ../dracut-pre-mount.service lrwxrwxrwx 1 root root 27 Dec 1 03:30 usr/lib/systemd/system/initrd.target.wants/dracut-pre-pivot.service -> ../dracut-pre-pivot.service lrwxrwxrwx 1 root root 29 Dec 1 03:30 usr/lib/systemd/system/initrd.target.wants/dracut-pre-trigger.service -> ../dracut-pre-trigger.service lrwxrwxrwx 1 root root 26 Dec 1 03:30 usr/lib/systemd/system/initrd.target.wants/dracut-pre-udev.service -> ../dracut-pre-udev.service -rw-r--r-- 1 root root 708 Nov 20 15:54 usr/lib/systemd/system/initrd-udevadm-cleanup-db.service Does that indicate anything worth looking into? I can't quite make heads or tails of it. -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: TW | Plasma 5.13 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: TW | Plasma 5.13 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 12/2/18 11:16 PM, Felix Miata wrote:

Did you ever try my cmdline suggestions, in particular, noresume?

Thank you for the reminder. I just looked over it, and found this file: /etc/default/grub In that file, there is this line, which is also in the /boot/grub2/grub.cfg file: GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/d3224276-28fa-44ad-b96e-cd3d84fd2e6e splash=silent quiet showopts" Which is the uuid of the file that the system is looking for, which fails with the 4.19 kernels, but times out with the 4.18 kernel. So in your suggestion that I make it a no resume line, how exactly do I specify that? Do I type something like "resume=noresume"? Or do I do something like "resume="? Which makes me think, if the resume line is something about where to resume from hibernation, then how do I make sure this line is set up correctly? Because the uuid of my swap partition is this: # blkid /dev/sdb7 /dev/sdb7: LABEL="swap" UUID="78e12fe1-1805-475f-bd43-ed40c991fc6e" TYPE="swap" PARTLABEL="swap" PARTUUID="08891476-54b5-4b4f-a3c3-243a6f80b2dc" -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: TW | Plasma 5.13 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: TW | Plasma 5.13 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

George from the tribe composed on 2018-12-03 21:43 (UTC-0600):

I have an idea that if I am able to successfully complete Carlos' suggestion and track down the actual file that put that line in /etc/default/grub, then I will be able to set it up to correctly look to my swap.

If the hang has anything to do with swap, commenting or removing the swap line in fstab might avoid the hang. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/12/2018 04.39, George from the tribe wrote:

On 12/2/18 11:16 PM, Felix Miata wrote:

...

Did you ever try my cmdline suggestions, in particular, noresume?

Thank you for the reminder. I just looked over it, and found this file: /etc/default/grub

In that file, there is this line, which is also in the /boot/grub2/grub.cfg file: GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/d3224276-28fa-44ad-b96e-cd3d84fd2e6e splash=silent quiet showopts"

Which is the uuid of the file that the system is looking for, which fails with the 4.19 kernels, but times out with the 4.18 kernel.

I thought you had already looked into that file. No, that file doesn't go into initrd, on the contrary. That file controls how grub is configured and this goes into initrd. There is nothing to seek for, just edit that file correctly now! Just put: GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-uuid/CORRECT_UUID_OF_SWAP splash=silent quiet" which is, you said, "78e12fe1-1805-475f-bd43-ed40c991fc6e". Or: GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/disk/by-label/swap splash=silent quiet" And then do what the first comment in the file says: # If you change this file, run 'grub2-mkconfig -o /boot/grub2/grub.cfg' afterwards to update # /boot/grub2/grub.cfg. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 03/12/2018 06.00, George from the tribe wrote:

On 12/2/18 8:21 AM, Felix Miata wrote:

...

Carlos E. R. composed on 2018-12-02 14:56 (UTC+0100):

...

So, again, look *inside* your initrd file and find that UUID. Then find out who/what writes it.

...

The initrd file is just a (compressed?) cpio archive. You can open it with mc by changing the extension temporarily to cpio.

Or use the lsinitrd command (since 10 years ago[1]) with less or grep.

[1] https://bugzilla.opensuse.org/show_bug.cgi?id=439103#c9

I don't seem to be able to find that uuid, or in fact any uuid in the initrd file: tribetrekDellbig:/boot # lsinitrd | grep disk tribetrekDellbig:/boot # lsinitrd | grep d3224 tribetrekDellbig:/boot # lsinitrd | grep fd2 tribetrekDellbig:/boot # lsinitrd | grep uuid -rwxr-xr-x   1 root     root        30840 Nov 14 07:48 usr/lib64/libuuid.so.1.3.0 lrwxrwxrwx   1 root     root           16 Dec  1 03:30 usr/lib64/libuuid.so.1 -> libuuid.so.1.3.0

Is there another way to read the initrd file?

It is not a file, it is an archive. And I told you: 'mc'. With "lsinitrd" it would be something like: lsinitrd -f * | grep 3224276-2d28fa but it does not work for me, I get xzcat: 20021107.1530.ethereal: File format not recognized Instead, you can do: md test cd test /usr/lib/dracut/skipcpio /boot/initrd-VERSION | xz -cd | cpio -idv which will create a tree of files. Then, I insist that you use 'mc' to find what file contains the string 3224276-2d28fa. Or grep: Telcontar:~/testing # grep -ril ac173013 etc/cmdline.d/95root-dev.conf Telcontar:~/testing # Telcontar:~/testing # cat ./etc/cmdline.d/95root-dev.conf root=UUID=ac173013-18ad-4c4e-921e-fd2ecfb56495 rootfstype=ext4 rootflags=rw,relatime,lazytime,data=ordered You can try "grep", but be warned that I failed: Note: it took me about an hour to find out all this, and I tested the procedure on my computer. So please, do it! -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 03/12/2018 20.22, L A Walsh wrote:

On 12/3/2018 1:51 AM, Carlos E. R. wrote:

...

On 03/12/2018 06.00, George from the tribe wrote:

...

Is there another way to read the initrd file? It is not a file, it is an archive....

---

Have you tried this:

table of contents (I don't remember cpio invocation for ToC)

    star -t

or to extract

mkdir img && cd img &&  gunzip

If you want to create devices, w/cpio, you'll need to be root.

Is that what you were wanting?

That's what I explained, yes. But it is not that trivial, because the cpio part is preceded by a cpu firmware update part, that has to be bypassed first. That's what the "skipcpio" command does. Once you obtain the real tree contained in the archive, the second part is to grep all the files in it to find out which file contains the reference to the wrong uuid. Once this is found, the next step would be finding out why it is created and correct it. I have been saying this since the first message, in less words. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 04/12/2018 04.33, George from the tribe wrote:

On 12/3/18 3:51 AM, Carlos E. R. wrote:

Sorry, I was out all day with work and wasn't able to get to this until now. But I am working on this now. Quick question - from what starting directory do I need to begin? When I type 'md test' it will create that directory. I am not sure where is the optimal place to start and have it created.

It does not matter at all. In you home. Wherever you do your homework. After you solve the problem, you have to destroy it, no longer needed... But you don't need to do any of that, you have already shown your /etc/default/grub to be faulty. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 01/12/2018 20:15, Felix Miata wrote:

...

Evolution as taught in public schools is religion, not science.

Felix, can I please ask you to not put religious quotes in your sig? It is really testing my self-control and good manners. I am sure I am not alone. Even though I never took it as a religious statement, IMNSHO it's not a sig

Op dinsdag 4 december 2018 20:45:36 CET schreef Liam Proven: that should be used here. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org