# dracut-initqueue\[291\]: Warning: Could not boot. **URL:** \ **Category:** SLES Updates\ **Created:** [January 6, 2017, 5:27pm UTC](https://forums.suse.com/t/dracut-initqueue-291-warning-could-not-boot/29206 "2017-01-06T17:27:34Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![mikenash](https://avatars.discourse-cdn.com/v4/letter/m/977dab/32.png) [@mikenash](https://forums.suse.com/u/mikenash)\ **Post date:** [January 6, 2017, 5:27pm UTC](https://forums.suse.com/t/dracut-initqueue-291-warning-could-not-boot/29206/1 "2017-01-06T17:27:34Z")
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. ```auto 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. ---
**Author:** ![ab1](https://avatars.discourse-cdn.com/v4/letter/a/d2c977/32.png) [@ab1](https://forums.suse.com/u/ab1)\ **Post date:** [January 6, 2017, 5:52pm UTC](https://forums.suse.com/t/dracut-initqueue-291-warning-could-not-boot/29206/2 "2017-01-06T17:52:38Z")
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… ---
**Author:** ![mikenash](https://avatars.discourse-cdn.com/v4/letter/m/977dab/32.png) [@mikenash](https://forums.suse.com/u/mikenash)\ **Post date:** [January 6, 2017, 6:07pm UTC](https://forums.suse.com/t/dracut-initqueue-291-warning-could-not-boot/29206/3 "2017-01-06T18:07:43Z")
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` ---
**Author:** ![mikenash](https://avatars.discourse-cdn.com/v4/letter/m/977dab/32.png) [@mikenash](https://forums.suse.com/u/mikenash)\ **Post date:** [January 6, 2017, 6:26pm UTC](https://forums.suse.com/t/dracut-initqueue-291-warning-could-not-boot/29206/4 "2017-01-06T18:26:20Z")
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? ---
**Author:** ![ab1](https://avatars.discourse-cdn.com/v4/letter/a/d2c977/32.png) [@ab1](https://forums.suse.com/u/ab1)\ **Post date:** [January 6, 2017, 6:25pm UTC](https://forums.suse.com/t/dracut-initqueue-291-warning-could-not-boot/29206/5 "2017-01-06T18:25:37Z")
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: ```auto 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… ---
**Author:** ![ab1](https://avatars.discourse-cdn.com/v4/letter/a/d2c977/32.png) [@ab1](https://forums.suse.com/u/ab1)\ **Post date:** [January 6, 2017, 6:42pm UTC](https://forums.suse.com/t/dracut-initqueue-291-warning-could-not-boot/29206/6 "2017-01-06T18:42:49Z")
On 01/06/2017 09:34 AM, mikenash wrote:[color=blue] > 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 > --------------------[/color] 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 [color=blue] > 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” > --------------------[/color] 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: ```auto rpm -qf /etc/os-release ``` [color=blue] > 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?[/color] 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…