PDA

View Full Version : SLES 12 SP1 dracut-initqueue[291]: Warning: Could not boot.



mikenash
06-Jan-2017, 16:27
Update SLES 12 to SLES SP1

dracut-initqueue[291]: Warning: Could not boot.
[ OK ] Started Show Plymouth Boot Screen.
[ OK ] Reached target Paths.
[ OK ] Reached target Basic System.
dracut-initqueue[291]: Warning: Could not boot.
dracut-initqueue[291]: Warning: /dev/disk/by-path/ccw-0.0.3120-part1 does not exist
dracut-initqueue[291]: Warning: /dev/disk/by-uuid/30f85989-86ac-474d-b696-1d6689da5832 does not exist
dracut-initqueue[291]: Warning: /dev/disk/by-uuid/431a0543-dc6b-4b92-8688-6f9087affd65 does not exist
dracut-initqueue[291]: Warning: /dev/disk/by-uuid/b273239f-1943-4607-ad44-2e007624ee1b does not exist
Starting Dracut Emergency Shell...
Warning: /dev/disk/by-path/ccw-0.0.3120-part1 does not exist
Warning: /dev/disk/by-uuid/30f85989-86ac-474d-b696-1d6689da5832 does not exist
Warning: /dev/disk/by-uuid/431a0543-dc6b-4b92-8688-6f9087affd65 does not exist
Warning: /dev/disk/by-uuid/b273239f-1943-4607-ad44-2e007624ee1b does not exist
Warning: Boot has failed. To debug this issue add "rd.shell rd.debug" to the kernel command line.
dracut-initqueue[291]: Job for dracut-emergency.service failed. See "systemctl status dracut-emergency.service" and "journalctl -xn"
for details.
dracut-initqueue[291]: Warning: Not all disks have been found.
dracut-initqueue[291]: Warning: You might want to regenerate your initramfs.
I am able to boot on the previous kernel.

I issued: dracut --regenerate-all -f && grub2-mkconfig -o /boot/grub2/grub.cfg
I receive the same results.
filesystems are using "btfs"
ccw-0.0.3120-part1 is ext2.

ab
06-Jan-2017, 16:52
If you boot to your previous kernel (which you indicated works) and check
your disk space for things like /boot and the root (/) filesystem, do you
have a fair bit (GiBs, not MiBs) free/available? Also, are your initrd
files similar sizes? What you describe seems odd to me but if you have a
bad/missing initrd for the newer kernel, or if you did not get all of the
new kernel modules installed (usually for space reasons) then it would
explain a fair bit.


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

mikenash
06-Jan-2017, 17:07
Thank you ab for your reply. The disk space looks good and the file sizes appear to be alright.

linux33:~ # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/dasda3 5.8G 4.3G 1005M 82% /
devtmpfs 439M 0 439M 0% /dev
tmpfs 446M 0 446M 0% /dev/shm
tmpfs 446M 7.0M 439M 2% /run
tmpfs 446M 0 446M 0% /sys/fs/cgroup
/dev/dasda1 194M 47M 138M 26% /boot/zipl
/dev/dasda3 5.8G 4.3G 1005M 82% /var/tmp
/dev/dasda3 5.8G 4.3G 1005M 82% /var/spool
/dev/dasda3 5.8G 4.3G 1005M 82% /var/opt
/dev/dasda3 5.8G 4.3G 1005M 82% /var/lib/pgsql
/dev/dasda3 5.8G 4.3G 1005M 82% /var/lib/named
/dev/dasda3 5.8G 4.3G 1005M 82% /var/crash
/dev/dasda3 5.8G 4.3G 1005M 82% /var/lib/mailman
/dev/dasda3 5.8G 4.3G 1005M 82% /usr/local
/dev/dasda3 5.8G 4.3G 1005M 82% /tmp
/dev/dasda3 5.8G 4.3G 1005M 82% /srv
/dev/dasda3 5.8G 4.3G 1005M 82% /opt
/dev/dasda3 5.8G 4.3G 1005M 82% /home
/dev/dasda3 5.8G 4.3G 1005M 82% /boot/grub2/s390x-emu
/dev/dasda3 5.8G 4.3G 1005M 82% /var/log

