10:45 a.m.
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
11:05 p.m.
On Jun 4, 2014, at 10:16 AM, Matthew Miller <mattdm(a)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
3:26 p.m.
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
11:47 a.m.
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
11:31 a.m.
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
--
Gary Stainburn
Group I.T. Manager
Ringways Garages
http://www.ringways.co.uk
11:16 a.m.
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
8:41 a.m.
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
9:24 a.m.
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.
2:56 a.m.
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.
1:58 p.m.
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
3673
days inactive
3674
days old
9 comments
6 participants
participants (6)
-
Chris Murphy -
Doug -
Gary Stainburn -
Matthew Miller -
Rahul Sundaram -
Trever L. Adams