[opensuse] tumbleweed fails to boot hangs on initrd
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. On either of the first 2 kernels, it hangs there and will not get past that line. It actually does not even create a boot log for the attempted boot, and there is seemingly no way to get around it. The boot log for booting into kernel 4.18.15 shows this around the time it is working with that device: ------------ Sat Dec 01 03:44:57 CST 2018 ------------ 6e\x2dcd3d84fd2e6e.device (12s / 1min 30s) [** ] A start job is running for dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device (13s / 1min 30s) [** ] A start job is running for dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device (13s / 1min 30s) [** ] A start job is running for dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device (14s / 1min 30s) [** ] A start job is running for dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device (15s / 1min 30s) < the start job line is repeated many times with new time stamps as time passes > [** ] A start job is running for dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device (1min 29s / 1min 30s) [** ] A start job is running for dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device (1min 29s / 1min 30s) [** ] A start job is running for dev-disk-by\x2duuid-d3224276\x2d28fa\x2d44ad\x2db96e\x2dcd3d84fd2e6e.device (1min 30s / 1min 30s) [ 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. [ OK ] Reached target Local File Systems (Pre). [ OK ] Reached target Local File Systems. [ OK ] Reached target System Initialization. [ OK ] Reached target Basic System. < then the log continues on normally through into completing the boot cycle > So, what exactly is the problem here? I was assuming it was the initrd, so I ran mkinitrd again, and rebooted, but it did not fix the problem. For now I have added a lock on kernel packages so that on my next upgrade I won't push out my one working kernel with tumbleweed. But other than that, I don't know what to do next. Any ideas? -- 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 5:24 AM, Carlos E. R. wrote:
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
Try editing the grub kernel line: root=UUID=<foo> --> root=/dev/disk/by-label/<bar> splash=silent --> resume=UUID=<baz> --> noresume 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) Do you have any Windows partitions or an ESP partition in fstab? -- 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 12/1/18 2:24 PM, Andrei Borzenkov wrote:
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 12/1/18 2:24 PM, Andrei Borzenkov wrote:
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. -- 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:
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)
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 -- 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 12/2/18 8:21 AM, Felix Miata wrote:
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
Did you ever try my cmdline suggestions, in particular, noresume? -- 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 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
On 12/3/18 9:39 PM, George from the tribe wrote:
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. -- 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):
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
George from the tribe composed on 2018-12-03 21:39 (UTC-0600):
This is a test to see if resume is associated with hanging, by telling the kernel and systemd not to attempt to resume. Edit the kernel line at the grub menu. Prepend no to resume=. Remove everything appended to resume=, and for good measure to better see what follows, remove everything else on that line. showopts does absolutely nothing anyway. splash=silent and quiet might hide possible clues to what causes hanging. -- 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:
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 12/4/18 3:30 AM, Carlos E. R. wrote:
On 04/12/2018 04.39, George from the tribe wrote:
On 12/2/18 11:16 PM, Felix Miata wrote:
You guys are awesome! I did that and booted up, and the system no longer has a delay on any of my kernels. So having the wrong uuid for the resume swap file was one of the problems. Unfortunately, it was not the whole problem. It was only masking a deeper problem. My system is still locking up with either of the 4.19 kernels. The difference is now, if I boot into runlevel 3, it is fast and I can actually log in. After that, I have about 35 seconds of time logged in (not enough time to do it in the graphical environment), and then my system locks up again and I can't do anything. I can boot all the way into the graphical environment if I choose kernel 4.18. Sooooo... it is late right now and I need to get some rest. Tomorrow I will start a new thread to try and troubleshoot what the problem is that is locking up my system using kernel 4.19. I have an idea it has something to do with the video driver and the amdgpu, but I can't get to it tonight. BTW, just a really big thanks to everyone... I have a ton of things going on in life right now, including a shift in focus in my career (not really a career change, but big enough to be like that) while taking care of an elderly parent and putting a kid in college, among some medical issues... just a lot of life happening. So to have people willing to help when these sorts of things come up on my pc (which is the primary tool used in so many things), well, it really makes a difference. This is a great community to be a part of. -- 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 03/12/2018 06.00, George from the tribe wrote:
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 12/3/2018 1:51 AM, Carlos E. R. wrote:
Have you tried this: table of contents (I don't remember cpio invocation for ToC) star -t <initrd.img or to extract mkdir img && cd img && gunzip <initrd.img |cpio -i If you want to create devices, w/cpio, you'll need to be root. Is that what you were wanting? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/12/2018 20.22, L A Walsh wrote:
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 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. -- 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 04/12/2018 04.33, George from the tribe wrote:
On 12/3/18 3:51 AM, Carlos E. R. wrote:
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. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Did you try editing the grub kernel line? root=UUID=<foo> --> root=/dev/disk/by-label/<bar> splash=silent --> resume=UUID=<baz> --> noresume -- 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 12/1/18 5:24 AM, Carlos E. R. wrote:
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
Try editing the grub kernel line: root=UUID=<foo> --> root=/dev/disk/by-label/<bar> splash=silent --> resume=UUID=<baz> --> noresume 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) Do you have any Windows partitions or an ESP partition in fstab? -- 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 12/1/18 2:24 PM, Andrei Borzenkov wrote:
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
participants (7)
-
Andrei Borzenkov -
Carlos E. R. -
Felix Miata -
George from the tribe -
Knurpht-openSUSE -
L A Walsh -
Liam Proven