First boot after install dialog fails

**shmuelmetz** · 14-Jul-2020, 13:20

I'm attempting to install LEAP 15.2. with KDE on /dev/sda16 formatted as ext4. I specify installing grub in the PBR for /dev/sda16. I get all the way through the install dialog and the automatic rebot, but the KDE logon manager never initializes. I took a shot of the screen but it's very blurry. Are there any log files that I should be looking at from a live DVD? Any suggestions?

The install target is an SSD with the layout below:

Code:

DFSee OS/2   16.7 : Executing: fdisk -r- -w-
Command timestamp : Tuesday 2020-07-14 15:53:03
+---+--+--+-----------------+--------+--------+-----------+----------------------------------------------------+-----------+
|ID |ux|Dr|Type, description|Format  |Related |VolumeLabel|OS2-LVM/BM / GPT / Crypt / additional info          |  Size MiB |
+--</dev/sda     MBR disk  1>--------+--------+-----------<D1 SSD>---------------------------------------------+-----------+
|01>| 1|  |Prim 0c FAT32-Ext|FAT32   |MSWIN4.1|DOS BOOT   |DOS boot             DOS boot - disk                |       63.2|
|02 | 5|  |Log  0b FAT32    |FAT32   |DFSe16.x|DOS DATA   |DOS Data             DOS Data                       |      110.6|
|03 | 6|E:|Log  07 Inst-FSys|JFS     |IBM 4.50|ARCAOS505  |ArcaOS5.0.5          ArcaOS5.0.5                    |     4111.3|
|04 | 7|F:|Log  07 Inst-FSys|JFS     |IBM 4.50|ARCAOS503  |ArcaOS5.0.3          ArcaOS5.0.3                    |     4111.3|
|05 | 8|G:|Log  07 Inst-FSys|JFS     |IBM 4.50|ARCAOS501  |ArcaOS5.0.1          ArcaOS5.0.1                    |     4111.3|
|06 | 9|H:|Log  35 Warp-LVM |JFS     |IBM 4.50|UserData1  |User Data            User Data                      |    10009.6|
|07 |10|I:|Log  35 Warp-LVM |JFS     |IBM 4.50|Comm       |Data for comm        Data for comm                  |    10009.6|
|08 |11|M:|Log  35 Warp-LVM |JFS     |IBM 4.50|Manuals    |Manuals et al new    Manuals et al new              |    40006.8|
|09 |12|  |Log  0e FAT16-Ext|FAT     |DFSe16.x|SA DUMP    |Post Mortem          Post Mortem                    |     2039.8|
|10 |13|Q:|Log  07 Inst-FSys|JFS     |IBM 4.50|ARCAOS504  |ArcaOS5.0.4          ArcaOS5.0.4                    |     4127.1|
|11 |14|U:|Log  35 Warp-LVM |JFS     |IBM 4.50|Smedley    |Smedley Builds       Smedley Builds                 |     4111.3|
|12 |15|W:|Log  35 Warp-LVM |JFS     |IBM 4.50|Work       |Work Space           Work Space                     |    30013.0|
|13 |  |  |FreeSpace Logical|-- -- --|-- -- --|- - - - - -|                                                    |   743898.5|
|13 |16|  |Log  8e Linux-LVM|EXT4    |GRUB    |LEAP 15.2 b|LEAP 15.2 beta       LEAP 15.2 beta                 |    80013.7|
|14 |17|  |Log  82 SunS/SWAP|SWAP    |LinuxV1 |SWAPSPACE2 |swap SSD             swap SSD                       |    20003.4|
|15 |18|  |Log  83 LinuxNatv|XFS     |Linux   |home       |/home SSD            /home SSD                      |    20003.4|

**tsu2** · 15-Jul-2020, 15:10

Looks like you are chainloading your openSUSE install and an IBM OS.
Unfortunately I don't have any experience with an IBM OS (don't know what it is, mini or mainframe?) bootloader.

