I would like to know something about testing methods.
Unfortunately my experience is that if somebody wants to change ANYTHING in the hardware or the software (something went wrong or must upgrade for any purpose), the system falls into small pieces and shows strange behaviors: different remained libraries, new error problems, non repeated mistakes. The error repairing became more difficult.
So I would like to know: would be again repair system and SAX, some other helper tools? If I have to change a disk (on separate environment) or a video-card, it is a big problem for the system…
How you test the system (I see only same tests on same architecture), repeated install/uninstall, update/upgrade/downgrade and regression tests? The system stability (against the changes) now very slow… dynamic test are missing, I think.
Could you improve the program and system error messages and error seeking (“it is an error”, unconfined error", lots of error with same error messages - “CHANGE HAT”)?
Could you make simplier and wider (not for the files/directories but the programs/programgroups) useful apparmor program (not for the gurus, but the lamas)?
I’m struggling to comprehend. Perhaps you need to clarify…
But FYI: Changing a GPU should present little issues, but it may depend on driver requirements. In my case, where the driver needs are the same for different GPU’s - switching is as simple as Pull and Replace.
However, HDD’s could present a challenge. But if you understand your system it should be no issue.
Testing can be done by having a partition set aside for such.
There were some useful tools in the system (repair, sax and so on) in legacy distros. Are there again in the future? The error repairs (after changes) took incredible huge time nowadays.
Will the 13.2 support the nvidia drivers with hardware rendering (XBMC needs)? The 13.1 supports G01 driver (the kernel), but the device works with the G03… BTW the Xorg crashes about it… two ore more drivers (nouveau, nvidia) without proper handling…
If I change 2 hardware drives in the drive bay (with shared partitions), the system crashes… drives work with logical names… grrr… it is just one problem (grub).
If I (re)install some (legacy) programs, there are different behaviors (for example audit, xdm, mesa, apache and so on); my system is about 10 years old with yearly updates. New errors occurred with misty error messages (mainly security issues). Why don’t you claim proper error handling? Error… with no information, no data, no purposes. One error case -> one different error message -> one different repairing method… it would be ideal… the error handling is more important than the proper program… :))). The dynamic tests would be more important than the wide static test environment… “never touch the running system?”. Or back to the system defaults maybe… if it exists at all.
So… I planned to change the openSuSE system to other so I would need to these informations, because I liked it… but not stabile now.
PS: And I have to say that the system was another “before NOVELL” than now… now far less stability but more shining.
Both sax and repair were discontinued because the amount of work needed to maintain them was absurd and Xorg (and Wayland) are moving towards more and more autoconfiguration without user intervention or need to make changes to configuration files - there simply wasn’t anyone willing to maintain sax and the repair system required insane amount of testing on different hardware and a maintainer. Unfortunately no one wanted to step up and do it so it was remove.
I have an nVidia GTX770 that works fine with 13.1 with the G03 drivers + XBMC.
What issues do you have? You should open a thread about this.
You don’t have to use UUID, you can switch to using /dev/sdX if you so want - it’s just the default!
I find that Apache, MySQL, Xorg etc. error messages are actually quite straightforward if you know what they mean. Yes, they require some knowledge about what makes the system tick but once you do, it’s pretty easy to figure out what the problem is.
I don’t agree - you must also remember that in 10 years technology has progressed incredibly and modern day systems are way more complex (both from hardware and software angle) than they were mere 10 years ago. Take a look at KDE for example and see how much has been added to it.
Not to mention display adapters and how much more complex the drivers are today.
> venember;2664770 Wrote:
>> 3. If I change 2 hardware drives in the drive bay (with shared
>> partitions), the system crashes… drives work with logical names…
>> grrr… it is just one problem (grub).
> You don’t have to use UUID, you can switch to using /dev/sdX if you so
> want - it’s just the default!
You should not use /dev/sdX names. Be aware that a disk can get
different such names on different boots.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
GT610. Lot-lot-lot Xorg and X.x11-video-nvidiaGxx effort… NO hardware rendering, the nvidia xorg.conf crashes.
Yes, I know.
No. Yesterday: apache setup rewrite after restart-crash: 2 hours googling. A pearl from today: “the working directory not writable” … WHAT/WHERE working directory and WHY (apparmor, jailkit, default, hacker, whatever)? And this is a small example. My favourite message is the “change hat”.
PS. You are right… maybe. But the machine is situated on hosting 40 kilometres from me. If there is a problem: remote repair… reboot… or restart by the support… or remote console… or a small visit by car at the patient… And no everybody is a guru in the openSuSE, there are ordinary users also… like me. I became unsure because of the several and mainly serious errors.
You should open a thread about this in the graphics subsection with information about the crashes and exact hardware specs.
Change hat means security context change - meaning the issue most likely lies with AppArmor and security configuration for it
You can configure Apache and php for example to output considerably more detailed logfiles with debug parameters if you run into issues like “not writeable”.
I maintain a multi billion hit server cluster from another town and I’ve been to the office maybe half a dozen times in the last 6 months.
Ah the joys of remote access.
But I understand your point - there are still issues with the system being overly complex for ‘normal users’ but things are getting better and better as the years go by. You just need to be patient - large changes don’t happen easily and quickly.
I don’t think I’ve ever seen this but then again I use HP servers which have a very specific SAS/SATA order is so a, b, c etc. never change as long as you slap it in the same slot.
Although on SAS it’s always cciss anyway and RAID takes care of the devices so the OS always sees them as pieces of the bigger chunk.
On 2014-09-16 21:56, hcvv wrote:
>
> Miuku;2664856 Wrote:
>> as long as you slap it in the same slot.
>>
>>
> Exactly. But sometimes that is simply not done, or not possible, or
> adding hardware to the system borks this.
I use external eSATA disks, an internal SATA HD caddy, and eventually
via USB. Disks are hot plugable, and what I plug can differ from session
to session. Also I can boot the machine with the internal, fixed disks,
then add disks while on use, then hibernate.
Often those hot-plugged disks become sda instead of what was sda on boot.
And no, I’m not moving disks from slot to slot: all the system disks are
internal and always on the same slot, for years.
So yes, indeed the /dev/sdX names can change, and that’s the very reason
they are now deprecated on Linux. True, there are people that do not
ever see this, but others that see it every day.
So, to be safe, avoid them.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
So… I would declare again, I am/we are (with one of my friends) not a guru, but just an ordinary (retired ) informatics member from other area…
We chose the OpenSuSE because it was user-friendly and easy-to-use together and more complex than other systems/distros ANNO. We learned the Linux for fun, and it was very useful.
So, when one problem occurred, we mostly started from the beginning to dig down from the ground, the known areas were few but its number are increased during the years (hardware and software).
GT610: I don’t know: wait for the 13.2 or open the discuss…
Errors: we don’t agree. The apache error was a surprise, but I found the solutions. “Dir not writable” is dangerous, because I don’ know the origin (named). “Change hat” would be useful, but the error message should contain the area and the dir from the apparmor. But there are lots of annoying stupid error messages, which are not help really (or just I think).
Disks: I distributed the SUSE system directories to different disks. It was the (first) big mistake, when some of them became wrong. Then follows others …
Better times: we would live till now… but I would enjoy to a complex, effective and strong, but easy-to-use security system: apparmor, fail2ban, jailkit, tls and certificates together… plus virus and spam scanner (what do I forget?). I think the security gurus should avoid from the LDAP… it never will become a powerful, scalable and usable solution against the other database systems. But it is only my opinion.
> Errors: we don’t agree. The apache error was a surprise, but I found the
> solutions. “Dir not writable” is dangerous, because I don’ know the
> origin (named). “Change hat” would be useful, but the error message
> should contain the area and the dir from the apparmor. But there are
> lots of annoying stupid error messages, which are not help really (or
> just I think).
One of my professional skills is reading logs of machines, and finding
out if something is needed to be done, or not, and who should do it. And
I have seen messages way more arcane than those you mention. In time you
learn what you need about them.
You do need to learn some slang - like “hat”
At least, now you do not need a paper manual filling several shelves and
racks, to find out what those damn messages are about, as I did… Now
you can google about them, or ask here, without being afraid of the bill
> Disks: I distributed the SUSE system directories to different disks. It
> was the (first) big mistake, when some of them became wrong. Then
> follows others …
This machine is distributed on 4 disks (not raid). No problem at all.
Currently 52 partitions mounted. Well, not really, some are swap or
master table entries.
Telcontar:~ # lsblk | wc -l
52
Telcontar:~ #
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
What you would do, when the departed /var partition became unreached because a disk (which contains only that) went wrong and no fresh saved copy and the disk cannot be repaired?
googling: “Not really something to be concerned, it is an annoyance in pam_systemd, already fixed in systemd 209 or later.”
But I have systemd 208. Now the decision is mine: I see the error message day by day till the new version or update systemd and bear a risk to get unexpected errors… because there is no offered system repairing update after launching the distros… only for the strictly compulsory problems (security). I think you have a mild Stockholm-syndrome…
The system must have STRONG tests and regular checked update. But there are not now. You will lose the remained non-guru users. Is the aim a system for only business purposes?
You’re expecting consumer oriented approach with multi-tier testing from a community distribution with limited resources and a massive amount of software available that is going through a radical transition from a 30 year old init system, a completely new GUI and a foundation that is being rebuilt for future (Wayland, new KDE, SystemD etc.)
> 1. What you would do, when the departed /var partition became unreached
> because a disk (which contains only that) went wrong and no fresh saved
> copy and the disk cannot be repaired?
Same as if you were using a single disk and partition. Analyze, then
repair or replace it.
> 2. New day, new error. From today:
> - pam_putenv … delete nonexistent entry: XDG_RUNTIME_DIR
Ignore it.
> - googling: “Not really something to be concerned, it is an annoyance in
> pam_systemd, already fixed in systemd 209 or later.”
>
> But I have systemd 208. Now the decision is mine: I see the error
> message day by day till the new version or update systemd and bear a
> risk to get unexpected errors… because there is no offered system
> repairing update after launching the distros… only for the strictly
> compulsory problems (security). I think you have a mild
> Stockholm-syndrome…
As I said: ignore it.
If you are that annoyed by that message, create a filter in syslog to
delete them.
> The system must have STRONG tests and regular checked update. But there
> are not now. You will lose the remained non-guru users. Is the aim a
> system for only business purposes?
This is a community distribution, free, and depending on volunteer work.
Maybe you want the commercial version, and they you get what you pay for.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
The last argument always: buy a payable system. No.
Nobody forces somebody into launching distros. If somebody works something, then he/she is responsible for his work somehow.
Not in this case: I make a distro and YOU will tested, checked and repaired it, it is your problem… If I make a ladder for you/for free to climb up the roof it won’t be break under your weight, you must believe that.
I do not wait a big, very sophisticated, state-of-art system with million user and 1000 server functions, mainly if somebody cannot manage it. But I wait an error-free - well: error minimized - system and cooooorrect, frequent update, when it is necessary. It would be a minimum: if I realized that my distro is defected, I should repair this some way, doesn’t matter who wrote the unique part. Not that I will repair it in the next version…
My mate said about a development: “It became too difficult… we have to stop (give up) this.” She was right, the decision was smart.
And - in our case - I missed the deeper tests. And my opinion could not change. The easiest way to say that if the car became broken: the driver was responsible.
Except as specifically stated in this agreement or a license for a particular component, TO THE MAXIMUM EXTENT PERMITTED UNDER APPLICABLE LAW, OPENSUSE 13.1 AND THE COMPONENTS ARE PROVIDED AND LICENSED “AS IS” WITHOUT WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE. The openSUSE Project does not warrant that the functions contained in openSUSE 13.1 will meet your requirements or that the operation of openSUSE 13.1 will be entirely error free or appear precisely as described in the accompanying documentation. USE OF OPENSUSE 13.1 IS AT YOUR OWN RISK.
I’d like to emphasize that last part: The openSUSE Project does not warrant that the functions contained in openSUSE 13.1 will meet your requirements or that the operation of openSUSE 13.1 will be entirely error free or appear precisely as described in the accompanying documentation. USE OF OPENSUSE 13.1 IS AT YOUR OWN RISK.
Morally speaking; You’re using a free product that is made by people with no compensation whatsoever and supported by people who are paid absolutely nothing and give everything out of the goodness of their heart - when you contribute to the overall project as much as many of the people here have - then I’d say you are in a position to start dictating what is acceptable and what is not.
For comparison - I don’t consider myself in a position to dictate anything to the openSUSE guys - that’s why I just try to help where ever I can and learn instead of complaining. I do not feel I contribute enough to criticize except when there is a catastrophic failure that is caused by sheer negligence, which there hasn’t so far been that I can name.
Yes. The answers in these cases are usually step by step:
You are lama.
The problem is not exist.
Buy a payed system.
Taking offense.
The legal shields.
… instead of examine the problem or declare that I am not competent in the problem or responsible for it. Thanks for your helping. It is far better than our cleaning salon was; they cleaned my coat for 20 euros WITH MY RISK and the coat was exactly so dirty that was before. However… I think I could not reach any positive result complaining against the Microsoft whatever Windows error occurs.
We understand your problem however you do not seem to understand what I’m trying to explain to you, so I’ll try this once more:
We are not developers of openSUSE nor SLED/SLES, we have absolutely no control over any of it.
We are not developers of the THOUSANDS of applications that come with it and have their own errors or quality control, it’s all upstream - the actual developers of the software.
We are just users like you, some of us simply more experienced.
openSUSE guys just package the software and slap it together - many of the problems you describe are not in any way related to the distribution itself, the problems lie much further upstream - for example the developers of Apache have their own error codes as do KDE guys and so forth. If you really want to improve it - go complain to THEM.
Maybe. But if you buy a coat, you do not complain at the supporter who send the button to the coat but the at coat distributor. Or if you have a dinner at home and the meal is not delicious your wife do not send you to the market to complain to the parsley seller… but if you are wise enough do not complain…
Back to the beginning:
My problem was purely that there are much more errors in the SuSE than were before. The main answers are:
I became stupid and irresponsible, the statement is not true.
The problem is real.
I asked (and proposed) some thing which are able to improve the system quality, these and the answers are, if we supposed the second alternative:
Will you bring back the legacy and useful tools to help to users like me? No.
Would you extend and improve the testing mechanism of the distro? No.
Could you ask/force the supporters to improve their program’s error handling? No.
Would you plan periodically launched SP or something to decrease the count of errors between two distros? No.
The answers globally: repair YOU, if you can, we can not be responsible for anything.
I would try to be more clear:
NO hardware rendering, the nvidia xorg.conf crashes.
) informatics member from other area…
