[QUOTE=malcolmlewis;33766]Hi
Mount as a loop device and browse around… for example;
[snip]
Run some random md5 or sha256 sum checks on files in both source and destination to compare, but if the dd image mounts without issues, it should (in theory) be ok.[/QUOTE]
Okay, cool. I have images of all the system directories and they seem to be intact.
Either tomorrow or early next week, I’m going to zypper dup… wish me luck! I’ll be back soon with the results!
One of the packages I was trying to install back when I was trying to get dansguardian to make properly was glibc-devel. And apparently the zypper dup wanted to get rid of glibc and install the one that came from the SUSE repository.
Well, the one it installed with the zypper dup is glibc 2.11… and all the rpm upgrades that followed the installation of glibc 2.11 failed because apparently they require glibc 2.14.
I have a backup rpm of glibc 2.14 from the yast backup I ran before I did the zypper dup… but I think the repo for it is openSUSE. Should I install glibc 2.14 from my backup, then retry the zypper dup, and when the zypper dup removes glibc 2.14 and fails the rest of the upgrade again, should I then open a screen session, re-install glibc 2.14, and try to resume the upgrade with a retry command??
Well / for a start, somehow we need to get glibc back to SLE… but
there must be some packages still lurking somewhere…
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.27-27-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
[QUOTE=malcolmlewis;33821]Hi
Oh and probably /usr as well.[/QUOTE]
Okay. It will probably have to wait until I can do an off-hours maintenance window (Monday, probably) to boot into a liveCD rescue environment and do the restoration. I tried mounting the external drive I did my dd backups to, and mount required glibc 2.14 as well…
Thank you, by the way, for everything you’ve done so far to help me. It’s very, very appreciated. It’s scary, being given admin responsibilities on a system you’re only intermediately familiar with… and didn’t build yourself!
One of the packages I was trying to install back when I was trying to
get dansguardian to make properly was glibc-devel. And apparently the
zypper dup wanted to get rid of glibc and install the one that came from
the SUSE repository.
Well, the one it installed with the zypper dup is glibc 2.11… and all
the rpm upgrades that followed the installation of glibc 2.11 failed
because apparently they require glibc 2.14.
I have a backup rpm of glibc 2.14 from the yast backup I ran before I
did the zypper dup… but I think the repo for it is openSUSE. Should I
install glibc 2.14 from my backup, then retry the zypper dup, and when
the zypper dup removes glibc 2.14 and fails the rest of the upgrade
again, should I then open a screen session, re-install glibc 2.14, and
try to resume the upgrade with a retry command??[/color]
Which repos do you have enabled? Please post the output from “zypper lr -u”
I’m guessing you have some repos for openSUSE added that are offering
differing versions of some of the SLES-related packages and possibly
even have some of those alternatives already installed, neither of which
are a good idea.
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
[QUOTE]
Which repos do you have enabled? Please post the output from “zypper lr -u”
I’m guessing you have some repos for openSUSE added that are offering
differing versions of some of the SLES-related packages and possibly
even have some of those alternatives already installed, neither of which
are a good idea.
HTH.
Simon
SUSE Knowledge Partner[/QUOTE]
Simon,
Thanks for the reply. I can’t post the output of zypper lr -u because zypper is currently broken due to the failed glibc 2.14 dependency. All zypper commands now return with an error.
I can, however, give you the output of zypper ref that I pulled and saved off before running zypper dup:
Repository 'SUSE-Linux-Enterprise-Server-11-SP3 11.3.3-1.138' is up to date.
Repository 'dell-omsa-hw' is up to date.
Repository 'dell-omsa-hwindep' is up to date.
Repository 'SLES11-SP3-Pool' is up to date.
Repository 'SLES11-SP3-Updates' is up to date.
All repositories have been refreshed.
Please note that this zypper ref was pulled after I had gone in and removed an openSUSE repository that was mistakenly added. The repos in ^ that list are the only active ones on my system right now.
Hi
Boot from the SP3 Install dvd in rescue mode, just to make sure
everything is the same…
No worries, we are here to help
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.27-27-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
[QUOTE=malcolmlewis;33830]Hi
Boot from the SP3 Install dvd in rescue mode, just to make sure
everything is the same…
No worries, we are here to help
[/QUOTE]
I’m sorry, but what do you mean to make sure everything is the same? When should I boot with the SUSE rescue disk (before or after I dd restore) and what should I check for?
Thanks for the reply. I can’t post the output of -zypper lr -u- because
zypper is currently broken due to the failed glibc 2.14 dependency. All
zypper commands now return with an error.
I can, however, give you the output of -zypper ref- that I pulled and
saved off before running zypper dup:
Code:
Repository ‘SUSE-Linux-Enterprise-Server-11-SP3 11.3.3-1.138’ is up to date.
Repository ‘dell-omsa-hw’ is up to date.
Repository ‘dell-omsa-hwindep’ is up to date.
Repository ‘SLES11-SP3-Pool’ is up to date.
Repository ‘SLES11-SP3-Updates’ is up to date.
All repositories have been refreshed.
Please note that this -zypper ref- was pulled after I had gone in and
removed an openSUSE repository that was mistakenly added. The repos in ^
that list are the only active ones on my system right now.[/color]
Hmm with zypper being broken we can’t run zypper se -si | grep “(System
Packages)” which would identify packages that have been installed from
somewhere other than the currently installed correct repos.
You could check /var/log/zypp/history to see which packages have been
installed from the openSUSE repo - if you know the name used for the
repo you should be able to grep for that.
Does the rpm command work or is that also now broken?
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
Attached you will find a copy of my zypper history log. There are openSUSE items in there but I’m not sure what precisely I’m looking for…[ATTACH]170[/ATTACH]
[QUOTE=teds;33832]I’m sorry, but what do you mean to make sure everything is the same? When should I boot with the SUSE rescue disk (before or after I dd restore) and what should I check for?
Thanks,
Ted[/QUOTE]
Hi
If you boot from the SP3 DVD in rescue mode, just zypper, glibc etc will be the correct level, so hopefully can check the files as indicated by Simon to see if can find out whats up (Perhaps use chroot). You should use the rescue system for your dd command as well.
[QUOTE=malcolmlewis;33836]Hi
If you boot from the SP3 DVD in rescue mode, just zypper, glibc etc will be the correct level, so hopefully can check the files as indicated by Simon to see if can find out whats up (Perhaps use chroot). You should use the rescue system for your dd command as well.[/QUOTE]
Okay, that makes sense, thanks. Am I able to use the rescue disk to reinstall rpm packages?
Hi
I’ve never tried it but if push comes to shove, booting in rescue mode,
chrooting and binding the partition should allow it…
But I think getting back to where it was and looking again at the file
list again, and try and get the glibc rolled back to start with.
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.27-27-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Okay so you’ll need to boot in rescue mode as per Malcolm’s advice.
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
------------------------------------------------------------------------[/QUOTE]
Okay, cool. Thank you again. When I get into the rescue mode, what kind of repair should I run from there? Or should I just dd restore the /usr / and /var filesystem partitions I backed up before performing the zypper dup?
[QUOTE=malcolmlewis;33840]Hi
I’ve never tried it but if push comes to shove, booting in rescue mode,
chrooting and binding the partition should allow it…
But I think getting back to where it was and looking again at the file
list again, and try and get the glibc rolled back to start with.[/QUOTE]
Okay. Once I’m in the rescue environment, what kind of repair can I run? Sorry if this seems like a redundant question, I haven’t really used the rescue CD for anything before.
Hi
Just dd you backup images back, restart the system and will start
again…
–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.1|GNOME 3.16.2|4.1.27-27-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!