And, it becomes important to know exactly what is happening at the time your new openSUSE install doesn't boot... Would need to know exactly what succeeded on boot up to the failure... ie did your system boot to your IBM OS bootloader and then switch over to your openSUSE but fail, or did your system try to boot to openSUSE first?

Naturally, it should be helpful both if you've been running your IBM OS for a long enough time for you to know what should happen so you can know if any part of it is broken.

IMO,
TSU

**mrmazda** · 15-Jul-2020, 19:49

DFSee is reporting sda16 has a 0x8e LVM partition type rather than a 0x83 type appropriate to an EXT4 filesystem directly on the partition. Whether simply changing the type to 0x83 would be sufficient alone I won't speculate, as I've never yet tried to use Linux LVM purposely. It's probably worth trying though, as booting directly from an LVM partition by Grub is not supported. The hangup may be the openSUSE installer isn't handling this sort of error condition and doesn't try to install Grub, or report the problem on the screen. You could use installation media to boot the installed system, through which you could collect installation logs on a USB stick, local filesystem or network, with the save_y2logs command. Attaching this log set to a new bug against the installer reporting what happened sounds like something that may be needed. Booted this way you should also be able to use YaST to install Grub to sda16 successfully.

**shmuelmetz** · 16-Jul-2020, 01:15

Originally Posted by tsu2

Looks like you are chainloading your openSUSE install and an IBM OS.
Unfortunately I don't have any experience with an IBM OS (don't know what it is, mini or mainframe?) bootloader.

And, it becomes important to know exactly what is happening at the time your new openSUSE install doesn't boot... Would need to know exactly what succeeded on boot up to the failure... ie did your system boot to your IBM OS bootloader and then switch over to your openSUSE but fail, or did your system try to boot to openSUSE first?

Naturally, it should be helpful both if you've been running your IBM OS for a long enough time for you to know what should happen so you can know if any part of it is broken.

IMO,
TSU

I have Air-Boot in the MBR. I was able to install LEAP 15.2 beta and slecet it from the Air-Boot menu. The problem started when I tried to install LEAP 15.2 GA. I get the standard initial messages before I crash. I am not using the OS/2 Boot Manager.

**shmuelmetz** · 16-Jul-2020, 01:26

Originally Posted by mrmazda

DFSee is reporting sda16 has a 0x8e LVM partition type rather than a 0x83 type appropriate to an EXT4 filesystem directly on the partition. Whether simply changing the type to 0x83 would be sufficient alone I won't speculate, as I've never yet tried to use Linux LVM purposely. It's probably worth trying though, as booting directly from an LVM partition by Grub is not supported. The hangup may be the openSUSE installer isn't handling this sort of error condition and doesn't try to install Grub, or report the problem on the screen. You could use installation media to boot the installed system, through which you could collect installation logs on a USB stick, local filesystem or network, with the save_y2logs command. Attaching this log set to a new bug against the installer reporting what happened sounds like something that may be needed. Booted this way you should also be able to use YaST to install Grub to sda16 successfully.

I get well past grub; several pages of what look like standard Linux boot messages. I'll try changing the partition type first. Thanks.

**shmuelmetz** · 16-Jul-2020, 09:23

Changing the partition type didn't help. I wrote down the first few lines on the screen, and based on my reading of it I'm going to reinstall without enabling the online repositories. I'll post when I know the results of the reinstall.

Code:

[    0-323591] Spectre V2 : Spectre mitigation: LFENCE not serializing. switching to generic retpoline
[0.542296] ACPI Error: AE_NOT_FOUND, While resolving a  named reference package element - "\_PR_CPUB

**shmuelmetz** · 10-Aug-2020, 15:29

I opened https://bugzilla.opensuse.org/show_bug.cgi?id=1174214 and the problem was caused by a change in mounting devices with blacklisted fiie systems. When I removed theblacklisting of JFS I was able to log into KDE.