On Mon, 2011-06-06 at 12:37 -0700, Joe Zeff wrote: > On 06/06/2011 10:11 AM, Michael H. Warfield wrote: > > To the preupgrade devs - I would strongly recommend you test with a > > known broken machine that has dependency problems that anaconda can NOT > > resolve and make sure it gracefully stops and generates sane, > > intelligible error messages... The current avidmux is a good place to > > start. > It's good to see that you're making progress and, if not out of the > tunnel yet you can at least tell that the light isn't an on-coming train. > If you haven't yet, I'd suggest putting in a bug report against > preupgrade because AFAIK none of the appropriate devs are on this list. I have not as yet, as I thought I might extract more from the corpse. Unfortunately, seems twas not to be (though I haven't totally given up quite yet). My latest effort... I did the following... rpm -qa --qf | sort -u > rpm.list Then yum reinstall `cat rpm.list` (I even turned off my cacher forcing it to re-download everything from the net from scratch.) Re-downloaded over 3800 packages. It then began to rerun the install phase and blew its brains out after about 2400 of the packages were installed with the stupid "Transaction would be destructive error" and landed me back at the ^D emergency mode prompt jail. Sigh. Here we go again. I know the drill... My entire domain is named after caves in Colossal Caverns Adventure. You're in a maze of twisty little passages all different. I know the drill all too well. Logged back in. Ran yum-complete-transaction. It had a lot to do with just about 1000 packages to rum after the LAST time systemctl committed harri karri and, this time, ran to completion with no errors. Still no joy... Rebooting still lands me back in the emergency mode hell. Running "systemctl default" still results in "Transaction would be destructive". I think systemd / systemctl is what's destructive on first principle. PoS. Right now, I'm beginning to believe it's this whole systemd systemctl garbage that's a crock of shit that stinks to high heaven. That's where the crashes are. The old SYSV scripts at least WORKED and didn't screw you over. That yum reinstall is telling me exactly what's broken and why anaconda hurled chunks earlier. It's that systemd setup that's hosed and blew up with no warning. It blew up in the middle of the recovery. If it did something like that in the middle of anaconda it's no wonder the machine is a steaming pile of molten RAM and disk. And still... THAT even took less time that preupgrade took on the first pass, even with the entire fresh redownload. Someone has done something seriously wrong in preupgrade. It may work in 99.99% of the cases but a single case of destroying a machine like this is simply inexcusable. Something that critical must be failsafe, and it's apparent to me this is not failsafe. Even if the ultimate fault in this case is systemd / systemctl, the bottom line at the end of the day is that preupgrade / anaconda did not detect / resolve the conflict / failure before you gave up control of the machine and before it was too late and irrecoverable. As much of a hassle as it has been at times over the years, the "yum upgrade" path has never, EVER left me with a machine that would not run. I can no longer say the same for preupgrade. Unfortunately, once THAT trust is lost, it can never be regained. Still trying to recovery the smoldering pieces but now getting very VERY close to just saying "screw it" and saving all 3TB off to another system and rebuilding this thing from scratch and restoring the data. That will take me a fraction of the time this has already even though the diagnostic data will be lost. Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw@xxxxxxxxxxxx /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF | possible worlds. A pessimist is sure of it!
Attachment:
signature.asc
Description: This is a digitally signed message part
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
