dracut and oem - issue with booting

[kanthans]

Hi

Problem description

I am creating a custom oem image. Using dracut as initrd and below are the info from sled.kiwi file data used

       <type
            image="oem"
            initrd_system="dracut"
            filesystem="btrfs"
            bootloader="grub2"
            firmware="bios"
            installiso="true"
            efipartsize="33"
            kernelcmdline="plymouth.enable=0 console=ttyS0,115200 console=tty0"
            bootpartition="true"
            devicepersistency="by-label"
            btrfs_root_is_snapshot="true"
        >
            <systemdisk>
                <volume name="home"/>
                <volume name="root"/>
                <volume name="tmp"/>
                <volume name="opt"/>
                <volume name="srv"/>
                <volume name="boot/grub2/x86_64-efi" mountpoint="boot/grub2/x86_64-efi"/>
                <volume name="usr/local"/>
                <volume name="var" copy_on_write="false"/>
            </systemdisk>
            <oemconfig>
                <oem-swap>true</oem-swap>
                <oem-swapsize>2048</oem-swapsize>
             </oemconfig>

I am not having an oemboot directory within the description directory.

The image build is successful and install.iso when deployed in vmware workstation works very well as long as the disk type is scsi. The moment it is changed to SATA to mimic real-world desktops the booting becomes erratic. 1 out of 2 times the boot process gets interrupted. Messages pretaining to mount failure (/, /var, /opt, /tmp etc) and after a soft-reboot (ctrl+alt_del) the system boots normal.

The same behaviour appears on a physical desktop/laptops as well.

Options tried

1. booted with firmware type as bios and uefi in kiwi-config file
2. set the VM firmware as legacy bios & uefi

Expected behaviour

I expect the system to boot normally (the way it works when i set the disk type to SCSI in vmware workstation

Steps to reproduce the behaviour

Create an image with similar configuration info.

OS and Software information

• KIWI version: 9.18.9
• Operating system: Suse Linux Enterprise Desktop 15
• OBS version: Not using OBS, building on a separate workstation with same level & kernel as the deployed OS

[kanthans]

Hi, the issue does not looks to be a kiwi issue, more with dracut initrd. Changed the /etc/fstab entry to reflect the device mapper id instead of the label. The issue looks to have gone. Will check with device-persistency by-uuid and confirm back.

[kanthans]

Confirming that the issue is resolved. changed device-persistency setting to by-uuid .

[kanthans]

The issue is reappearing even with "label-uuid"... I have found the system to be stable if we replace the "Label=ROOT" or UUID=" xxxxxxx" entries with /dev/mapper/.............................-part2/part3 entries in /etc/fstab. Not sure how device mapper enabled as the system is having single HDD system with btrfs filesystem. We are not using LVM or any dmraid functions.

[kanthans]

The issue is reappearing even with "label-uuid"... I have found the system to be stable if we replace the "Label=ROOT" or UUID=" xxxxxxx" entries with /dev/mapper/.............................-part2/part3 entries in /etc/fstab. Not sure how device mapper enabled as the system is having single HDD system with btrfs filesystem. We are not using LVM or any dmraid functions.

[davidcassany]

@kanthans I could not reproduce this issue in my KVM libvirt environment. I tried with the same <type> you shared but without success. I tried using IDE, SCSI and SATA configurations in my libvirt and they all worked fine. I also tried using the installation ISO too and also tested with uuid and label device persistence options.

I am clue less about how to follow up here. Could you verify you are still seeing the issue with current master v9.18.15? If so it would be also helpful if you manage to share the logs of the boot (you can include rd.debug rd.shell rd.kiwi.debug flags in your kernel command line to make it verbose).

[kanthans]

Hello @davidcassany
The issue is observed only in installation iso. Not in VMX.
I have tested in VMware Workstation with SATA and it is reproducible atleast 1 out of 10 times.
In a physical system with SATA disks the issue is reproducible 1 out of 3 times.

Will check with latest version of kiwi and revert back on this.

[davidcassany]

mmm then this is pretty bad, looks like some race condition at boot time...

Just to clarify the context. You are building a SLE 15 image from a SLE 15 host, right? Is the image using the regular systemd from standard repos?

[kanthans]

Yes, SLE15 image using SLE 15 Host. I have configured as of now only the SLE 15 Packages DVD image as the repo and hence not outside repo. Except for few addons as separate repo that has nothing to do with systemd or disk drivers.

[davidcassany]

I did some further tests again setting both SATA to harddisk and SATA cdrom device. No luck, so far i can't reproduce the issue.

I assume you don't even see any dialog of the installation process, is that correct? I am trying to figure out at which stage your system gets stuck. Also running some tests again on SLE15 specifically I hit an issue that you might hit too. Which version of the dracut-kiwi-* modules are you using?

If you are using a recent KIWI from git master or from https://download.opensuse.org/repositories/Virtualization:/Appliances:/Builder/SLE_15/ repository you should you the equivalent dracut-kiwi-* modules in your image. I mostly means that the mentioned repository should also be included in your image description and verify that the version of the dracut-kiwi-* that are included as part of the image matches the KIWI version you are using to build.

[kanthans]

Will share all information on 22/Sep/2019, as I am currently on travel.

[schaefi]

Will share all information on 22/Sep/2019, as I am currently on travel.

any news ?

[schaefi]

It seems this has lost its attraction