[opensuse-factory] Problems with installation of 15.0 Beta
Hi, Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition. Test system is in sda9, and has written grub to sda4 (extended partition) - notice the (,msdos9) entry in the output from bootinfo script: => Syslinux MBR (5.00 and higher) is installed in the MBR of /dev/sda. sda4: __________________________________________________________________________ File system: Extended Partition Boot sector type: Grub2 (v1.99-2.00) Boot sector info: Grub2 (v2.00) is installed in the boot sector of sda4 and looks at sector 945810512 of the same hard drive for core.img. core.img is at this location and looks for (,msdos9)/boot/grub2. It also embeds following components: sda9: __________________________________________________________________________ File system: ext4 Boot sector type: - Boot sector info: Operating System: openSUSE Leap 15.0 Beta Boot files: /boot/grub2/grub.cfg /etc/fstab /boot/grub2/i386-pc/core.img I told it to install grub "on partition". The text did not say which, but obviously I assumed to mean the root partition. I also told it not to overwrrite MBR, which it respected, with a big red warning. It could obviate the warning by detecting that the disk is not new and there are other installed systems. I will write a proper bugzilla tomorrow, if time allows. First I have to undo the damage. And before record the status for analysis. The laptop has several years of use with this same partition layout. Factory or test install has always worked in the same sda9, I never had any problem remotely similar to this. ---------- Second problem It failed to mount an encrypted data partition. It created this fstab line: LABEL=ANameUnseen /data/cripta xfs defaults 0 0 and no crypttab file. Obviously this causes boot to emergency mode to edit and comment out that line. During install, I told it to mount that existing encrypted partition, there was an automatically set tickbox that said "encrypted". ---------- third problem On emergency mode control-D did nothing. I had to force reboot by C-A-D keys. --------- The XFCE terminal tittle does not follow what happens in the command line. There is a bugzilla for this in 42.3, but no activity. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/09/2018 06:36 PM, Carlos E. R. wrote:
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition.
Test system is in sda9, and has written grub to sda4 (extended partition) - notice the (,msdos9) entry in the output from bootinfo script:
It worked fine for me, installing into "sda1". But that's a primary partition, so not the equivalent. I don't have a computer where I can test with a logical partition. Maybe I'll test in a VM if I get around to it. As I recall, this was always a problem. When I want to install in a logical partition, it has been tricky to persuade the installer to get it right.
---------- Second problem
It failed to mount an encrypted data partition. It created this fstab line:
LABEL=ANameUnseen /data/cripta xfs defaults 0 0
and no crypttab file. Obviously this causes boot to emergency mode to edit and comment out that line.
This is a known issue. See bug 1071350. According to comments in the bug report, this should be fixed in time for the final release of 15.0. In the meantime, my workaround for test installs is to copy "crypttab" to "/etc" myself. I keep a copy of "crypttab" in my "/home" file system. During the install (about half way through the package installing), I use CTRL-ALT-F2 to get a root command line. And then ls /mnt/etc/crypttab ## check if crypttab exists cp /mnt/home/crypttab /mnt/etc/crypttab and then CTRL-ALT-F7 to get back to the GUI install That gives me a good (bootable) install. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-10 03:02, Neil Rickert wrote:
On 03/09/2018 06:36 PM, Carlos E. R. wrote:
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition.
Test system is in sda9, and has written grub to sda4 (extended partition) - notice the (,msdos9) entry in the output from bootinfo script:
It worked fine for me, installing into "sda1". But that's a primary partition, so not the equivalent. I don't have a computer where I can test with a logical partition. Maybe I'll test in a VM if I get around to it.
As I recall, this was always a problem. When I want to install in a logical partition, it has been tricky to persuade the installer to get it right
It was never a problem here till today. Grub was supposed to be installed on "/", a logical partition. How to tell the bios to boot that one is my issue, not the installer's. The installer can not decide to install grub on another partition without telling me. .
---------- Second problem
It failed to mount an encrypted data partition. It created this fstab line:
LABEL=ANameUnseen /data/cripta xfs defaults 0 0
and no crypttab file. Obviously this causes boot to emergency mode to edit and comment out that line.
This is a known issue. See bug 1071350.
Oh.
According to comments in the bug report, this should be fixed in time for the final release of 15.0.
In the meantime, my workaround for test installs is to copy "crypttab" to "/etc" myself. I keep a copy of "crypttab" in my "/home" file system. During the install (about half way through the package installing), I use CTRL-ALT-F2 to get a root command line. And then ls /mnt/etc/crypttab ## check if crypttab exists cp /mnt/home/crypttab /mnt/etc/crypttab and then CTRL-ALT-F7 to get back to the GUI install
That gives me a good (bootable) install.
I can certainly add that file now, after booting the system. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 10/03/18 13:22, Carlos E. R. wrote:
On 2018-03-10 03:02, Neil Rickert wrote:
On 03/09/2018 06:36 PM, Carlos E. R. wrote:
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition.
Test system is in sda9, and has written grub to sda4 (extended partition) - notice the (,msdos9) entry in the output from bootinfo script:
It worked fine for me, installing into "sda1". But that's a primary partition, so not the equivalent. I don't have a computer where I can test with a logical partition. Maybe I'll test in a VM if I get around to it.
As I recall, this was always a problem. When I want to install in a logical partition, it has been tricky to persuade the installer to get it right
It was never a problem here till today.
Grub was supposed to be installed on "/", a logical partition. How to tell the bios to boot that one is my issue, not the installer's. The installer can not decide to install grub on another partition without telling me.
I had no problem at all in having the installer use the Root Partition to install grub, and the Root Partition (ext4) is a logical partition within the extended partition. A question: were you installing 15.0 using English or using Spanish language (?is it possible to install it in Spanish?)? I ask because of what you said earlier, "I told it to install grub "on partition" which I have not seen -- I see "Root Partition". [pruned] BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-10 06:09, Basil Chupin wrote:
On 10/03/18 13:22, Carlos E. R. wrote:
On 2018-03-10 03:02, Neil Rickert wrote:
On 03/09/2018 06:36 PM, Carlos E. R. wrote:
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition.
Test system is in sda9, and has written grub to sda4 (extended partition) - notice the (,msdos9) entry in the output from bootinfo script:
It worked fine for me, installing into "sda1". But that's a primary partition, so not the equivalent. I don't have a computer where I can test with a logical partition. Maybe I'll test in a VM if I get around to it.
As I recall, this was always a problem. When I want to install in a logical partition, it has been tricky to persuade the installer to get it right
It was never a problem here till today.
Grub was supposed to be installed on "/", a logical partition. How to tell the bios to boot that one is my issue, not the installer's. The installer can not decide to install grub on another partition without telling me.
I had no problem at all in having the installer use the Root Partition to install grub, and the Root Partition (ext4) is a logical partition within the extended partition.
A question: were you installing 15.0 using English or using Spanish language (?is it possible to install it in Spanish?)? I ask because of what you said earlier, "I told it to install grub "on partition" which I have not seen -- I see "Root Partition".
English. I did not take photos, I did not expect problems. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 11/03/18 00:06, Carlos E. R. wrote:
On 2018-03-10 06:09, Basil Chupin wrote:
On 10/03/18 13:22, Carlos E. R. wrote:
On 2018-03-10 03:02, Neil Rickert wrote:
On 03/09/2018 06:36 PM, Carlos E. R. wrote:
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition.
Test system is in sda9, and has written grub to sda4 (extended partition) - notice the (,msdos9) entry in the output from bootinfo script: It worked fine for me, installing into "sda1". But that's a primary partition, so not the equivalent. I don't have a computer where I can test with a logical partition. Maybe I'll test in a VM if I get around to it.
As I recall, this was always a problem. When I want to install in a logical partition, it has been tricky to persuade the installer to get it right It was never a problem here till today.
Grub was supposed to be installed on "/", a logical partition. How to tell the bios to boot that one is my issue, not the installer's. The installer can not decide to install grub on another partition without telling me. I had no problem at all in having the installer use the Root Partition to install grub, and the Root Partition (ext4) is a logical partition within the extended partition.
A question: were you installing 15.0 using English or using Spanish language (?is it possible to install it in Spanish?)? I ask because of what you said earlier, "I told it to install grub "on partition" which I have not seen -- I see "Root Partition". English. I did not take photos, I did not expect problems.
Aaah, and there's the problem: "I did not expect problems". I*always* expect problems -- even if it is to an existing installation like 42.3 :-). How many times have I read on this list the words of advice, "But it's only an Alpha (or a Beta) so expect problems" :-). BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2018-03-11 03:54, Basil Chupin wrote:
On 11/03/18 00:06, Carlos E. R. wrote:
On 2018-03-10 06:09, Basil Chupin wrote:
On 10/03/18 13:22, Carlos E. R. wrote:
On 2018-03-10 03:02, Neil Rickert wrote:
On 03/09/2018 06:36 PM, Carlos E. R. wrote:
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition.
Test system is in sda9, and has written grub to sda4 (extended partition) - notice the (,msdos9) entry in the output from bootinfo script: It worked fine for me, installing into "sda1". But that's a primary partition, so not the equivalent. I don't have a computer where I can test with a logical partition. Maybe I'll test in a VM if I get around to it.
As I recall, this was always a problem. When I want to install in a logical partition, it has been tricky to persuade the installer to get it right It was never a problem here till today.
Grub was supposed to be installed on "/", a logical partition. How to tell the bios to boot that one is my issue, not the installer's. The installer can not decide to install grub on another partition without telling me. I had no problem at all in having the installer use the Root Partition to install grub, and the Root Partition (ext4) is a logical partition within the extended partition.
A question: were you installing 15.0 using English or using Spanish language (?is it possible to install it in Spanish?)? I ask because of what you said earlier, "I told it to install grub "on partition" which I have not seen -- I see "Root Partition". English. I did not take photos, I did not expect problems.
Aaah, and there's the problem: "I did not expect problems". I*always* expect problems -- even if it is to an existing installation like 42.3 :-). How many times have I read on this list the words of advice, "But it's only an Alpha (or a Beta) so expect problems" :-).
Yesterday I installed 42.3 on that partition, taking photos and noting the differences in that area. Now I'm imaging that install. And later, I will install 15.0B taking special attention and photos of the area (I think I noticed differences, but I can't trust memory). This investigation is taking many hours. Till recently I did not know that it was possible to capture screenshots of the installation, it is the first time I do it. Previously I used a camera with a tripod, which is not some thing fast to prepare. Or used a virtual machine installation. - -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlqk+JsACgkQja8UbcUWM1yZDwD/RHIC02WMQBzQfNdDROehKBbC WmFCcVw1lLvbLfEsZTQBAJb/AU/5bYydvoDVSUe+zTmFsJQ28NGae8hwzmFuV5lL =4ocM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Neil Rickert composed on 2018-03-09 20:02 (UTC-0600):
Carlos E. R. wrote:
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition.
Test system is in sda9, and has written grub to sda4 (extended partition) - notice the (,msdos9) entry in the output from bootinfo script:
It worked fine for me, installing into "sda1". But that's a primary partition, so not the equivalent. I don't have a computer where I can test with a logical partition. Maybe I'll test in a VM if I get around to it.
As I recall, this was always a problem. When I want to install in a logical partition, it has been tricky to persuade the installer to get it right. Never been a problem for me, and I've never ever put / on a MBR primary. On rare occasions I have had /boot on a primary, but as all my installations are on hardware multiboot systems, the realboot primary is already ready to go and not to be touched by an installer.
On Linux multiboot systems, maybe best thing to do is choose install no bootloader during installation, as I always do since Grub 0.97 was eliminated from installation options, and install bootloader later (or never), maybe without YaST2, after first boot from using the primary bootloader (possibly from using configfile, if the installer builds the file regardless of actually "installing"), and disabling os-prober. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-10 03:27, Felix Miata wrote:
Neil Rickert composed on 2018-03-09 20:02 (UTC-0600):
Carlos E. R. wrote:
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition.
Test system is in sda9, and has written grub to sda4 (extended partition) - notice the (,msdos9) entry in the output from bootinfo script:
It worked fine for me, installing into "sda1". But that's a primary partition, so not the equivalent. I don't have a computer where I can test with a logical partition. Maybe I'll test in a VM if I get around to it.
As I recall, this was always a problem. When I want to install in a logical partition, it has been tricky to persuade the installer to get it right. Never been a problem for me, and I've never ever put / on a MBR primary. On rare occasions I have had /boot on a primary, but as all my installations are on hardware multiboot systems, the realboot primary is already ready to go and not to be touched by an installer.
Exactly. Yet the 15.0 installer touched it. It changed another Linux Grub, on another partition, a primary. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. composed on 2018-03-10 03:33 (UTC+0100):
Felix Miata wrote:
Never been a problem for me, and I've never ever put / on a MBR primary. On rare occasions I have had /boot on a primary, but as all my installations are on hardware multiboot systems, the realboot primary is already ready to go and not to be touched by an installer.
Exactly. Yet the 15.0 installer touched it. It changed another Linux Grub, on another partition, a primary.
Another possible difference here: installer partitioners here are never used for partitioning. All they are ever used for is designating mount points & options. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-10 03:50, Felix Miata wrote:
Carlos E. R. composed on 2018-03-10 03:33 (UTC+0100):
Felix Miata wrote:
Never been a problem for me, and I've never ever put / on a MBR primary. On rare occasions I have had /boot on a primary, but as all my installations are on hardware multiboot systems, the realboot primary is already ready to go and not to be touched by an installer.
Exactly. Yet the 15.0 installer touched it. It changed another Linux Grub, on another partition, a primary.
Another possible difference here: installer partitioners here are never used for partitioning. All they are ever used for is designating mount points & options.
I did not create or changed any partition. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition.
Confirmed, did it again. I have dedicated about a full day to test this. To verify, I installed Leap 42.3 on the sda9 test partition, and verified that that the main install and secondary install had both Grub booting correctly. Took an image backup. I took photos during the install. I verified that YaST on 42.3 gives these options (defaults marked): [X] Boot from Root partition [ ] Boot from master boot record [X] Boot from extended partition [ ] Custom boot partition which I changed to the correct settings for this laptop: [X] Boot from Root partition [ ] Boot from master boot record [ ] Boot from extended partition [ ] Custom boot partition Then I installed Leap 15.0 Beta on the same partition. I also took photos. The options were different: [X] Boot from partition [ ] Boot from master boot record [ ] Custom boot partition Notice that it does not say _which_ partition. So I did this: [ ] Boot from partition [ ] Boot from master boot record [X] Custom boot partition [/dev/sda9 ] I noticed that in going to another tab, the "/dev/sda9" entry was cleared out: [ ] Boot from partition [ ] Boot from master boot record [ ] Custom boot partition [ ] I again marked the correct entries. I could not take more photos, yast refused. On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9 I don't understand this, YaST had this working on previous versions. Why write the code again? I will now create a bugzilla entry and attach photos and logs. No, first I have to try correct grub. And eat. Etc. [...] Well, YaST in 15.0 is unable to correct the situation. It insists on not installing grub to sda9. I can only correct the situation on the main system, which will render 15.0 unbootable. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 15.0, at Minas-Anor) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition. Confirmed, did it again. I have dedicated about a full day to test this.
To verify, I installed Leap 42.3 on the sda9 test partition, and verified that that the main install and secondary install had both Grub booting correctly. Took an image backup.
I took photos during the install. I verified that YaST on 42.3 gives these options (defaults marked):
[X] Boot from Root partition [ ] Boot from master boot record [X] Boot from extended partition [ ] Custom boot partition
which I changed to the correct settings for this laptop:
[X] Boot from Root partition [ ] Boot from master boot record [ ] Boot from extended partition [ ] Custom boot partition
Then I installed Leap 15.0 Beta on the same partition. I also took photos. The options were different:
[X] Boot from partition [ ] Boot from master boot record [ ] Custom boot partition
Notice that it does not say _which_ partition. So I did this:
[ ] Boot from partition [ ] Boot from master boot record [X] Custom boot partition [/dev/sda9 ]
I noticed that in going to another tab, the "/dev/sda9" entry was cleared out:
[ ] Boot from partition [ ] Boot from master boot record [ ] Custom boot partition [ ]
I again marked the correct entries. I could not take more photos, yast refused.
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements.
I will now create a bugzilla entry and attach photos and logs. No, first I have to try correct grub. And eat. Etc.
[...]
Well, YaST in 15.0 is unable to correct the situation. It insists on not installing grub to sda9. I can only correct the situation on the main system, which will render 15.0 unbootable.
-- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team Linux user #548252 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-11 15:00, Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
...
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements.
But the translation was done and finished years ago. You mean that maintenance is done on the original language, not Ruby, then translated again to Ruby? Then the code is being redone from scratch in Ruby? Ouch. That hurts. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Op zondag 11 maart 2018 19:22:15 CET schreef Carlos E. R.:
On 2018-03-11 15:00, Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
...
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements. But the translation was done and finished years ago.
You mean that maintenance is done on the original language, not Ruby, then translated again to Ruby?
Then the code is being redone from scratch in Ruby?
Ouch. That hurts.
AFAIK yes. Re-using translations requires a lot of work. But sometimes you have no other option. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team Linux user #548252 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sonntag, 11. März 2018 19:22:15 CET Carlos E. R. wrote:
On 2018-03-11 15:00, Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
...
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements. But the translation was done and finished years ago.
You mean that maintenance is done on the original language, not Ruby, then translated again to Ruby?
Then the code is being redone from scratch in Ruby?
Ouch. That hurts.
Why don't you stop making assumptions and e.g. read the (IMHO excellent) sprint reports from the yast team. The links to the full reports have been posted ~weekly on this very list, including a short overview. If you read these reports and have any questions left, feel free to ask again. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
There is at least one problem with the bootloader installation. As shown in https://bugzilla.novell.com/show_bug.cgi?id=1084017, the installer fails to set the boot flags correctly. My installation is a non-EFI system with a GPT partitioning scheme. I am installing the boot loader in the partition, and leaving the generic boot code in the MBR. In this case, the active partition is indicated by the "boot_legacy" flag. The installer fails to change this flag, and on reboot, the TW partition is still the one that boots GRUB. Because I had reformatted the partition used for 15.0, I could not even select it in the GRUB memu until I had rebooted TW and updated its boot files using YaST => System -> Boot Loader. That rewrote grub.cfg in the TW partition, which made the UUID for the 15.0 partition be correct. At that point, I could boot Leap 15.0 and use the Boot Loader part of YaST to fix the flags. Previously, YaST could not handle the boot flag at all, and I had to use parted to fix them. There is progress. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-11 20:18, Stefan Brüns wrote:
On Sonntag, 11. März 2018 19:22:15 CET Carlos E. R. wrote:
On 2018-03-11 15:00, Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
...
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements. But the translation was done and finished years ago.
You mean that maintenance is done on the original language, not Ruby, then translated again to Ruby?
Then the code is being redone from scratch in Ruby?
Ouch. That hurts.
Why don't you stop making assumptions and e.g. read the (IMHO excellent) sprint reports from the yast team. The links to the full reports have been posted ~weekly on this very list, including a short overview.
If you read these reports and have any questions left, feel free to ask again.
Well, because I usually try to avoid reading dry texts ;-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 11 March 2018 at 21:18, Carlos E. R.
On 2018-03-11 20:18, Stefan Brüns wrote:
On Sonntag, 11. März 2018 19:22:15 CET Carlos E. R. wrote:
On 2018-03-11 15:00, Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
...
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements. But the translation was done and finished years ago.
You mean that maintenance is done on the original language, not Ruby, then translated again to Ruby?
Then the code is being redone from scratch in Ruby?
Ouch. That hurts.
Why don't you stop making assumptions and e.g. read the (IMHO excellent) sprint reports from the yast team. The links to the full reports have been posted ~weekly on this very list, including a short overview.
If you read these reports and have any questions left, feel free to ask again.
Well, because I usually try to avoid reading dry texts ;-)
I usually try to avoid reading pointless nonsense, and yet you repeatedly make that difficult Do yourself a favour, read them, learn, and if you find behaviour that doesn't make sense to you, file bugs Stop wasting the time of everyone on the list. Your mails are not helping anyone, not even yourself it seems given your attitude. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Carlos E. R. wrote:
On 2018-03-11 15:00, Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
...
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements.
But the translation was done and finished years ago.
You mean that maintenance is done on the original language, not Ruby, then translated again to Ruby?
In 2013 there the YaST team did a mostly automated (AFAIK) translation from ycp to ruby - since then, maintenance and new development is in ruby. -- Per Jessen, Zürich (8.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-12 08:29, Per Jessen wrote:
Carlos E. R. wrote:
On 2018-03-11 15:00, Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
...
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements.
But the translation was done and finished years ago.
You mean that maintenance is done on the original language, not Ruby, then translated again to Ruby?
In 2013 there the YaST team did a mostly automated (AFAIK) translation from ycp to ruby - since then, maintenance and new development is in ruby.
The partition module has lost many features in 15.0, and some are appearing back one by one. For example, one could before change settings and have a particular filesystem as default for new partitions, say ext4. Or prefer mount by label. Or choose which values to display. Of these three that I remember, only one is available this week, none the week before. It is still not possible, or I have missed it again, to import from an existing fstab. This is very important for reinstalls. Not possible to reuse an existing encrypted partition. All these things existed in 42.3, so to me it is apparent that they are rewriting the code. And in a rewrite, errors are made that were not present before. I have some doubts that this yast module can be ready and debugged in two months with all the features. I hope to be wrong. This is a module that I have trusted for two decades (different incarnations), and it is a crucial module. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2018-03-12 08:29, Per Jessen wrote:
Carlos E. R. wrote:
In 2013 the YaST team did a mostly automated (AFAIK) translation from ycp to ruby - since then, maintenance and new development is in ruby.
The partition module has lost many features in 15.0, and some are appearing back one by one.
It is a new developmen from scratch. {yast-,lib}storage-ng. It will no doubt be re-gaining those features in/with time.
All these things existed in 42.3, so to me it is apparent that they are rewriting the code.
I think it is well-known. See above :-)
And in a rewrite, errors are made that were not present before. I have some doubts that this yast module can be ready and debugged in two months with all the features. I hope to be wrong. This is a module that I have trusted for two decades (different incarnations), and it is a crucial module.
Well, I am quite confident it'll be 99% ready. A little over a month ago, I filed a report on not being able to mount otherwise unsupported filesystems, it was already fixed (thanks!). Other little details with mount points and defaults have also been fixed. I would like to see iscsi and nfs on root also working, but I accept those are somewhat excotic features, they can wait. -- Per Jessen, Zürich (10.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 03/11/2018 07:22 PM, Carlos E. R. wrote:
On 2018-03-11 15:00, Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
...
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements.
But the translation was done and finished years ago.
You mean that maintenance is done on the original language, not Ruby, then translated again to Ruby?
Then the code is being redone from scratch in Ruby?
Ouch. That hurts.
Please, don't mix the conversion to Ruby with the rewrite of the storage stack (i.e. replacing libstorage and yast2-storage with libstorage-ng and yast2-storage-ng). They are completely different and disconnected things. The conversion to Ruby was done and finished years ago for the reasons explained by Knurpht above. The storage-ng effort is a current WIP and the reasons has been stated in several places (including this list regularly). One of the most recent communications is this article in news.o.o. https://news.opensuse.org/2018/01/09/future-tumbleweed-snapshot-to-bring-yas... Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-03-13 15:45, Ancor Gonzalez Sosa wrote:
On 03/11/2018 07:22 PM, Carlos E. R. wrote:
On 2018-03-11 15:00, Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
...
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements.
But the translation was done and finished years ago.
You mean that maintenance is done on the original language, not Ruby, then translated again to Ruby?
Then the code is being redone from scratch in Ruby?
Ouch. That hurts.
Please, don't mix the conversion to Ruby with the rewrite of the storage stack (i.e. replacing libstorage and yast2-storage with libstorage-ng and yast2-storage-ng). They are completely different and disconnected things.
The conversion to Ruby was done and finished years ago for the reasons explained by Knurpht above.
The storage-ng effort is a current WIP and the reasons has been stated in several places (including this list regularly). One of the most recent communications is this article in news.o.o.
https://news.opensuse.org/2018/01/09/future-tumbleweed-snapshot-to-bring-yas...
Thanks for this link, I *now* understand the issue. Although the article doesn't mention the boot module directly, I assume it is also affected. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 03/13/2018 03:59 PM, Carlos E. R. wrote:
On 2018-03-13 15:45, Ancor Gonzalez Sosa wrote:
On 03/11/2018 07:22 PM, Carlos E. R. wrote:
On 2018-03-11 15:00, Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
...
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short: YaST was writen in it's own language, resulting in the fact that both YaST and the coding language have to be maintained to stay up with developments. Rewriting in Ruby opens options for new developments/technical improvements.
But the translation was done and finished years ago.
You mean that maintenance is done on the original language, not Ruby, then translated again to Ruby?
Then the code is being redone from scratch in Ruby?
Ouch. That hurts.
Please, don't mix the conversion to Ruby with the rewrite of the storage stack (i.e. replacing libstorage and yast2-storage with libstorage-ng and yast2-storage-ng). They are completely different and disconnected things.
The conversion to Ruby was done and finished years ago for the reasons explained by Knurpht above.
The storage-ng effort is a current WIP and the reasons has been stated in several places (including this list regularly). One of the most recent communications is this article in news.o.o.
https://news.opensuse.org/2018/01/09/future-tumbleweed-snapshot-to-bring-yas...
Thanks for this link, I *now* understand the issue.
Although the article doesn't mention the boot module directly, I assume it is also affected.
Well, all the following YaST2 packages have a direct dependency on yast2-storage(-ng): yast2-bootloader yast2-network yast2-packager yast2-update yast2-installation yast2-autoinstallation (i.e. AutoYaST) yast2-s390 yast2-rear yast2-multipath yast2-docker So we could say that basically all the YaST components are directly or indirectly affected by the switch or involved on it. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Knurpht - Gertjan Lettink wrote:
Op zondag 11 maart 2018 13:31:00 CET schreef Carlos E. R.:
Hi,
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition. Confirmed, did it again. I have dedicated about a full day to test
On 03/10/2018 01:36 AM, Carlos E. R. wrote: this.
To verify, I installed Leap 42.3 on the sda9 test partition, and verified that that the main install and secondary install had both Grub booting correctly. Took an image backup.
I took photos during the install. I verified that YaST on 42.3 gives these options (defaults marked):
[X] Boot from Root partition [ ] Boot from master boot record [X] Boot from extended partition [ ] Custom boot partition
which I changed to the correct settings for this laptop:
[X] Boot from Root partition [ ] Boot from master boot record [ ] Boot from extended partition [ ] Custom boot partition
Then I installed Leap 15.0 Beta on the same partition. I also took photos. The options were different:
[X] Boot from partition [ ] Boot from master boot record [ ] Custom boot partition
Notice that it does not say _which_ partition. So I did this:
[ ] Boot from partition [ ] Boot from master boot record [X] Custom boot partition [/dev/sda9 ]
I noticed that in going to another tab, the "/dev/sda9" entry was cleared out:
[ ] Boot from partition [ ] Boot from master boot record [ ] Custom boot partition [ ]
I again marked the correct entries. I could not take more photos, yast refused.
On boot, YaST had installed grub to /dev/sda4, overwriting the main system, ignoring my explicit orders to install on /dev/sda9
I don't understand this, YaST had this working on previous versions. Why write the code again?
The reasons for a complete rewrite of YaST have been explained. In short:
That was a while ago. According to what Carlos describes, some behaviour appears to have changed from Leap42.3 to Leap15. -- Per Jessen, Zürich (8.1°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-03-11 at 13:31 +0100, Carlos E. R. wrote:
On 03/10/2018 01:36 AM, Carlos E. R. wrote:
Hi,
Main problem: it has destroyed Grub install of my main system, overwriting it instead of installing in the test partition.
Confirmed, did it again. I have dedicated about a full day to test this.
...
I will now create a bugzilla entry and attach photos and logs. No, first I have to try correct grub. And eat. Etc.
It is Bug 1084815 - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqltp0ACgkQtTMYHG2NR9UF7QCdGR2gy+ktVJk3tDW99qqGAWfH 5PwAoIcjrjX2u/NZ6hjABaj6wRYCyf1v =GdyB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (10)
-
Ancor Gonzalez Sosa -
Basil Chupin -
Carlos E. R. -
Felix Miata -
Knurpht - Gertjan Lettink -
Larry Finger -
Neil Rickert -
Per Jessen -
Richard Brown -
Stefan Brüns