Reinstallation of Leap 42.1 fails

croppert · September 21, 2016, 11:00am

Hi,

first time I installed Leap 42.1 (USB stick, on a new HP) everything went fine - basically all default options regarding the partitions. Then I reinstalled it but with encrypted option and everything went fine again. Then I had to reinstall it once again, but now it fails every time. I keep getting the “Minimal BASH-like…” grub prompt. I’ve also tried to install with ext4 instead of the default btrfs since somebody mentioned that it leaves some crumbs that are hard to get rid off. No sucess though. Any ideas? I thought that a clean installation should work regardless of previous config?

Cheers,
Bo

dcurtisfra · September 21, 2016, 11:28am

When you reinstalled again, did you attempt to reuse the existing (encrypted) partitioning or, did you explicitly make sure that the installation procedure would first delete the existing (Linux) partitioning before adding the partitioning for the re-installation?
<https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.inst.html#sec.i.yast2.inst_mode.partitioning>
Did you also make sure that the installation using encrypted partitions was using a GPT Partition Table rather than the default (usually) MSDOS Partition Table?

croppert · September 21, 2016, 12:18pm

What I did was just ticking the “Create LVM-based proposal” and “Encrypt Volume Group” and then entering the pwd. I didn’t do anything else from the default setup. If MSDOS is the default, then probably this was used. Don’t know if I answered all your questions? Just let me know.
Thanx for your quick answer.

dcurtisfra · September 21, 2016, 12:26pm

The default installation assumes that openSUSE is being installed alongside something else and therefore, attempts to save any existing partitions.
Therefore, also for Dual-Boot systems, it pays to carefully inspect what’s going on in the “Suggested Partitioning” section of the installation procedure.

croppert · September 21, 2016, 2:23pm

Hm, ok, but I still don’t understand why the installation went well two times (I don’t need dual boot), and then third time it failed. Second and third time I had the same settings.

Now, during installation, I’ve checked in expert partitioner which says:


/dev/sda SanDisk...
sda1       EFI Boot    FAT
sda2       Linux        Swap
sda3       Linux LVM  FtrFS
sda4       Linux LVM  XFS
sdb        Generic Flash Disk
sdb1       EFI (FAT-12/16)     FAT
sdb2       Hidden HPFS/NTFS  ISO9660
/dev/system          LVM2  System
/dev/system/home  LV      XFS
/dev/system/root    LV      BtrlFS

The Installation settings say:

Booting
Boot from MBR does not work together with btrfs filesystem and GPT disk label without bios_grub partition. To fix this issue, create bios_grub partition or use any ext filesystem for boot partition or do not install stage 1 to MBR.

And the config:


* Install bootcode into MBR
* Do not install bootcode into "/" partition

Maybe this is what is wrong? Still, I didn’t change this first two times either but don’t remember if I got the red “warning” text about btrfs and MBR.

Isn’t there just a simple way to say “wipe everything and just install”

croppert · September 21, 2016, 3:32pm

Ok, I just read that the “best” thing to do is to first convert MBR to GPT, by running rescue mode and gdisk, and then installing. With possibly additional problems regarding iso9960 label, but then solving this with writing zeroes over the beginning of the disk.

knurpht · September 21, 2016, 4:16pm

And that’s easy: boot from the install medium / a linux live cd, and dd-ing the ~100M to the disk.

croppert · September 21, 2016, 5:21pm

So, now I got rid of the grub prompt, but it doesn’t boot at all, i.e nothing is found.

Going into rescue I see that the Disklabel type is gpt for:
/dev/sda1 BIOS boot
/dev/sda2 Linux LVM

and dos for:
/dev/sdb1 EFI (FaT-12/16/32)
/dev/sdb2 * Hidden HPFS/NTFS

and it seems that the boot partition is set totally wrong - set to the sdb2. Don’t know why sdb is not deleted?

gogalthorp · September 21, 2016, 6:21pm

sdb is you USB drive don’t delete anything there. Unless you have a second drive you did not mention.

sda1 should be an EFI boot partition formatted FAT

from rescue show efibootmgr

Basic way to install EFI is to be sure to boot the install disk in EFI mode. This will make an entry in the UEFI flash and add an opensuse directory to the efi boot partition creating one if needed.

The default is to add a new OS rather then to overwrite existing unless you chose to. Always be sure the partition scheme is what you want and expect before proceeding. Don’t just breeze through the screen.

croppert · September 21, 2016, 7:22pm

Yes, you’re right, the sdb is the USB of course - forgot about that one

The output from efibootmgr is:


