Bug 153576

Do you know why it fails? The cipher shouldn't have been changed since 10.0. Is it possible to manually mount the partition?

I don't know why it fails, else I would have written it. I have no knowledge about this stuff.

try the following (assuming the crypto-fs to be on sda8)

%modprobe twofish
%losetup -d /dev/loop0                      # assures loop0 is not busy 
%losetup -e twofish256 /dev/loop0 /dev/sda8 # should ask for pw here
%mount /dev/loop0 /mnt

Does the output indicate the error? A failed ioctl-call would indicate a problem with the cipher-module, if the filesystem cannot be mounted in the last step, it's probably another cipher here.

This time mounting worked after fixing /etc/cryptotab, maybe I made a mistake the last time.

But /etc/cryptotab was changed again by YaST2 to the wrong twofishSL92 entry.

The rewrite should only happen if upgrading from <= 9.2. Could be a zypp related bug if the old proddb is used to determine the previously installed product. yast logs should show which version yast thinks it's upgrading.

OK, Thorsten, attach the logs, after this I'll reassign.

Created attachment 70841 [details]
y2logs.tgz

Klaus: Please check comment #5

The problem is inside ./pkg-bindings/src/Target.cc
YCPList PkgModuleFunctions::TargetProducts () already has a warning pointing on this (indirectly).

The returned YCPList does not contain all keys, especially the version of the product.

In ./update/src/modules/Update.ycp the function GetProductName () expects this information. The version falls back to "?" and so the check for a specific version in the function Update () in ./storage/storage/src/modules/Storage.ycp is not correct and leads to above mention problem.

Klaus, which keys are supported in ./pkg-bindings/src/Target.cc TargetProducts() ?

Patch proposal:

Index: Target.cc
===================================================================
--- Target.cc   (revision 28955)
+++ Target.cc   (working copy)
@@ -302,8 +302,10 @@
        if (it->status().isInstalled() )
        {
            YCPMap prod;
-#warning TargetProducts doesn't return all keys
-           prod->add( YCPString("name"), YCPString( product->name() ) );
+           prod->add( YCPString("label"),       YCPString( product->displayName() ) );
+           prod->add( YCPString("vendor"),      YCPString( product->vendor() ) );
+           prod->add( YCPString("name"),        YCPString( product->name() ) );
+           prod->add( YCPString("version"),     YCPString( product->edition().version() ) );
            prod->add( YCPString("relnotesurl"), YCPString( product->releaseNotesUrl().asString() ) );
            products->add(prod);
        }

I have added the key "version" in yast2-pkg-bindings-2.13.26, which should fix the blocker.

This makes TargetProducts support 50% bigger!!! (product, version, relnotesurl) but Product.ycp wants quite some more. But the ycp code does not use it anyway.

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

Looks like this problem still is not quite fixed.

The log from #158618 shows that there is still something wrong with the old version on beta8:

Storage.ycp:4353 Update old:$["name":"?", "nameandversion":"? ?", "version":"?"] new:$["major":10, "minor":1, "name":"SUSE LINUX", "nameandversion":"SUSE LINUX 10.1", "version":"10.1"]

Thanks for looking it up, I will have a look tomorrow.

Jirka, in Update::GetProductName, Pkg::TargetProducts returns an empty list. I see that you made some changes in r29075. Does it mean Pkg::TargetProducts is obsolete? Or can you reimplement it in terms of ResolvablePropertiesEx?

The complex case here is upgrading a system which had addon products. Fortunately we do not have to get that one right for this release yet :-)

Another aspect of this bug is that the old product map is already filled correctly in RootPart::GetproductName - cut-n-paste programming :( - search the logs for "nameandversion". But I don't know the module dependencies enough to tell whether we can use that info in Update.

TargetProduct cannot return any data from older release - the reason is that it is not able to read all metadata stored on the disk.

Martin, as you already investigated, does what you wrote mean that if I delete Update::GetProductName and use RootPart::GetProductName instead, the bug will be solved?

/etc/cryptotab again contained twofishSL92 after update from beta6 -> beta8 :-(

I'll add this bug to the most annoying bugs because it can cause filesystem corruption.

> Martin, as you already investigated, does what you wrote mean that if I
> delete Update::GetProductName and use RootPart::GetProductName instead,
> the bug will be solved?

Why not fix Pkg::TargetProducts? If that's hard, I can fix it tomorrow by *moving* RootPart::GetProductName to replace Update::GetProductName.

(Pkg::TargetProducts is explained in comment 18, I missed that)

Fixed in yast2-update-2.13.9

Encryption alghorythmus still ok after updating beta8 to beta9 - your fix works :-)

Thanks!

The bug is there again when updating to 10.2 alpha5plus.

OK, I'll check it in 10.2 Beta1

I see. Storage module uses keys "major" and "minor" but such keys are not defined in the Update::installedVersion map which is used in Storage. That's why it considers system version to be major==0, minor=0.

Thomas, I'll add them into the Update module but I suggest you should also add some checking into your function Storage::Update().

Created attachment 102678 [details]
my YaST logs for completeness

Updating 10.0 GM DVD to 10.2 Beta2 DVD

Thomas, there might be a problem when upadting from SLE or SLD. In this case, there is only a major version (9, 10) but no minor one despite the fact that SLE 10 has the same base as openSUSE 10.1. Any proposed solution?

The interface to function Storage::Update was designed some years ago (2004, 
I think for SLES9) and the maps contained keys "major" and "minor" back then.
So something must have changed since then without telling me.

I will add a check that logs an error when they keys are missing.

Ad comment#29:

SLES9 used code base of SL 9.1 and SLES10 code base of SL 10.1.
Why not simply add an entry for "minor":1 in these two cases.

Ad comment #30
  Martin has probably changed something - see comment #21

Ad comment #31
  Because in this case, the information would have to be somehow hardcoded into the source code. Update module take this information from SuSERelease module which thakes that from /etc/SuSE-release from the installed system.

  It would be better to handle it this way: If a major version is defined and a minor one isn't - it 'must be' SLES/SLED. But I'd still be just guessing... I'd rather create another key like "enterprise":true in this case than to guess a minor version.

But since we need to compare the minor number to decide which updates need
to be done it is necessary to hardcode it somewhere. Of course I could also 
hardcode minor number corresponding to SLES in Storage::Update function itself.
Should i?

Somewhere the knowledge that SLES9 is SL 9.1 and SLES10 is SL 10.1 needs to 
be hardcoded anyway and it is IMHO no problem to hardcode it since these 
facts will and can not change.

I guess, that hardcoding minor=1 if minor is not defined and major is defined because Update itself doesn't need it anywhere. These major/minor numbers are there just because of Storage.

Additionally, you would know that it isn't openSUSE but an enterprise version. That's even better because, for instance, openSUSE 10.1 is not exactly the same as SLE 10.

Ok, I added a mapping to minor number if no "minor" entry is present to
Storage::Update.

Fixed in yast2-update-2.14.2 (openSUSE 10.2) and yast2-update-2.13.38 (SLE 10 SP1).

Comment #26 filed as FATE request #301717.

Thomas, just a reminder, fix it also for SLE 10 SP1, please.

Fix will be in 2.13.74 (SLES10 SP1) and 2.14.14 (SL 10.2)