DBUS Nightmares (recent 'sabotage?') and rant, 2023 failing of Arch

Format: Plaintext
 ( View Raw)
Date: Wed, 24 May 2023 at 21:36:55

DBUS Nightmares (recent 'sabotage?') and rant, 2023 failing of Arch

Before anyone decides to jump down my throat.

I am a 10 year daily arch user, and have used 90% of the day and night every days sans a 2 week vacation since.
I had install and maintain multiple machines for others.
I am skilled at sys admin. I have used arch for web server and local.
Linux us linux of course regardless of distribution with only minor differences, but notably maintainer, packaging and deliverance.

I have both very simple systems with maybe 2 sata drive, one for OS/linux and another for example for media. NTFS (of which on linux for 20 YEARS never ever ever ever ever ever had issue until 2023 now, tested and occuring on multiple independent machines = DBUS SABOTAGE/INCOMPTENT ERRORS.

Kind of crucialm, eh? And the perfect fucntion to actually sabotage linux. 100% I believe now there are people within paid off (probably by Apple, Google or Microsoft, or even IBM whom Red Hat sold out and destroyed all their credibility imo) in conspiracy to tamper

I signed up this account because it is has gone too far - either incomptence or sabotage, take your pick. Do I expect a rabid bunch of excusers calling this post a conspiracy theory, of course. I have been a 110% advocate of Vanilla Arch for years, but things have gone too far. And with this latest issue, notably today. I have to leave temporarily and switch to Debian as my daily until this issue can be resolved.

EX. BELOW -proving this problem in simple words.

I should not have to re-install Arch (which would be at this point the easiest and fastest solution to untangle the "sabotage" that was incurred BY WHAT I WOULD CALL MALWARE/VIRUS IN CONVENTIONAL TERMS from recent packages installed related to community and dbus. After downgrades and inspecting the obvious elements for example, no fix and issue.

As a side note, I could point a ot A BUG, an absolute flaw (and to Arch own doc, instruction) on installing bootloader on gpt/efi/uefi as is basically required these days. I have installed vanilla arch (and also for convenience in script likes anarchy-arch, which also now are broken of course! of course, of course, like EVERYTHING else SINCE 2020 2020 2020 2020.

I will absolutely state that there seems to be within Arch now either completely INCOMPETENT maintainers, or honestly what I believe now - SABOTEURS. Because certain core functionality crucial by common sense should not be malfunctioning or releases WITHOUT TESTING (only a retard would release with such issues and obvious non-testing). Why do sabotage linux in general. I could point a list now of maybe 5-6 major istances of problem that sohuld have not happened, and that were also reported by at least some people out there as well.

... including the dbus issues of recent! Not going to find all links or threads.

#1 - After updates maybe a month ago, NTFS formatted drives, drives I and other people similarly (independent to my hardware, network or machines entirely) have used for 10 years on Arch daily, all-of-the-sudden FAIL MOUNT AND REQUIRE NTFSFIX on /dev partitions!! This has been a recent reoccurent problem points to "A ISSUE"

After doing my own analysis, I came to conclusion it was a dbus-related issue absolute.

#2 - Next, I updated 2 machines the other day who have not been updated for maybe a week,
- one a very minimal vanilla arch with 2 SATA drives - one for os simply, the other with simple media/data. The media/data 2nd sata drive is not mounted in fstab but requires manual mount. By default Arch has also btw unmounted automatically gracefully on shutdown as it should. Like wise over 10 years never an issue, not a file manager issue, every variable TESTED (unlike the Arch packagers aka saboteurs?)

- second machine, used robustly for development. Multiple internal and external drives, which allows me for example to be well-versed in any issued and expert in admin. Some of mounted in fstab, some note, some transient, etc. NEVER an issue, similarly.

But again, both vanilla basic Arch installs simultaneously has corrupted reading incurred by ARCH and required a sudo ntfsfix /dev/sdx to fix, repeatedly and only since end of April AFTER recent Arch updates on simple core packages.

But THEN now, both machines again simultaneously updates last night, reboot with worse:

any attempt to mount any drive:
	
Failed to mount "drive label"
Message recipient disconnected from message bus without replying.

All block devices are removed from any file manager view. I *** COULD *** manually mount/umount drives. The drive that was attempted to mount via (any file manager - all had same exact issue = dbus FAULT/sabotage) of course had it's folder remaining in the mount directory.

You will find similar complaint related to dbus on the forums too, recent.

TAKE TWO
Take these two errors and this proves massive 'malware' fault, incompetence, screw-up and really in reality - a sabotage of crucial messaging system either screwing people's drives and certtainly preventing a lay, basic computer users A NIGHTMARE, inaccessibilty to their drives...

in reality a fully 'broken' system because of course if you cannot reach your files. What does this 'sabotage' do? It causes bad mouth, bad rep and turns people to crap amoral company products like Apple, Microsoft and Google junk. Same story, I saw it happen with web development in the 2000s!!!!!

Sabotage. Maybe time to put on the Black Sabbath LP and not excuse and and laugh about. This is serious problem and Arch imo has certainly been infiltrated. Maybe Arch maintainers of crucial core system packages should get off their comfortable d-asses and fix and watch the -dbus or better get replaced by a "TRUSTED USER" (and not a saboteur from big tech louses, they already invaded Red Hat, I guess Arch in next)

Big problems in Arch. Small issues - never a problem. BOOT, FILES/FM and DBUS = Inexcusable at any level whether LTS but also DEV level. But it happened April/May 2023. Arch sabotage plain-and-simple, incompetence at this level is sabotage any way you cut.

Don't excuse. Fix and make sure this never happens again. When Arch 2015, which was far more cumbersome, linux was in-transition withsome natural 'disturbances' that were rational and natural, the problems here should never have happened to this point. Crippled computers. Shame.

SERIOUS 3rd
Sidenote: I also experienced on a new install Arch machine, another serious issue regarding files and data on encrypted drives RELATIVE TO DBUS, severe destructive issues I will not expand on here. I able to 'de-bug' and correct the issue only by salvaging and moving files on a new encrypted container and then deleting the other. In my days of 40+ YEARS of computing and admin on every single existent OS, I have not seen the problem. At first I suspected it had to be relating disks and GPT as I always used MS-DOS for data (2 different disk it occurred, one new one old circa 20000hrs, both verified ok), but not... guess what it was related to DBUS!

LASTLY
What could I do to continue using arch. Attempt a clean re-install (the joke is I just did a clean install on a new machine in February !!! And this happened just the same as multiple other machines) yet currently and perceivably over next months this issue will arrive. Not a real solution or rationally acceptable, actually anti-thetical to LINUX itself. (Cause system was sabotaged with malware or bugged out badly through these or related ARCH dbus packages!)

I could also attempt to mount all drives via fstab, but not going to do that now considering 'corruption' issues with Arch DBUS. PROOF. DING DING DING: They get corrupted because they are not unmounted properly thus requiring NTFSFIX in cases of such drives (this has nothing to do with ntfs driver btw, absolutely not of course). Just as with the "Failed to mount "drive label" Message recipient disconnected from message bus without replying." >> All drives mounts are hidden from file managers, followed by an NON-UMOUNTED drive MOUNT-ATTEMPT THROUGH DBUS that caused the error!! Result, improper unmount, meaning (a) for the NTFS drives, corrupted table requiring ntfsfix operation to restore (and thus mount); (b) total crash and inaccessibily of file systems on other drives that ROOT/HOME and leftover mountpoint folder requiring manual removal!

Unacceptable. No excuse. Total failure by Arch Team.

So now as veteran Arch user, skilled at sys admin and RATIONAL, I have no choice to leave Arch for the time being???? Think about this. You could not have less "trusted users" or "maintainers" or greater incompetency. What happened, do the saboteurs win.

Perhaps you should email J.A. Steffans (heftig) and ask what the hell happened and then look around and find out who the saboteurs in Arch team are, maybe do an financial audit and see who has a conflict-of-interest or getting PAID. 10 YEARS, not a major problem that could not be handled. If now drives are inaccessible or in danger of corruption to do core functionality and dbus, then the system is broken.

sad((((

To other Arch users, I would pay attention to this and note fatal core errors you discover today or in coming days that probably should not have happened. And worry a bit...

Whhat a shame Arch Linux was the best absolutely shining example of Linux, vanilla, simple, any user can see and know thy package(s). By philosphy and design (and aur) Arch as a distribution still is...

But when the core elements required for running an actual computer system fail to such a degree, then it is 1500% percentage not the end-user fault or blame in any way shape or form---it is the ARCH TEAM. A

What a let down, I feel very sad to watch nearly every in society be invaded and ruined, and this is NEW PHENOMENA since 2020, right, right.

I am very very sorry to post this rant, but I have to say it in hopes of immediate audit, correction and to enter feedback. Too many issues have arisen recently, accelrating is frequency and severity, where latest core updates ARE TOO MUCH AND DISTRO-KILLERS.

Anyone would defend or try to shoot down my post here is probably a loser saboteur or taking a pay check from the same garbage tech companies invasive and controlling of nearly all web, and even now in many ways to hardware level. Something wicked this way has come. Time to flush it out.