BootCurrent: 000D
Timeout: 0 seconds
BootOrder: 000D,000A,000E,000B,000C,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000F
Boot0000  Startup Menu
Boot0001  System Information
Boot0002  Bios Setup
Boot0003  3rd Party Option ROM Management
Boot0004  System Diagnostics
Boot0005  System Diagnostics
Boot0006  System Diagnostics
Boot0007  System Diagnostics
Boot0008  Boot Menu
Boot0009  HP Recovery
Boot000A* SanDisk SD7SN6S-512G-1006 
Boot000B* SanDisk SD7SN6S-512G-1006 : 
Boot000C* Intel Corporation: IBA CL Slot 00FE v0106
Boot000D* Generic Mass Storage C4480B62
Boot000E* Generic Mass Storage C4480B62: 
Boot000F  Network Boot

Basic way to install EFI is to be sure to boot the install disk in EFI mode.

How is this achieved? Haven’t found anything about this, but maybe it’s in the docs.

The default is to add a new OS rather then to overwrite existing unless you chose

I chose to delete it, I think, because in the “summary” it said that all sda were going to be deleted first. Yes, I guess I have to take a closer look at the partition scheme, maybe I was to quick accepting all defaults.

dcurtisfra · September 21, 2016, 7:32pm

The LVM partitions on sda3 and sda4 need to be deleted at the next installation assuming that, you only want to run with a primary ext4 partition.
You could also reformat the EFI and swap partitions (sda1 and sda2) at the next installation.

gogalthorp · September 21, 2016, 8:26pm

openSUSE is not listed in UEFI flash so not properly installed. Boot the installer in EFI mode you may have to use the EFI boot menu which may be F9 F10 F12 or some other key (it is machine specific look in your docs)

Not sure what the BIOS boot partition is so I’d leave that partition alone. remove the LVM partition and start fresh you should have a a small FAT format EFI boot partition then your LVM

There appears to be a lot of redundant and probably unneeded stuff in the UEFI flash. Not sure if there is a limit on or the number of entries supported. This may be where the problem is but but you are pushing the limit of my knowledge and it may be hardware dependent. There are 16 entries It appears HP is striking out on it’s own path.

croppert · September 21, 2016, 10:37pm

Yes, I found the EFI boot menu, thanx. I’ve repeated the installation a couple of times now, since I got some error messages each time. Now, eventually, the installation was completed without errors and it looks better and better

Disk /dev/sda: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F3EB8D71-D0AF-436A-AD9D-0FB05B0ACE64

Device       Start        End   Sectors   Size Type
/dev/sda1     2048     321535    319488   156M EFI System
/dev/sda2   321536    1157119    835584   408M Microsoft basic data
/dev/sda3  1157120 1000214527 999057408 476.4G Linux LVM

Disk /dev/mapper/system-root: 40 GiB, 42949672960 bytes, 83886080 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/mapper/system-swap: 2 GiB, 2147483648 bytes, 4194304 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/sdb: 7.6 GiB, 8178892800 bytes, 15974400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x20ca2c8b

Device     Boot Start     End Sectors  Size Id Type
/dev/sdb1        3780   11339    7560  3.7M ef EFI (FAT-12/16/32)
/dev/sdb2  *    11340 9078783 9067444  4.3G 17 Hidden HPFS/NTFS

Disk /dev/mapper/system-home: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/sdc: 3.8 GiB, 4027580416 bytes, 7866368 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start     End Sectors  Size Id Type
/dev/sdc1          32 7866367 7866336  3.8G  b W95 FAT32

The only thing that bothers me is the sda2 (Microsoft), don’t know why and how that got there. Even sdc is a bit of a mystery?

efibootmgr also looks better, even if there are a loooot of entries?:

BootCurrent: 000A
Timeout: 0 seconds
BootOrder: 000A,000D,0010,000E,000B,000C,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000F
Boot0000  Startup Menu
Boot0001  System Information
Boot0002  Bios Setup
Boot0003  3rd Party Option ROM Management
Boot0004  System Diagnostics
Boot0005  System Diagnostics
Boot0006  System Diagnostics
Boot0007  System Diagnostics
Boot0008  Boot Menu
Boot0009  HP Recovery
Boot000A* opensuse-secureboot
Boot000B* SanDisk SD7SN6S-512G-1006 : 
Boot000C* Intel Corporation: IBA CL Slot 00FE v0106
Boot000D* Generic Mass Storage C4480B62
Boot000E* Generic Mass Storage C4480B62: 
Boot000F  Network Boot
Boot0010* SanDisk SD7SN6S-512G-1006

croppert · September 21, 2016, 10:44pm

