Posts Tagged yum

I like uptime

Sadly, reboots must occur.

But that doesn’t mean I can’t wait for a nice time.

[[email protected] ~]# uptime
 16:10:10 up 75 days, 23:59, 2 users, load average: 1.06, 0.69, 0.33
[[email protected] ~]# uptime
 16:10:42 up 76 days, 0 min, 2 users, load average: 0.59, 0.62, 0.32
[[email protected] ~]# reboot

, ,

No Comments

Upgrading to Fedora 16 Beta with yum

So… I saw that Fedora 16 was out in Beta. I decided to try out the supposed Xen dom0 capability, using my old 1U. It had Fedora 15 installed, but nothing on it, so I just decided to blow it all away.

To start, I went and downloaded the Live CD. First problem: I grabbed the x64 version. NOT the i686 version which my 1U needs. Took out the ‘rhgb’ option in the boot line, wondering why it wasn’t starting up, only to be greeted with “This machine requires an i386 kernel, while this kernel is x86_64.”

And that was Derp 1 of the day.

Ok… so do a preupgrade or similar. Reboot into Fedora 15, ssh in. I completely forget about preupgrade, and jump straight to upgrading with yum. A few package upgrade errors where “libnih” can’t find dependencies, easily fixed by doing a “yum provides libnih” followed by “yum erase libnih” and repeat for the packages with errors.

So I’m merrily following the “official upgrade using yum guide“, and I run into another error. This time it’s more serious. Having just followed the instructions to wipe out grub, the bootloader, to my horror I find I can’t install grub2, the new bootloader.

And this is derp 2 of the day: I don’t narrow down the cause. I see “Cannot retrieve metalink for repository: fedora”, and immediately think “Oh, crud, because of the yum upgrade, it can’t determine the release version! And I can’t reboot because the frakkin’ bootloader’s not there!”

Except, it wasn’t a problem with the repo files. The system’s DNS resolving went down. I have no clue why, but I’m just thankful that my SSH session remained open. Add the IPs for and to /etc/hosts, and grub2 downloads & installs.

So far so good.

/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg was taking a suspiciously long time, though, it’s giving messages similar to the ones in this bug. But it seems to be smart enough to test what kernels can support Xen, though it’s not too smart about Xen itself – It has 3 menu entries for Xen, using ‘xen.gz’, ‘xen-4.gz’ and ‘xen-4.1.gz’, all of which are symlinked to ‘xen-4.1.1.gz’. Which itself has an entry. So now I’ve got multiple entries for Xen all pointing to the same Xen install.

As for the grub2-install, using /dev/mapper/pdc_dbijaaabh as the boot drive failed. Using /sbin/grub2-install /dev/disk/by-id/ata-ST3160812A_5LS9P57M also didn’t work.

But, it boots! Still using legacy grub (didn’t wipe out the bootsector, thank god), but, IT BOOTS! 😀

(Also, I’m getting memory errors in dmesg and /var/log/messages. Yay. But that’s a hardware problem, and this system only has to live for another 8 months anyway.)

, , ,

No Comments

When a yum update kills itself…

There’s a bunch of clean up to do.

New kernel isn’t working properly – boot from old one.

Try yum update again, get an error message about an existing transaction.

Have yum-utils already installed, so yum-complete-transactions is a command away.

Even after repeating it multiple times, yum still complains about broken packages.

Turns out yum died in the middle of cleanup, so old packages were still in the rpmDB.

Discovery of the day: package-cleanup –cleandupes will fix that error, even though the list of packages to remove looks very scary.

, ,

No Comments