Hi all,
Just a quick piece of advice.
If you try to fedup and the fedup doesn't work (completed but kernel panic on boot) don't try to 'yum erase' the duplicate RPM's. I goes through the uninstall process and removes all the GLIBC files and leaves you with a totally stuiffed server
On Wed, Jun 04, 2014 at 04:45:16PM +0100, Gary Stainburn wrote:
If you try to fedup and the fedup doesn't work (completed but kernel panic on boot) don't try to 'yum erase' the duplicate RPM's. I goes through the uninstall process and removes all the GLIBC files and leaves you with a totally stuiffed server
Yes indeed. Instead, use `package-cleanup --cleandupes` (possibly with the --noscripts flag if there are issues) from the yum-utils package.
On Wednesday 04 June 2014 17:16:54 Matthew Miller wrote:
On Wed, Jun 04, 2014 at 04:45:16PM +0100, Gary Stainburn wrote:
If you try to fedup and the fedup doesn't work (completed but kernel panic on boot) don't try to 'yum erase' the duplicate RPM's. I goes through the uninstall process and removes all the GLIBC files and leaves you with a totally stuiffed server
Yes indeed. Instead, use `package-cleanup --cleandupes` (possibly with the --noscripts flag if there are issues) from the yum-utils package.
I so wish I knew that one as I now can't log out because I know that if I do I can never log in again. I'm desparately trying to do whatever rescue I can without being able to actually load anything
On 06/04/2014 11:45 AM, Gary Stainburn wrote:
Hi all,
Just a quick piece of advice.
If you try to fedup and the fedup doesn't work (completed but kernel panic on boot) don't try to 'yum erase' the duplicate RPM's. I goes through the uninstall process and removes all the GLIBC files and leaves you with a totally stuiffed server
I thought Fedup was the name of the corporation resulting from the takeover of Federal Express by United Parcel Service. No?
--dm
Hi
On Wed, Jun 4, 2014 at 12:47 PM, Doug wrote:
I thought Fedup was the name of the corporation resulting from the takeover of Federal Express by United Parcel Service. No?
Just in case, this was a serious question, the answer is no
https://fedoraproject.org/wiki/FedUp
Rahul
On 06/04/2014 10:31 AM, Gary Stainburn wrote:
On Wednesday 04 June 2014 17:16:54 Matthew Miller wrote:
On Wed, Jun 04, 2014 at 04:45:16PM +0100, Gary Stainburn wrote:
If you try to fedup and the fedup doesn't work (completed but kernel panic on boot) don't try to 'yum erase' the duplicate RPM's. I goes through the uninstall process and removes all the GLIBC files and leaves you with a totally stuiffed server
Yes indeed. Instead, use `package-cleanup --cleandupes` (possibly with the --noscripts flag if there are issues) from the yum-utils package.
I so wish I knew that one as I now can't log out because I know that if I do I can never log in again. I'm desparately trying to do whatever rescue I can without being able to actually load anything
yum check
Then do yum install for anything missing. If you have missing dependencies for that, contact me in private, I can provide specific files for x86_64. That is assuming you can't fetch rpms and extract the files manually.
I have had this happen even with the "proper" clean up methods several times. It is a royal pain.
Trever
On Jun 4, 2014, at 10:16 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Wed, Jun 04, 2014 at 04:45:16PM +0100, Gary Stainburn wrote:
If you try to fedup and the fedup doesn't work (completed but kernel panic on boot) don't try to 'yum erase' the duplicate RPM's. I goes through the uninstall process and removes all the GLIBC files and leaves you with a totally stuiffed server
Yes indeed. Instead, use `package-cleanup --cleandupes` (possibly with the --noscripts flag if there are issues) from the yum-utils package.
I wonder if this will work booting a live cd, mounting the broken system parts [1], and chrooting it, then running package-cleanup?
Chris Murphy
[1] grep mount /var/log/anaconda/anaconda.program.log will give an example of how to mount the system the way the installer does it. For a btrfs system it looks like this:
14:45:00,060 INFO program: Running... mount -t btrfs -o subvol=root /dev/sda3 /mnt/sysimage 14:45:00,289 INFO program: Running... mount -t ext4 -o defaults /dev/sda2 /mnt/sysimage/boot 14:45:00,477 INFO program: Running... mount -t vfat -o umask=0077,shortname=winnt /dev/sda1 /mnt/sysimage/boot/efi 14:45:00,700 INFO program: Running... mount -t bind -o bind,defaults /dev /mnt/sysimage/dev 14:45:00,863 INFO program: Running... mount -t devpts -o gid=5,mode=620 devpts /mnt/sysimage/dev/pts 14:45:01,039 INFO program: Running... mount -t tmpfs -o defaults tmpfs /mnt/sysimage/dev/shm 14:45:01,218 INFO program: Running... mount -t btrfs -o subvol=home /dev/sda3 /mnt/sysimage/home 14:45:01,416 INFO program: Running... mount -t proc -o defaults proc /mnt/sysimage/proc 14:45:02,901 INFO program: Running... mount -t bind -o bind,defaults /run /mnt/sysimage/run 14:45:03,072 INFO program: Running... mount -t sysfs -o defaults sysfs /mnt/sysimage/sys 14:45:03,241 INFO program: Running... mount -t selinuxfs -o defaults selinuxfs /mnt/sysimage/sys/fs/selinux 14:45:03,429 INFO program: Running... mount -t btrfs -o subvol=var /dev/sda3 /mnt/sysimage/var
On Wednesday 04 June 2014 21:26:36 Trever L. Adams wrote:
yum check
Then do yum install for anything missing. If you have missing dependencies for that, contact me in private, I can provide specific files for x86_64. That is assuming you can't fetch rpms and extract the files manually.
I have had this happen even with the "proper" clean up methods several times. It is a royal pain.
Trever
Thanks for the offer Trevor, I'm going to need all the help I can.
The situation is that I've currently got one open terminal session over ssh and can do anything that is built into BASH. So far I've managed to 'cat' a number of config files and copy/paste into gvim on a separate box.
I can't run many command (even ls fails) because of missing GLIBC libraries.
The system is running on a software RAID setup with sdb being a mirror of sda.
I've pretty much decided that the server is in such a state that it's going to be easier to build a new one. I'm just loathed to log out my session as I know I won't be able to log in again, and I'm loathed to reboot to a LIVEDVD in case I can't mount the filesystems afterwards
The system successfully fedup from 17 to 18 but then failed and got messy doing 18 to 19. It now thinks the RPM's for 18 are installed but the actual contents of the RPM's were removed trying to clear away the 19 ones.
On 06/05/2014 01:56 AM, Gary Stainburn wrote:
On Wednesday 04 June 2014 21:26:36 Trever L. Adams wrote:
yum check
Then do yum install for anything missing. If you have missing dependencies for that, contact me in private, I can provide specific files for x86_64. That is assuming you can't fetch rpms and extract the files manually.
I have had this happen even with the "proper" clean up methods several times. It is a royal pain.
Trever
Thanks for the offer Trevor, I'm going to need all the help I can.
The situation is that I've currently got one open terminal session over ssh and can do anything that is built into BASH. So far I've managed to 'cat' a number of config files and copy/paste into gvim on a separate box.
I can't run many command (even ls fails) because of missing GLIBC libraries.
The system is running on a software RAID setup with sdb being a mirror of sda.
I've pretty much decided that the server is in such a state that it's going to be easier to build a new one. I'm just loathed to log out my session as I know I won't be able to log in again, and I'm loathed to reboot to a LIVEDVD in case I can't mount the filesystems afterwards
The system successfully fedup from 17 to 18 but then failed and got messy doing 18 to 19. It now thinks the RPM's for 18 are installed but the actual contents of the RPM's were removed trying to clear away the 19 ones.
Gary,
Wow. If you are missing glibc, I am not sure I can help you. You need to find a static mount command and cp (possibly on rescue images). If you can do that, just suck the glibc stuff onto a flash drive with those and move them over. From there, you should be able to start rebuilding.
Otherwise, you are correct, likely just better to copy data and configuration information off the system and reload.
Good luck, Trever
On Thursday 05 June 2014 14:41:57 Trever L. Adams wrote:
Wow. If you are missing glibc, I am not sure I can help you. You need to find a static mount command and cp (possibly on rescue images). If you can do that, just suck the glibc stuff onto a flash drive with those and move them over. From there, you should be able to start rebuilding.
Otherwise, you are correct, likely just better to copy data and configuration information off the system and reload.
Good luck, Trever
Thanks for your help Trevor
I have managed to
a) start a new server install with the software RAID I wanted - although I do get a worrying error on boot as posted in another thread, but it seems to work perfectly, even headless.
b) used sysresccd to boot the old server and using advice elsewhere on this list got the mount commands out of anaconda.program.log and mounted the old RAID partitions.
I've managed to successfully rsync off /home /etc and /root and I'm in the process of rsyncing the Bacula storage contents (long job as over 2TB)
The Postgresql backup and an old tgz I already had on my backup backup server :-)
Now it's just a case of working through each service and configuring it correctly. My only concern is version dependencies on the postgresql database and the Bacula Director config files but they're doable.
-
Chris Murphy -
Doug -
Gary Stainburn -
Matthew Miller -
Rahul Sundaram -
Trever L. Adams