Now I made a last reinstallation, at least I thought it should have been the last, with the same schema as the last successful one and the dreaded Minimal…grub prompt returned…>:(. Back to square 1. :mad:

dcurtisfra · September 22, 2016, 10:00am

Hmmm . . .
It seems that Hewlett-Packard and Lenovo Laptops have something in common – they’re possibly both sensitive to non-Microsoft operating systems . . .
[HR][/HR]My Lenovo (AMD) Laptop is Dual-Boot because it’s not possible to update the BIOS/UEFI without Windows; HP offers the possibility to update the BIOS/UEFI via a USB-Stick but, that temptation may be dangerous . . .
[HR][/HR]My guess is that, both Lenovo and HP have “expecting Microsoft” code in their firmware – BIOS/UEFI – which makes it difficult to have a “no Microsoft here” machine.
We may have to start a list of “must be Dual-Boot” machines . . .

The Empire strikes back . . .

whonea · September 22, 2016, 8:20pm

croppert wrote:

>
> Now I made a last reinstallation, at least I thought it should have been
> the last, with the same schema as the last successful one and the
> dreaded Minimal…grub prompt returned…>:(. Back to square 1. :mad:
>
Unless the 42.1 distro release was updated (haven’t checked, so this may be
useless info), the UEFI boot partition info was not properly written on my
HP. The work around was to copy some files from a working copy of 13.2
after which it took off and ran just fine.

The practice of not updating the GM distro after release said they wouldn’t
update the GM files, even if there was an error. I used the work around a
few times but had other issues with 42.1 and decided to skip it. I got the
work around info here, so someone probably has it but I got tired of messing
with all the issues and can’t recall exactly what file(s) needed to be
copied. Some of the web sites (theRegister.co.uk and Slashdot.com) had
blurbs today on Lenovo blocking non-Win UEFI installs and mentioned HP as
another giving problems but the original one on my HP box was a bug in the
installation files rather than a conspiracy

dcurtisfra · September 23, 2016, 9:15am

Which means that, after the end-of-support for 13.2 these files will have to be archived somewhere for general use. <https://en.opensuse.org/Lifetime>

The following distributions are expected to receive updates until the specified date:

openSUSE 13.2 - will be maintained until 2 months after release of Leap 42.2 (EXPECTED First Quarter of 2017)

Leap 42.1 - will be maintained until 6 months after 42.2 (EXPECTED Second Quarter of 2017)

whonea · September 23, 2016, 11:22pm

Not really. The update policy only means that the GM image is locked on the servers - which is reasonable in most cases. This particular case might have been a reasonable exception and might have been overruled - I just don’t know. The errant file was released as an update but any procedural oops makes it a PITA anyway you look at it - another reason to avoid changes even to GM issues. As I said, I don’t know the current status and an exception may have been made.

For my use, I stuck with 13.1/2 as the KDE issues made 42.1 useless to me. Even 42.2 with KDE still looks a lot like a vast change with a half-vast implementation of KDE…

dcurtisfra · September 24, 2016, 3:04pm

Assuming that, GM == “Gold Master”, personally, I’m rather (in)sensitive to the “Gold” terminology – due to some rather unpleasant experiences in my professional life with respect to marketing folks hyping up sales teams and customers with “Gold versions” of feature releases.

My personal preference is for “GA” – “General Availability”.

The bottom line with respect to the relationship of openSUSE to discontinued versions is here: <Lifetime - openSUSE Wiki;
This URL: <http://download.opensuse.org/distribution/>; does indicate that, the following discontinued distributions are available from the openSUSE servers: 11.4, 12.1, 12.1 and 13.1 – but with the following caveat:

motd

NFS shares of this server were disabled on Mon 20.6.2016!

find(.gz) and newfiles(.gz) are not updated at the moment.

The following is also relevant: <openSUSE:Mirrors - openSUSE Wiki.
Bottom line: hopefully the critical files will be available somewhere either on the openSUSE servers or, on an EOL mirror, somewhere . . .

Please note this News feed: <https://news.opensuse.org/2016/09/22/new-leap-beta-adds-plasma-5-8-beta/>
[HR][/HR]The relationship between human beings and computer operating systems is a little bit like marriage:

Sometimes it lasts forever;
Sometimes it results in divorce.

whonea · September 24, 2016, 10:55pm

dcurtisfra wrote:

> The following is also relevant:
> <https://en.opensuse.org/openSUSE:Mirrors#EOL_mirrors>.
> Bottom line: hopefully the critical files will be available somewhere
> either on the openSUSE servers or, on an EOL mirror, somewhere . . .
>

Actually, I keep installation copies of just about everything. As the price
of “small” USB sticks I moved everything I had on DVD to some 8GB devices I
picked up for a couple of bucks apiece as they seem to be much less fragile
over time as well as faster and more convenient. There are a number of
places where old versions of most distros are also available so that isn’t a
real issue, just a nuisance factor.

My major issues on my personal hardware are with network hardware - 42.2
network handling have been a PITA since I frequently switch between WIFI and
wired networking but the KDE desktop changes have been a huge issue with all
the users I support so that is likely to be an issue with any distro.

–
Will Honea