linux33:/boot # ls -l
total 110548
-rw-r--r-- 1 root root 65 Oct 8 2014 .image-3.12.28-4-default.hmac
-rw-r--r-- 1 root root 65 Dec 2 05:11 .image-3.12.67-60.64.21-default.hmac
-rw-r--r-- 1 root root 65 Dec 9 10:45 .image-3.12.67-60.64.24-default.hmac
-rw-r--r-- 1 root root 1883851 Oct 8 2014 System.map-3.12.28-4-default
-rw-r--r-- 1 root root 1918455 Dec 2 05:09 System.map-3.12.67-60.64.21-default
-rw-r--r-- 1 root root 1918455 Dec 9 10:44 System.map-3.12.67-60.64.24-default
-rw-r--r-- 1 root root 512 Dec 19 2014 backup_mbr
-rw-r--r-- 1 root root 1484 Sep 26 2014 boot.readme
-rw-r--r-- 1 root root 54916 Oct 8 2014 config-3.12.28-4-default
-rw-r--r-- 1 root root 56204 Dec 2 04:52 config-3.12.67-60.64.21-default
-rw-r--r-- 1 root root 56204 Dec 9 10:29 config-3.12.67-60.64.24-default
drwxr-xr-x 1 root root 0 Sep 1 10:20 dracut
drwxr-xr-x 1 root root 118 Jan 6 09:33 grub2
lrwxrwxrwx 1 root root 30 Jan 4 14:48 image -> image-3.12.67-60.64.21-default
-rw-r--r-- 1 root root 10770432 Oct 8 2014 image-3.12.28-4-default
-rw-r--r-- 1 root root 10278656 Dec 2 05:09 image-3.12.67-60.64.21-default
-rw-r--r-- 1 root root 10278656 Dec 9 10:44 image-3.12.67-60.64.24-default
lrwxrwxrwx 1 root root 31 Jan 4 14:48 initrd -> initrd-3.12.67-60.64.21-default
-rw------- 1 root root 13299872 Jan 6 09:28 initrd-3.12.28-4-default
-rw------- 1 root root 10962800 Jan 4 14:48 initrd-3.12.28-4-default-kdump
-rw------- 1 root root 13337140 Jan 6 09:28 initrd-3.12.67-60.64.21-default
-rw------- 1 root root 10999496 Jan 5 16:43 initrd-3.12.67-60.64.21-default-kdump
-rw------- 1 root root 13244032 Jan 6 09:28 initrd-3.12.67-60.64.24-default
-rw-r--r-- 1 root root 351874 Dec 9 10:45 symtypes-3.12.67-60.64.24-default.gz
-rw-r--r-- 1 root root 122263 Oct 8 2014 symvers-3.12.28-4-default.gz
-rw-r--r-- 1 root root 127209 Dec 2 05:11 symvers-3.12.67-60.64.21-default.gz
-rw-r--r-- 1 root root 127209 Dec 9 10:45 symvers-3.12.67-60.64.24-default.gz
-rw-r--r-- 1 root root 409 Oct 8 2014 sysctl.conf-3.12.28-4-default
-rw-r--r-- 1 root root 409 Dec 2 05:11 sysctl.conf-3.12.67-60.64.21-default
-rw-r--r-- 1 root root 409 Dec 9 10:45 sysctl.conf-3.12.67-60.64.24-default
-rw-r--r-- 1 root root 4520837 Oct 8 2014 vmlinux-3.12.28-4-default.gz
-rw-r--r-- 1 root root 4400798 Dec 2 05:11 vmlinux-3.12.67-60.64.21-default.gz
-rw-r--r-- 1 root root 4401865 Dec 9 10:45 vmlinux-3.12.67-60.64.24-default.gz
drwxr-xr-x 3 root root 4096 Jan 5 16:25 zipl

ab
06-Jan-2017, 17:25
Are you using BtrFS, I presume? If so, we may want to ask the btrfs tools
about filesystem usage too; overall this disk seems really small, and I'd
still probably bet on a space being an influencer unless you can duplicate
the problem (presumably with a kernel patch) on another system:



btrfs filesystem usage /
btrfs filesystem usage /boot
snapper list



--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

mikenash
06-Jan-2017, 17:26
I have some questions? I did not perform the update so I do not know if any problems occurred during this process.
I tried to find a YAST log but I was unable to find one in /var/log/YaST2 but I am not sure what the name would be!

linux33:/var/log/YaST2 # ls
_dev_dasda curl_log macro_inst_initial.ycp signal y2log
arch.info disk_dasda.info mkinitrd.log tmpfs.info y2log-1.gz
config_diff_2014_12_19.log disk_dasda.info-1 pbl-instsys.log vncserver.log y2logmkinitrd
config_diff_2017_01_04.log free.info perl-BL-standalone-log y2changes y2start.log
I see that /etc/os-release does not state SLES12-SP1. Is this because I am on the previous kernel or that the update may have failed?

linux33:/var/log # cat /etc/os-release
NAME="SLES"
VERSION="12"
VERSION_ID="12"
PRETTY_NAME="SUSE Linux Enterprise Server 12"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:12"
At this point is it possible to perform the update to SP1?
Is there any cleanup that need to be done, like removing initrd files or any other files?

ab
06-Jan-2017, 17:42
On 01/06/2017 09:34 AM, mikenash wrote:
>
> I have some questions? I did not perform the update so I do not know if
> any problems occurred during this process.
> I tried to find a YAST log but I was unable to find one in
> /var/log/YaST2 but I am not sure what the name would be!
>
> Code:
> --------------------
> linux33:/var/log/YaST2 # ls
> _dev_dasda curl_log macro_inst_initial.ycp signal y2log
> arch.info disk_dasda.info mkinitrd.log tmpfs.info y2log-1.gz
> config_diff_2014_12_19.log disk_dasda.info-1 pbl-instsys.log vncserver.log y2logmkinitrd
> config_diff_2017_01_04.log free.info perl-BL-standalone-log y2changes y2start.log
> --------------------

y2log is the main log if Yast was used, or else you may want to look for a
zypper log file: /var/log/zypper.log

> I see that /etc/os-release does not state SLES12-SP1. Is this because I
> am on the previous kernel or that the update may have failed?
>
> Code:
> --------------------
> linux33:/var/log # cat /etc/os-release
> NAME="SLES"
> VERSION="12"
> VERSION_ID="12"
> PRETTY_NAME="SUSE Linux Enterprise Server 12"
> ID="sles"
> ANSI_COLOR="0;32"
> CPE_NAME="cpe:/o:suse:sles:12"
> --------------------

It should be updated by the package that owns it, which apparently was not
upgraded to SP1; you can find that package using the following command:



rpm -qf /etc/os-release


> At this point is it possible to perform the update to SP1?
> Is there any cleanup that need to be done, like removing initrd files or
> any other files?

I would still address disk space before doing anything else. Performing
an SP upgrade (distribution upgrade probably, meaning 'zypper dup') with
less-than 1 GiB free, particularly when you likely have BtrFS snapshots,
seems like a bad idea.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...