Bug 1094749

Created attachment 771458 [details]
y2logs at issue

y2logs at issue point

This is the fstab layout:

elite-01:~ # cat /etc/fstab
/dev/System/root     /                    xfs        defaults              1 1
/dev/B-up/Save-1     /save-1              xfs        nofail                1 2
/dev/B-up/save-2     /save-2              xfs        nofail                1 2
/dev/System/home     /home                xfs        defaults              1 2
/dev/System/swap     swap                 swap       defaults              0 0
/dev/System/var      /var                 xfs        defaults              1 2
/dev/VM/local        /local               xfs        defaults              1 2
/dev/VM/pgms         /vm-pgm              xfs        defaults              1 2
/dev/VM/vm-mach      /vm-mach             xfs        defaults              1 2
UUID=BAA9-4F03       /boot/efi            vfat       umask=0002,utf8=true  0 0
/dev/System/opt      /opt                 xfs        defaults              1 2

If I can provide any more info please ask...

__

Thanks for the report

The failure is triggered by not finding /dev/B-up/Save-1

It *looks* like B-up is a volume group but I cannot see that in the logs, unlike the System and VM VGs.

(In reply to Martin Vidner from comment #3)
> Thanks for the report
> 
> The failure is triggered by not finding /dev/B-up/Save-1
> 
> It *looks* like B-up is a volume group but I cannot see that in the logs,
> unlike the System and VM VGs.

B-up (back-up) is only used when I want to run a back-up. Should I plug in the USB and try again ?

I do run this 90% on the time without it plugged in and I have not seen any messages, but then I have not looked for any either.

__R

> B-up (back-up) is only used when I want to run a back-up. Should I plug in the USB and try again ?

I suspect connecting the device will make the upgrade succeed. Definitely worth trying.

Ah, I see. Also, man 5 fstab says:
>  nofail     do not report errors for this device if it does not exist.

Apparently we should take a hint from that option :-/

(In reply to Martin Vidner from comment #5)
> > B-up (back-up) is only used when I want to run a back-up. Should I plug in the USB and try again ?
> 
> I suspect connecting the device will make the upgrade succeed. Definitely
> worth trying.
> 
> Ah, I see. Also, man 5 fstab says:
> >  nofail     do not report errors for this device if it does not exist.
> 
> Apparently we should take a hint from that option :-/

Yes that setting was the suggestion of the back-up people of Software AG as before that it did "nag" quite a bit. I do have another physical host with a very similar file systems but no B-up. I'll run the UPDATE and there, which I was going to do until I saw the issue on Sunday... I#ll let you know how that runs.

__R

*** Bug 1094837 has been marked as a duplicate of this bug. ***

Created attachment 771593 [details]
Install on Elete02, Okay bar issue at the end

The LEAP ISO GA Installed Okay on the mirror of Elite01 Okay bar a request for save_y2logs at the end. There were issue with the parms of the boot loader or in that area. I took the y2logs and pushed on. I do have a running system, maybe you can let me know what the issue was ?
Elite01 and Elite02 are two HP Elites I got to run SAG from my home office. They ran LEAP42 with VMware and I have SLES, LEAP and Win10 guests. So when you have the fix for the B-UP I'll UPDATE Elite01
__R

Created attachment 771870 [details]
hrach2 y2logs

The same problem on my machine, upgrading from 42.3 to 15.0

Hints: Slovak locale, US keyboard, encrypted disk partition (data)
Installation rollback after failure not OK - visible in YaST2 repositories, which rolled back to some 42.2 version (first snapper snapshot?). I had to rollback manually with snapper.

Attaching my y2logs.

Created attachment 772218 [details]
y2logs for comment 11

I see that same issue on my system, which admittedly has a somewhat weird and complex partition layout:

/dev/system/root     /                    ext4       acl,user_xattr        1 1
/dev/mapper/cr_home  /home                ext4       acl,user_xattr,nofail                0 0
/dev/system/swap     swap                 swap       defaults              0 0
/dev/disk/by-id/ata-XXX-part5 /boot                ext4       acl,user_xattr        1 2
/dev/disk/by-id/ata-XXX-part1 /boot/efi            vfat       umask=0002,utf8=true  0 0
/dev/mapper/cr_ephemeral /ephemeral       btrfs      defaults,nofail       0 0


/dev/mapper/cr_home is backed by /dev/md0, spanning /dev/sdc1 and /dev/sdd1.
/dev/mapper/cr_ephemeral is a full disk without partitions (/dev/sde).
The physical volume of volume group system is /dev/mapper/cr_system, which is a partition on /dev/sdb, which is the same drive /dev/disk/by-id/ata-XXX… are on.

One thing I noted is that the crypts are shown as cr-auto-1 and cr-auto-3 instead of cr_home and cr_ephemeral. I assume this might be part of the problem, as it would cause an issue similar to the original reporters: devices showing up in /etc/fstab that the updater can't find.

I have attached screenshots of the error messages and attached my yast logs.

Created attachment 772219 [details]
Error message screenshot for comment 12

Created attachment 772220 [details]
Error message 2 screenshot for comment 12

I just ran a quick test. If I switch out into one of the other consoles during the selection screens and modify the /etc/fstab to point to /dev/cr-auto-1 and /dev/cr-auto-3 instead of /dev/cr_home and /dev/cr_ephemeral this solves the issue in my case. Seems something about naming those crypto-devices changed between 42.3 and 15.0. I couldn't find any hints on this in the release notes, though.

(In reply to Matthias Bach from comment #15)
> I just ran a quick test. If I switch out into one of the other consoles
> during the selection screens and modify the /etc/fstab to point to
> /dev/cr-auto-1 and /dev/cr-auto-3 instead of /dev/cr_home and
> /dev/cr_ephemeral this solves the issue in my case. Seems something about
> naming those crypto-devices changed between 42.3 and 15.0. I couldn't find
> any hints on this in the release notes, though.

Arvin. Shouldn't libstorage-ng be able to find the devices by their cr_home and cr_ephemeral names? Any clue why are they detected just as cr-auto-1 and cr-auto-3?

Looks like a duplicate of bug #1094963. (See https://bugzilla.suse.com/show_bug.cgi?id=1094963#c14).

I agree this is a duplicate of bug#1094963 so it should be fixed by now (late for the Leap 15 release, sorry). Check the other bug report for details.

*** This bug has been marked as a duplicate of bug 1094963 ***

(In reply to Martin Vidner from comment #5)
> > B-up (back-up) is only used when I want to run a back-up. Should I plug in the USB and try again ?
> 
> I suspect connecting the device will make the upgrade succeed. Definitely
> worth trying.
> 
> Ah, I see. Also, man 5 fstab says:
> >  nofail     do not report errors for this device if it does not exist.
> 
> Apparently we should take a hint from that option :-/

Grand Sunny Sunday,
This bug is marked as closed / RESOLVED so I gave it a run and I see the same issues as I reported on the 26th May. If it is resolved please tell me what I need to do to get my update to work ?

Many Thanks,

__R

(In reply to Ancor Gonzalez Sosa from comment #18)
> I agree this is a duplicate of bug#1094963 so it should be fixed by now
> (late for the Leap 15 release, sorry). Check the other bug report for
> details.
> 
> *** This bug has been marked as a duplicate of bug 1094963 ***

Grand Sunny Sunday,

I do not agree this bug is the same as bug 1094963, can you look again now that bug 1094963 has been fixed and tell me your thoughts please.

__R

(In reply to Dick Waite from comment #19)
> 
> Grand Sunny Sunday,
> This bug is marked as closed / RESOLVED so I gave it a run and I see the
> same issues as I reported on the 26th May. If it is resolved please tell me
> what I need to do to get my update to work ?

It's fixed in recent versions of the yast2-storage-ng and yast2-update packages, as commented in the comment 29 of the other bug [1]

But the Leap 15.0 ISO is never updated after the official release. So getting an up-to-date installer (i.e. including the improvements in those two new packages) to perform an upgrade with it is not so easy. Let me offer you three completely unsupported ways. Use any of them at your our responsibility. In other words, don't blame me if any of these methods eats your dog.


A) Use the YaST self-update feature to get a completely up-to-date (but not so well tested) version of the installer.

Boot with the Leap 15.0 ISO and add this boot option while selecting the "Upgrade" option in Linuxrc (that is, in this screen[2])

SELF_UPDATE=https://download.opensuse.org/repositories/home:/ancorgs:/test_self_update:/Leap_15.0/openSUSE_Leap_15.0/

Proceed as usual from there. You will need to tell the installer you trust that unofficial repository.


B) Download the following packages from the Leap 15.0 update repository (or from YaST:Head if the packages in the update repo are not recent enough) and make a driver update disk (DUD) out of them:

yast2-storage-ng, yast2-update, libstorage-ng1, libstorage-ng-ruby and libstorage-ng-lang

For more information about how to create a DUD and how to boot applying it, check https://en.opensuse.org/SDB:Linuxrc#p_dud


C) Using the Leap 15 Live images to perform an update. The live images are refreshed once in a while, so they can contain an installer that is more up-to-date than the installer in the Leap 15 normal ISO.

Of course, first you need to make sure the current live are fresh enough to contain the desired versions of the desired packages. That is still not true at the moment of writing this. But some of the upcoming versions of the Live images (let's say in one month from now) should contain an installer that is up-to-date enough.

Moreover, performing an upgrade with the installer on the live versions is possible but tricky.

First of all, run the image and apply any update displayed by the update applet in the systray (if any).

Then you need to run a root shell ("System" -> "Terminal - Super User Mode" in the KDE menu, something similar for Gnome) and edit the file /usr/sbin/start-install.sh adding this before the last line

echo "Upgrade: 1" >> /etc/install.inf

So (just to double-check) the two last lines of that file should look like:

echo "Upgrade: 1" >> /etc/install.inf
/usr/lib/YaST/startup/YaST2.call installation initial

Then use the "Installation" icon from the desktop. That will run the installer as usual in the Live images, but in Upgrade mode thanks to our modification of the start-install.sh file.


So if you are brave enough, use any of those methods to upgrade and confirm whether your bug is indeed a different one from bug#1094963. If the patched installation works, then it's the same bug and it's already solved in YaST (even if the fix didn't arrive on time to be included in Leap 15.0 ISO).

[1] https://bugzilla.suse.com/show_bug.cgi?id=1094963#c29
[2] https://openqa.opensuse.org/tests/677527#step/bootloader/4

(In reply to Ancor Gonzalez Sosa from comment #21)
...
> A) Use the YaST self-update feature to get a completely up-to-date (but not
> so well tested) version of the installer.
...
> B) Download the following packages from the Leap 15.0 update repository (or
> from YaST:Head if the packages in the update repo are not recent enough) and
> make a driver update disk (DUD) out of them:
...
> C) Using the Leap 15 Live images to perform an update. The live images are
> refreshed once in a while, so they can contain an installer that is more
> up-to-date than the installer in the Leap 15 normal ISO.

Thanks.

Question.

What would happen with the Netinstall CD? I understand it downloads the actual installer. Does it get an updated YaST automatically? If not, can it be told to download an updated YAST installer?

(I was told the L15 Live uses the same installer as the Netinstall CD)

(In reply to Carlos Robinson from comment #22)
> What would happen with the Netinstall CD? I understand it downloads the
> actual installer. Does it get an updated YaST automatically? If not, can it
> be told to download an updated YAST installer?

The NET installer downloads the YaST boot image from https://download.opensuse.org/distribution/leap/15.0/repo/oss/

Which means it always uses the GM version without any updates released later.

> 
> (I was told the L15 Live uses the same installer as the Netinstall CD)

The difference is that the Live ISO media are rebuilt from time to time, so they might contain the released maintenance updates.

(In reply to Ancor Gonzalez Sosa from comment #21)
> SELF_UPDATE=https://download.opensuse.org/repositories/home:/ancorgs:/
> test_self_update:/Leap_15.0/openSUSE_Leap_15.0/
> 
> Proceed as usual from there. You will need to tell the installer you trust
> that unofficial repository.

Or alternatively you might use the "insecure=1" boot option, see https://en.opensuse.org/SDB:Linuxrc#p_insecure

(In reply to Ancor Gonzalez Sosa from comment #21)
> SELF_UPDATE=https://download.opensuse.org/repositories/home:/ancorgs:/
> test_self_update:/Leap_15.0/openSUSE_Leap_15.0/

How high are the chances to make mistakes when typing this? ;)
Did I mention OBS repo https-to-http redirection bug 1107994 already?
RPMs signed with your home project key?
No thanks, then the installer will complain about "broken" packages with "NOKEY" in the details when trying to verify the missing key.

A DUD from official update RPMs is the way to go IMHO.

See:
> https://github.com/sriemer/spars-coding/tree/master/opensuse_fixes/leap15

Works fine for me.

(In reply to Sebastian Parschauer from comment #25)
> (In reply to Ancor Gonzalez Sosa from comment #21)
> > SELF_UPDATE=https://download.opensuse.org/repositories/home:/ancorgs:/
> > test_self_update:/Leap_15.0/openSUSE_Leap_15.0/
> 
> How high are the chances to make mistakes when typing this? ;)
> Did I mention OBS repo https-to-http redirection bug 1107994 already?
> RPMs signed with your home project key?
> No thanks, then the installer will complain about "broken" packages with
> "NOKEY" in the details when trying to verify the missing key.

Of course, this is not an official solution. openSUSE Leap does not have an official channel for the installer self-update or to release official DUDs. So far, bugs in the installer can only be fixed in the next version of Leap (and in Tumbleweed, of course). And that's what we (the YaST team) did.

Additionally, I wanted to offer an unofficial best-effort "bonus" using the self-update mechanism. Feel free to not use it, but there is no official alternative in the openSUSE policies (other than using the NET ISO, the only official image that gets refreshed once in a while).

> A DUD from official update RPMs is the way to go IMHO.

I have never seen such thing happening (an official DUD published in the project page or anything like that).

(In reply to Ancor Gonzalez Sosa from comment #26)
> ... (other than using the NET ISO, the only
> official image that gets refreshed once in a while).

Sorry, I meant the Live images, not the NET one.