[Bug 954650] New: Installation of leap fails reliably with - error code 4013
http://bugzilla.opensuse.org/show_bug.cgi?id=954650 Bug ID: 954650 Summary: Installation of leap fails reliably with - error code 4013 Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Critical Priority: P5 - None Component: Installation Assignee: yast2-maintainers@suse.de Reporter: stakanov@freenet.de QA Contact: jsrain@suse.com Found By: --- Blocker: --- I try to install leap on a machine with Tumbleweed installed. This machine has three disc. sda sdb sdc The sda holds Tumbleweed with /sda1 as /boot and /sda2 as encryped LVM both with EXT4. Boot loader is Grub2 with password. After the recent updates everything is fine with this. sdb holds one encrypted partition with XFS for the entire disk. sdc should hold leap and has been erased to 0 partitions, virgin prior to install. During install I give the installer all passwords for unlocking. I choose to use sdc as disc to install leap. I change to ext4 setup with encrypted LVM, /boot on sdc1 and /LVM on sdc2 as proposed by the installer. I set here also password protected Grub2 in /boot on sdc1. When I want to install the installation fails reliably with the following error (translated from Italian but should be understandable). System error during the following operation. While removing the system volume group LVM_VG_REMOVE_FAILED. Error code was -4013 /sbin/vgrepremove -f 'system' connect failed no such file or directory warning failed to connect to lvmetad falling back to internal scanning Continue despite this error. Now, before I did try to continue but you get a non working system. /boot is created but /system is empty in that case. After the install the other partitions are unchanged and tumbleweed does boot perfectly, so at least now trouble with that. But I do not manage to install Leap with this setting. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954650 http://bugzilla.opensuse.org/show_bug.cgi?id=954650#c2 Stakanov Schufter <stakanov@freenet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(stakanov@freenet. | |de) | --- Comment #2 from Stakanov Schufter <stakanov@freenet.de> --- Created attachment 655899 --> http://bugzilla.opensuse.org/attachment.cgi?id=655899&action=edit yast2log taken of a dedicated usbdrive mounted following the wiki the pendrive is there, so whatever else you need, I can provide. The procedure is absolutely the same all the time and finshes with the error that I did write in the OP. Hope that helps. P.S. thank you for the wiki, it is not so easy as it seams the first time, but now I know "Kung Fu" :-) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954650 http://bugzilla.opensuse.org/show_bug.cgi?id=954650#c3 Stakanov Schufter <stakanov@freenet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yast2-maintainers@suse.de Flags| |needinfo?(yast2-maintainers | |@suse.de) --- Comment #3 from Stakanov Schufter <stakanov@freenet.de> --- I tried now out several scenarios. a) normal install without LVM. Success but one erroneous behavior of the installer. Leap does install, as set in the process, "use the whole disc /sdc" in sdc1,sdc2,sdc3 , but is using as well sdb1 without asking(!) as place for btrfs snapshots. More curiously, it does neither indicate nor ask to do that, that is, I had no way to see this during install. However, for the rest leap installs and is stable in this context, coexisting w/o problems with Tumbleweed on the same machine (on sda with encrypted lvm). b) using the encrypted LVM install approach: this gives the very same error as the install with EXT4: error 4013 with exactly the same error message. I haven't yet tried the pure LVM version. If you deem it useful I will do so. I can also provide for any of these situations the respective yast2log (again if you deem it of useful). That said: even in situation as of a) the installer should not "just like that" and without even showing it in the resume of install, attribute an existing sdb1/XFS partition (even if, as in this case, empty), to write on it btrfs snapshots. So I see also problems in this config with the very normal installer. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954650 http://bugzilla.opensuse.org/show_bug.cgi?id=954650#c5 --- Comment #5 from Stakanov Schufter <stakanov@freenet.de> --- I have some additional info, maybe of interest. I tried all available combinations of the install process and found out there are some differences. a) default partitioning as proposed with btrfs xfs without lvm does work b) default partitioning with ext4 as file system does work c) default partitioning btrfs xfs clicking "modify proposal" selecting LVM without encryption does fails with error 4013 d) default partitioning btrfs xfs clicking "modify proposal" selecting LVM with encryption does fail with 4013 but interestingly in this proposal the "enlarge swap for suspension" is greyed out and does not work. e) same as of above with EXT4 fails in the very same way, also here the enlarge swap is inactive/greyed out. f) cancelling the default partitioning and choosing: create partition configuration 1) attributing the third disk entirely succeeds as mentioned before without LVM (but messes with existing partitions if available). 2) attributing the third disk entirely choosing LVM with or without encryption fails and furthermore, the enlarge swap is greyed out, and the size of /home is wrongly set in the sense that without LVM it is set to the max space. With LVM instead it is set to a quite arbitrary value of 50 GB if 90 are available, 100Gb when e.g. 190 are available. It can be corrected by resizing in expert partitioning. But it will be irritating to a less experienced user because it will not be modifiable through modify proposal of "create partition configuration". In both cases 1) and 2) the install fails then with error -4013 at the end. g)The most curious case I had when attributing the second disk, without any pre-existing partition. First of all, it messes with the /boot of sda1 that it wants to format (by default). With "create partitioning configuration" - use entire disk instead, (That is: install to sdb with sdb1,sdb2(LVM without encryption)): If you attribute the second disk with "create partition configuration, use entire disk", it will use sdb1/boot and sdb2/LVM as expected. There the "enlarge swap" selection is possible, but, before even going on with the install you get a pop up with the following error message: "impossible to set cypher. Error code -3014. Possible that the cypher password is not correct." Now, this is curious, because it was a NOT encrypted LVM. And the existing password of sda2 was accepted at the beginning of the process already and the disk is visible. Moreover, the disc to install to (sdb), is empty, without any pre-existing partition. So whatever setup with LVM, with or without encryption does not seem to work (at least in my case). Personally I am not in a hurry. I have a laptop with 13.2 that works and Tumbleweed on the first disk. In order to report bugs I have now leap (although not installed as I would do, intended for real use, but still). So for me at this point of time there is no "cata" if this is postponed to a later point (as long as it is not "sine die"). Cheers. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954650 http://bugzilla.opensuse.org/show_bug.cgi?id=954650#c8 --- Comment #8 from Stakanov Schufter <stakanov@freenet.de> --- This seams to be at the end a hardware limitation of the bios of the machine. If one installs with one disk at the time it is possible to have a machine with dual boot via Bios. So on very old machines with a agp/pci-e combination for graphics and a risercard for a cpu upgrade etc.etc. you may encounter this. Solution: In this particular configs one has to use a screw driver. Once installed, connecting the disks, dual even triple etc. boot is possible via bios selection of the hdd to boot. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=954650 http://bugzilla.opensuse.org/show_bug.cgi?id=954650#c9 Stakanov Schufter <stakanov@freenet.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Stakanov Schufter <stakanov@freenet.de> --- sorry should have been set to resolved as status. done -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com