Everyone:
No complaints here. Just some insights from some recent experiences.
Bottom line: everyone who administers a Fedora system, should do a "clean install" or an effective system refresh (reinstalling the OS and all apps on a system having a separate /home partition) at least, I would say, once for every three new versions of Fedora. The "fedup" app lets too many minor faults accumulate in a system over time. Result: you are cheating yourself and your users of a good user experience.
Long ago I did a yum upgrade from F14 to F17. At first everything went swimmingly. And then I got the problem some of you might remember my complaining about: after two hours of operation, or maybe four or five or six hours if I were especially blessed (or as quickly as five minutes if I were under a special curse), new windows and dialog boxes would open as an unrelieved black. (Some KDE pop-up menus and notifications would pop up as a transparent outline.) I filed bug after bug after bug with Bugzilla. I re-filed with every new upgrade, which I accomplished with fedup. From F17->F18, F18->F19, and F19->F20, the problem persisted. Frankly I'm surprised the PTB's didn't CLOSE the bug as WONTFIX.
Two weeks ago I acquired a new, replacement machine for one of the two mini-towers on myh network. At the same time, the mouse on my F20 machine went wild, opening and closing windows and pushing buttons without my conscious input, so I couldn't stop it. Finally the mouse just quit. I figured out what happened: the mouse cable had frayed. Happily, with the new shipment, I got a USB mouse and a USB keyboard that I now can keep as spares.
But I decided to put F20 on another machine I had intended to replace. (It was a video-capture machine, and I needed a faster processor with more memory to do it properly.) I figured, why not go from a Pentium Dual-Core with 3 GB RAM and a 500-GB HDD to an Intel Core 2 Quattro with 8 MB RAM and a 1TB HDD?
This involved downloading and burning an F20 KDE live spin, inserting it into the intended replacement machine, and doing a complete system format--reclaim the drive space, put in the new automatic partition (50 GB for /, 8 GB of swap, 500-MB physical boot partition, and all the rest, 790 GB, for /home), install F20 from the Internet, and painstakingly replicate my old environment--or at least those parts of it I wanted. Fresh install of samba, Firefox, Thunderbird, gnucash, and any other application I used regularly.
I learned later that the old machine had been providing a crutch for samba connectivity to other machines on the network. When I retired the old machine, I lost that. Temporarily. I had to relearn everything I'd learned and forgotten about configuring samba by directly editing the smb.conf file. But now I have two machines--a desktop and a laptop--that can establish samba connectivity independently.
But that black rectangle problem I complained about? That is now solved!
And something else: dialog buttons have a new, "more modern" look. This should have come with the F19->F20 fedup upgrade. But it did not. It came with a clean install on a brand-new physical box, to which I have migrated all my "stuff."
I can only conclude that the yum upgrade introduced the first of several cumulative errors. Every upgrade since then, introduced another one, and another, and another. These errors pile up. They won't cause a catastrophic failure, but they will create several annoying problems you might never solve.
To the development team that gave us fedup, listen up! Your application is not taking care of all these little things.
With /home partitioned off separately (as an LVM partition), I assume I can install F21 "cleanly" in the / partition without risking losing the contents of /home or my access to them. But I still have to write down every modification I made to a configuration file--or else keep copies of those files in /home. They would include, I also assume, things like the files holding the UIDs, GIDs, and passwords for Users and Groups.
That's the only reason I don't plan to do a clean install every time. But I wouldn't mind doing it every other time, or every third time. To make sure these cumulative errors don't build up again.
Again, I offer this to provide some insight into problems that we "amateur system administrators" sometimes have.
Temlakos
On 06/18/2014 08:56 AM, Temlakos wrote:
With /home partitioned off separately (as an LVM partition), I assume I can install F21 "cleanly" in the / partition without risking losing the contents of /home or my access to them. But I still have to write down every modification I made to a configuration file--or else keep copies of those files in /home. They would include, I also assume, things like the files holding the UIDs, GIDs, and passwords for Users and Groups.
That's the only reason I don't plan to do a clean install every time. But I wouldn't mind doing it every other time, or every third time. To make sure these cumulative errors don't build up again.
Again, I offer this to provide some insight into problems that we "amateur system administrators" sometimes have.
I'll bet some of those issues might have gone away if you had removed the .* files in your home directory... .kde* , .gnome* .... compare a new user environment to your old existing user, to see if things are any different..
On 06/18/2014 09:15 AM, Paul Cartwright wrote:
On 06/18/2014 08:56 AM, Temlakos wrote:
With /home partitioned off separately (as an LVM partition), I assume I can install F21 "cleanly" in the / partition without risking losing the contents of /home or my access to them. But I still have to write down every modification I made to a configuration file--or else keep copies of those files in /home. They would include, I also assume, things like the files holding the UIDs, GIDs, and passwords for Users and Groups.
That's the only reason I don't plan to do a clean install every time. But I wouldn't mind doing it every other time, or every third time. To make sure these cumulative errors don't build up again.
Again, I offer this to provide some insight into problems that we "amateur system administrators" sometimes have.
I'll bet some of those issues might have gone away if you had removed the .* files in your home directory... .kde* , .gnome* .... compare a new user environment to your old existing user, to see if things are any different..
I don't deny I have noticed some differences. In fact, I took care to keep my migration of hidden files to a minimum. Things like the Thunderbird folder, that had all my e-mail accounts, local folders, and so on. And the config folders for two torrent peers I have loaded, so I didn't have to restart all my torrents.
The only thing is, every account on the old machine had the same black-rectangle problem. Nothing would do to solve it.
Nothing, that is, but the clean install. But I think what you're saying is, the secret might have been that I brought selected files to a new /home partition, not so much that I re-installed all applications.
Temlakos
Allegedly, on or about 18 June 2014, Temlakos sent:
The only thing is, every account on the old machine had the same black-rectangle problem. Nothing would do to solve it.
When you install a system, make an extra one or two test accounts. It gives you something to test with pristine user settings. And it gives you another account to log into should your normal one go belly up (just one reason why I make such accounts straight away).
On 06/18/2014 02:56 PM, Temlakos wrote:
Everyone:
No complaints here. Just some insights from some recent experiences.
Bottom line: everyone who administers a Fedora system, should do a "clean install" or an effective system refresh (reinstalling the OS and all apps on a system having a separate /home partition) at least, I would say, once for every three new versions of Fedora. The "fedup" app lets too many minor faults accumulate in a system over time. Result: you are cheating yourself and your users of a good user experience.
Why do you say this? You can, alternatively, just be diligent, handle .rpmorig and .rpmsave correctly, and generally know what you are doing.
My main installation was installed on Fedora 3, and then it was upgraded to 4, 5, 6, 7, 8, 9, 10, 12, 14, 15, 16, 17, 18, 19. It jumped on three different machines. It was born i386 and it is now x86_64. It moved from HDD to SSD. It moved from unencrypted storage to encrypted storage.
In many cases I've done what it is labeled as "you should not do this". Transformation of a i686 to x86_64 is considered impossible, for example. I never deleted my home directory (but the transition from KDE 3.5 to KDE 4.4 was hard indeed).
On Wed, 2014-06-18 at 08:56 -0400, Temlakos wrote:
With /home partitioned off separately (as an LVM partition), I assume I can install F21 "cleanly" in the / partition without risking losing the contents of /home or my access to them. But I still have to write down every modification I made to a configuration file--or else keep copies of those files in /home. They would include, I also assume, things like the files holding the UIDs, GIDs, and passwords for Users and Groups.
I just have an automated daily backup of /etc (on another machine just in case). Encrypt it if the other machine is not under your control.
poc
Allegedly, on or about 18 June 2014, Temlakos sent:
Bottom line: everyone who administers a Fedora system, should do a "clean install" or an effective system refresh (reinstalling the OS and all apps on a system having a separate /home partition) at least, I would say, once for every three new versions of Fedora. The "fedup" app lets too many minor faults accumulate in a system over time. Result: you are cheating yourself and your users of a good user experience.
I'd done upgrades in the past, and always found them painful. Firstly, there was the huge delay, as it churned through what you had installed, to work out what to put into the upgrade. Then there was the left-overs that caused problems with the new system (old, incompatible configuration files, abandoned packages, conflicting packages, etc.), that took longer to sort out than backing up old settings, installing fresh, and carefully implementing their configurations into the new updated versions.
If I ran databases, I might be more inclined to try upgrading rather than fresh installs. But my current circumstances say that it's easier to do fresh installs.
But I decided to put F20 on another machine I had intended to replace. (It was a video-capture machine
I'd be interested to know what you use for that (software and hardware). I've yet to find anything that isn't painful, or actually works.
I learned later that the old machine had been providing a crutch for samba connectivity to other machines on the network. When I retired the old machine, I lost that. Temporarily. I had to relearn everything I'd learned and forgotten about configuring samba by directly editing the smb.conf file. But now I have two machines--a desktop and a laptop--that can establish samba connectivity independently.
Computers running SMB elect a browser master amongst themselves, according to some algorithm - that may be buried in sourcecode, but I haven't seen explained in precise detail - that takes into account things like fastest, strongest, machine that's been running for the longest uptime, to be the master. When machines go offline, there may be a reconsideration of who to be the master, and that can make SMB unresponsive for up to quarter of an hour (great design, that, especially as they don't seem to have the concept of gracefully going offline - i.e. logging off/announcing that they're leaving, everything else times out trying to contact the missing computer). If the browse master goes offline, that can really throw things into a spin. Sometimes the quickest way to force a re-election is to restart SMB on all of them (not really possible if one of them is Windows, rather than Samba, as it doesn't give you an interface to do that).
Although the Samba config does let you try to influence a client to be the browse master, it's still up to all the others as to what really happens. If you have an actual Windows machine on the LAN, it can be very hard to get something else to be the browser master. It can be easier to go the other way, and configure each Samba machine that you don't want to be a browse master, to be lesser machines that shouldn't be considered for the role.
I hate the sodding protocol. These days it stays disabled unless I have to let a Windows machine share files over the network. And I'm more inclined to try and put NFS onto the Windows machine than play SMB shenanigans. That, or just FTP/HTTP/USB-discdrive files across.
-
Patrick O'Callaghan -
Paul Cartwright -
Roberto Ragusa -
Temlakos -
Tim