EncryptedPhreak's Follow-Up udev-208 Comments and Recommendations

EncryptedPhreak's Follow Up udev-208 Comments and Recommendations To the Gentoo Developers.txt (text/plain), 29.69 KB, created by EncryptedPhreak on 2014-04-09 03:42:31 UTC

Dear Jack, Magnus, Jorge Manuel and Samuli,

I've done a LOT of Gentoo Hardened installation and re-installation work trying to get to the bottom of the udev issue since my original udev post on 7 March 2014.  After countless reboots, I finally identified the correct solution, which while being ultimately trivial, is neither obvious to the end user, nor is this udev-208 issue, or the solution, documented on-line, at least I far I can determine!
 
The correct way to fix udev AFTER a user's first boot into Gentoo Hardened following a clean stage3 installation, and following root login, is to issue these three commands:

/etc/init.d/udev start
rc-update add udev sysinit
rc-update add udev-mount sysinit

I know that solution works, period, for a new Gentoo Hardened installation on an amd64 computer.

Just so you understand where I am coming from, I am not an exceptional coder (yet) like all of you clearly are.  Therefore, I have no idea if udev is also broken on Hardened installations on architectures other than amd64.  Nor do I know whether udev is broken on Gentoo non-Hardened installations.  Finding the correct answers to those questions is a task that I will leave in your competent hands.

I will return to discussing udev-208 related issues in a few minutes, but please allow me diverge a bit and discuss how I would like to contribute to Gentoo.

What I am is wanna-be hacker, who is a normal end-user of Gentoo Hardened, and who happens to be an International Businessman.  I am an ex-pat based in Asia who has lived, and thrived, here for many years.  I taught myself MS-DOS in 1981, and my first rig was IBM XT-clone with an externally connected, very expensive Hayes 300 baud modem.   I have used Windows since its initial release, and all subsequent releases through the current 8.1.  I began using linux about five years ago, and for about the last three years, I have used all manner of linux distributions almost exclusively.  Despite the passage of decades, I tote around the still extraordinarily painful recollections of the effort required to graduate near the top of my MBA class from one of those 'prestigious' Universities.  Perhaps, I also have invested the time required to teach myself some more advanced skills than the average linux user.  Enough for now, at least to accomplish the objectives of this posting, about my 'story.' ;-)

The way I see myself optimally contributing the fantastic Gentoo Community, is to write documentation for processes I know and think I understand.  Due solely to the udev-208 problem, I have become what I now consider to be an expert on the topic of correctly installing and efficiently booting into Gentoo Hardened.

You should also know that I am heavily involved with, and a huge supporter of, the i2p project (http://geti2p.net), and that many our of senior i2p coders also love ROCKING their Gentoo Hardened rigs every bit as much as I do!  If you were not aware of it already, you should know that despite the i2p project's relatively small user base, i2p has a disproportionate percentage of users who are coders with seriously advanced linux skills, relative to most FOSS projects.  Of course, ALL OF ANY OF YOU ARE MOST WELCOME TO JOIN US, AT ANY TIME!!  

I assume that any of you would be most comfortable on our #i2p-dev channel, as this is where our i2p developers hang out.  zzz, the Lead Developer behind i2p, is a crackling smart coder, and zzz is also highly responsive to well-formed questions!!  It is also worth noting that we have more than a few very capable Boyz, Girlz and Botz who congregate on our #salt channel.  Furthermore, we also have hundreds of useful guides and links promoting anonymity and encryption on our awesome salted wiki website.  Our #salt channel and salted wiki are both controlled by one of my dearest friends, who uses the nick 'efkt.'  efkt, simply, is exceptionally brilliant.  As I am well-known within the i2p Community, please feel free to drop me an email, and I will ensure you get introduced to the 'right' people.  I will attach my public key to this posting.

If any of you have any available bandwidth to spare, we at i2p, NEED MORE serious coders to conduct peer reviews of our source code.  Therefore, if you can, PLEASE GET INVOLVED WITH I2P!!!

While I do believe that the amd Handbook is a finely crafted document, I also believe that it is a HUGE, GAPING MISS that we do NOT have any similar process documented to achieve a Gentoo Hardened install.

To address that glaring need, I have written a comprehensive guide, entitled:  How To Install Gentoo Hardened with Encrypted Root and Swap.

I've invested several hundred hours of my life researching, testing, and composing this KNOWN TO WORK Hardened installation guide.  I wrote this guide with the i2p user base in mind.  However, my guide can easily be adapted for the global Gentoo Hardened installation audience!

My guide is currently undergoing peer review by several senior i2p coders whom I respect.  When that peer review has been completed, I will be more than happy to share it with you for your review and feedback.  Therefore, HEADS UP, a new Gentoo Hardened installation guide will be coming your way soon! 

After the Gentoo developers have reviewed, tested and I have incorporated their feedback into to my Gentoo Hardened installation guide, I would like to see my Gentoo Hardened installation guide get published on gentoo.org as soon as possible.

While my guide relies on, and refers to, where appropriate, the amd64 Handbook, it deviates from the amd64 Handbook in many fundamentally important areas.

I do not want to spoil the surprise, but allow me to take a moment to highlight some of the key differences between my Gentoo Hardened installation approach and the methods and tools used in the Gentoo Linux amd64 Handbook. 

1.  My HDD is structured as follows:

/dev/sda1 is a 300 MiB EFI partition.  As you likely know, EFI boot partitions are required to contain an unencrypted, FAT32 filesystem.
/dev/sda2 encompasses the reminder of my HDD.  It is encrypted with LUKS and contains 8 GiB of encrypted swap space and remainder of my HDD contains an encrypted ext4 filesystem.  

/dev/sda2 contains only two volume groups:

/dev/mapper/vg-swap AND /dev/mapper/vg-root

Obviously, after LUKS passphrase entry, dmcrypt and lvm2 do all the heavy lifting and mounting before handing off control to the user's configured hardened kernel.

2.  I also two very different tools, both of which were written by a man I consider to be a Towering Linux GIANT, Roderick W. Smith.  In my installation guide, I use Rod's gdisk for HDD partitioning, and I use Rod's rEFInd for boot management.  I don't know if the Gentoo Development Team knows Rod already.  If the Development Team does not know Rod, I would strongly recommend the Development Team does get to know Rod, and DIRECTLY request his support.  Adding a well known, certifiable, linux GURU to the Gentoo Development Team could ONLY HELP CONTINUOUSLY IMPROVE Gentoo!

3.  Each of the tools I use in my installation guide are extensively documented on Rod's website:  http://www.rodsbooks.com/.  Rod's site also documents his truly impressive life's work!

4.  I do NOT USE ANY Bootloader.  In fact, I had previously used GRUB:2 to boot Gentoo Hardened, but found, over time, that GRUB:2 is unbelievably unreliable as a Bootloader for Gentoo Hardened.  I you read Rod's entire rEFInd website, you will also learn that Rod has experienced similar boot reliability issues with GRUB:2.

5.  The awesomely powerful boot manager, rEFInd, is ALL we need to efficiently, and very reliably, boot Gentoo Hardened on any modern amd64 computer!

To reiterate, my proposed Gentoo Hardened installation guide will be coming to your Inbox, in the near future, so please keep an eye out for it.

As promised, now we're back to issues related to the broken udev-208.

As I mentioned earlier, my Gentoo Hardened installation guide was composed with the i2p user base in mind.  Due to the fact that udev-208 is currently broken, I had an affirmative responsibility to my i2p user base to explain, to the best of my ability, how udev-208 is broken, and how to fix it.

To that end, I decided to break the udev-208 issue into two separate sections of my Gentoo Hardened installation guide.  The first section is entitled WARNING: udev Has A Bug Which WILL BREAK Your Gentoo Hardened Installation!  I discuss the udev-208 issue within Gentoo Hardened installation portion of my guide.  The udev-208 related text I have in this first udev section is as follows:

Importantly, keep this in the forefront of your mind when you read eselect news item #7 concerning upgrading udev: the udev included with the current hardened stage3 is BROKEN!! Your hardened stage3 also likely contains this very serious udev bug, which will LIKELY BREAK YOUR GENTOO INSTALLATION!!!

Unfortunately, there is not a single reference to the essential system functions performed by udev within the Gentoo amd64 Handbook installation chapters.

I developed my own solution to this bug over many, many reboots but, due to Gentoo's lack of documentation relating to fixing a broken udev, it was akin to grasping for straws, while blindfolded, inebriated and smoking crack!! ;-)

In any event, despite this sad state of affairs, I ASSUME by now, you KNOW I've got your SIX covered!!

Therefore, no worries my friends, I will tell you EXACTLY what to do after your initial UEFI Gentoo Hardened boot when we progress to that point in this installation process.

So you also know, your hardened stage3 has installed udev-208. If you read eselect news item 7, it discusses how to upgrade udev. DO NOT attempt to upgrade udev during this installation process!!! Upgrading udev during installation WILL BREAK your system!

I know this to be true because I have tried. I am in contact with the Gentoo developers to address this very serious bug. The underlying problem is that udev is code that is absolutely critical to the correct functioning of Gentoo's operating system. Also note, I have included all the correct kernel options below, so that you will be able to upgrade to the latest udev when it is known to be safe and stable.

You can verify the installed version of udev on your rig by doing:

emerge -av udev

You will then see this output:

* IMPORTANT: 4 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.


These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild R ] sys-fs/udev-208 USE="acl firmware-loader gudev kmod openrc -doc -introspection (-selinux) -static-libs" ABI_X86="(64) (-32) (-x32)" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

Would you like to merge these packages? [Yes/No]

Answer 'No' here.

Also note, that your udev USE flags may be different than mine, because I've got a properly functioning, full blown KDE Desktop installed on my Gentoo Hardened rig. You have more work remaining to progress to that state!

Do NOT upgrade udev until I receive confirmation from the Gentoo developers that upgrading to the latest udev is KNOWN to be safe!!!

I will keep this page updated with pertinent information on this critical topic.

The second udev-208 related section of my guide occurs immediately after the installer has progressed to the point of his/her actual, initial Gentoo Hardened boot.  The second section is entitled:  Determining If udev Has Broken Your Gentoo Hardened Installation and How To Resolve This Critical Issue.  The text contained within my second udev installation guide section is, as follows:

Remove your USB stick and UEFI boot into Gentoo Hardened!!

59. If your find that after UEFI booting with rEFInd and logging into root, that when you type:

ifconfig

and the ONLY network interface listed is lo, this the result of the major Gentoo Hardened udev installation bug, which I discussed above, and that I am working to resolve with the Gentoo developers.

A Gentoo Hardened installation in this condition is COMPLETELY BROKEN AND UNUSABLE!!

I was forced to develop a solution on my own, due solely to the INEXCUSABLE LACK OF GENTOO DOCUMENTATION on this topic!

The solution while, ultimately trivial, is absolutely critical, to fix your broken Gentoo Hardened installation.

To fix udev and to achieve a properly functioning Gentoo Hardened system, issue these commands as ROOT, in this sequence:

/etc/init.d/udev start

rc-update add udev sysinit

rc-update add udev-mount sysinit

reboot

After you log back in as root, now again, run:

ifconfig

If you see all of your network interfaces that you previously configured, you WILL KNOW that udev has been PERMANENTLY FIXED and now YOU CAN ROCK YOUR GENTOO HARDENED AS HARD AS YOU LIKE!!!

Optionally, you can now upgrade udev to the latest version. If you choose to upgrade, I recommend you reboot immediately following the upgrade.

The latest version of udev is sys-fs/udev-212-r1. If you have a KDE Desktop installed, these are the packages such an upgrade will pull in:

# emerge -av =sys-fs/udev-212-r1

* IMPORTANT: 4 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.


These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] sys-apps/hwids-20140317 [20130915.1] USE="udev" 1,585 kB
[ebuild U ~] sys-fs/udev-212-r1 [208] USE="acl firmware-loader gudev kmod openrc -doc -introspection (-selinux) -static-libs" ABI_X86="(64) -32 (-x32)" 2,660 kB

Total: 2 packages (2 upgrades), Size of downloads: 4,245 kB

The following keyword changes are necessary to proceed:
(see "package.accept_keywords" in the portage(5) man page for more details)
# required by =sys-fs/udev-212-r1 (argument)
=sys-fs/udev-212-r1 ~amd64

The following USE changes are necessary to proceed:
(see "package.use" in the portage(5) man page for more details)
# required by virtual/udev-208-r1
# required by sys-apps/hwids-20140317[udev]
# required by x11-libs/libpciaccess-0.13.2
# required by x11-drivers/xf86-video-glint-1.2.8-r1
# required by x11-base/xorg-drivers-1.15[video_cards_glint]
# required by @selected
# required by @world (argument)
=sys-fs/udev-212-r1 gudev

Use --autounmask-write to write changes to config files (honoring
CONFIG_PROTECT). Carefully examine the list of proposed changes,
paying special attention to mask or keyword changes that may expose
experimental or unstable packages.

However, I strongly recommend you do NOT upgrade to the latest udev, at present, for the following reasons:

1. I remain upset with the Gentoo coder(s) responsible for udev. It is apparent that they don't even know (yet) how to fix their broken udev-208 that is being shipped with their current generation of hardened stage3 releases.

2. My frustration is further exacerbated by the fact that the Gentoo developers were formally notified about this very serious udev problem by a fine gentlemen named Jack Suter on 2 March 2014. I followed up on 7 March 2014, by confirming the udev bug, and by explaining that this bug BREAKS Gentoo Hardened installations. Despite these dual notifications, the Gentoo developers have UTTERLY FAILED TO FIX UDEV!!!

3. You can review Jack's and my Bugzilla reports here. {NOTE the word 'here' in my installation guide is a link to THIS Bugzilla post!!}  While it is clear the Gentoo developers are aware of this issue, and are working on it, udev is NOT CURRENTLY FIXED. Obviously, this current udev state of affairs is COMPLETELY UNACCEPTABLE!! Feel free to add your own comments and installation experience if you would like to add more fuel to the fire!! ALL IN AN EFFORT, OF COURSE, TO GET THIS VERY SERIOUS PROBLEM RESOLVED AS SOON AS POSSIBLE!!

4. You will also see that I posted further, extensive, udev-208 comments to the Gentoo developers on 9 April 2014, in an effort to reach resolution concerning the udev-208 problem.

5. As I stated I would do in my original Bugzilla report, I did try installing Gentoo Hardened using an archived hardened stage3 release. I DO NOT KNOW when the udev bug was introduced, by I DO KNOW that installing Gentoo Hardened using this EXACT file set:

[ ] stage3-amd64-hardened-20140220.tar.bz2 21-Feb-2014 23:27 173M
[ ] stage3-amd64-hardened-20140220.tar.bz2.CONTENTS 21-Feb-2014 23:27 4.4M
[ ] stage3-amd64-hardened-20140220.tar.bz2.DIGESTS 21-Feb-2014 23:27 756
[TXT] stage3-amd64-hardened-20140220.tar.bz2.DIGESTS.asc 21-Feb-2014 23:28 1.6K

WILL ALSO RESULT IN A BROKEN GENTOO HARDENED INSTALLATION!!! Furthermore, to eliminate potential concerns, my stage3-amd64-hardened-20140220.tar.bz2 file did, in fact, pass SHA512 verification.

6. In fact, I know that udev-208 is still being delivered in a broken state, because my most recent installation of Gentoo Hardened occurred used this EXACT hardened stage3 file set:

-rw-r--r-- 1 root root 181697042 Mar 30 04:43 stage3-amd64-hardened-20140320.tar.bz2
-rw-r--r-- 1 root root 4615832 Mar 30 04:43 stage3-amd64-hardened-20140320.tar.bz2.CONTENTS
-rw-r--r-- 1 root root 756 Mar 30 04:43 stage3-amd64-hardened-20140320.tar.bz2.DIGESTS
-rw-r--r-- 1 root root 1639 Mar 30 04:43 stage3-amd64-hardened-20140320.tar.bz2.DIGESTS.asc

Despite my stage3-amd64-hardened-20140320.tar.bz2 file passing SHA512 verfication, I still ended up with a BROKEN Gentoo Hardened system!!!

7. I am further perturbed by the fact that if you carefully read eselect Item 7 concerning the udev upgrade, there is not a single compelling reason provided of why any user would want to upgrade udev. New, does NOT automatically imply, better!! If the Gentoo Hardened team wants people to upgrade a piece of code so critical to proper system functionality, then they sure as Hell OWE THEIR USER BASE A COMPLETE EXPLANATION OF WHAT THAT UPGRADE WILL ACCOMPLISH, AND THE RATIONALE UNDERLYING WHY IT IS IMPERATIVE TO UPGRADE IMMEDIATELY!!!

8. From my point of view, however, the final nail sealing the coffin of reasons to NOT TO 'UPGRADE' udev-208 is contained within this 'pretty' (perhaps, in reality, ugly) picture:

NOTE:  I actually do have a image related to the udev-212-r1.ebuild on my website which I pulled from:

http://packages.gentoo.org/package/sys-fs/udev

Please consider the potential impact to your installation given the implications of that '~' symbol denoting unstable for our amd64 architecture.

I am quite concerned by this, because, again, there is no mention of this instability, nor any reference to architectural applicability, provided within eselect news Item #7. Adding to my concen is the fact, as most of you realize, the amd64 architecture represents the overwhelming majority of computational rigs currently operating on our wonderful, shared Third Rock from the Sun!! ;-)

9. To be abundantly clear, for ALL of the REASONS I have stated above, I strongly recommend that you fix udev-208 as I have described, and that you DO NOT 'UPGRADE' udev until I know from the Gentoo developers that it IS KNOWN TO BE SAFE to perform the udev upgrade!

Please check back here periodically, as I WILL keep the udev related sections of my Gentoo Hardened installation guide updated with pertinent information. 

To summarize, I have told the i2p user base installing Gentoo Hardened that udev-208 is broken, and how to fix udev.

All Gentoo Hardened installers, and I DO MEAN, GLOBALLY, DESERVE TO HAVE ACCESS TO SIMILAR udev-208 INFORMATION, and if applicable, to the non-Hardened Gentoo user base of installers.  Similar information NEEDS to be issued IMMEDIATELY, and DIRECTLY FROM THE GENTOO HARDENED DEVELOPMENT TEAM!!

To be clear, from my point of view, the current udev-208 state of affairs is COMPLETELY UNACCEPTABLE!  The current udev-208 in results in a COMPLETELY BROKEN, AND UNUSABLE GENTOO HARDENED INSTALLATION!!!  To make matters worse, new Gentoo Hardened installers, following a significant investment of their time to install Gentoo Hardened, are then left alone with a broken system, in complete darkness, to either figure out a solution on their own, or to, more likely, GIVE UP on Gentoo entirely.  

I assume most NEW HARDENED INSTALLERS will choose to GIVE UP IN DISGUST, PERHAPS FORMING EXTREMELY NEGATIVE OPINIONS OF GENTOO, in light of the fact that NEW INSTALLERS likely do NOT even understand that it WAS udev-208 which WAS 100% RESPONSIBLE FOR BREAKING THEIR SYSTEM!!

I recommend that the Gentoo Hardened coder(s) responsible for udev-208 NEED to first take big step back, and ask themselves:  How would I feel if I tried to very carefully install a new Operating System, and then, despite following every instruction to the letter, I ended up with a BROKEN, UNUSABLE Operating System?

The answer to that question from my own perspective, is that I was absolutely furious!  I spent two weeks of my life with a BROKEN, UNUSABLE Gentoo Hardened installation until I finally figured out the solution on my own after hundreds of reboots, each time re-chrooting and trying all manner of different ideas! 

Obviously, the average user would NEVER possess the same degree of relentless persistence as I do, especially when you consider that it would be so much less painful for the average user to just GIVE UP, AND THEN SAY:  TO HELL WITH GENTOO!!

However, I am now even more furious than when my Gentoo Hardened installation was COMPLETELY BROKEN, AND UNUSABLE.  To be frank, I am infuriated by the fact the solution I identified in the beginning of this post to fix the currently broken udev-208 is so trivial, YET, DESPITE THE GENTOO DEVELOPMENT TEAM BEING NOTIFIED ON 2 MARCH 2014 BY JACK AND THEN BY ME ON 7 MARCH 2014:I

A.  NO GENTOO HARDENED END USER COMMUNICATION HAS OCCURRED DESCRIBING THE KNOWN UDEV-208 PROBLEM, AND
B.  NO KNOWN TO WORK SOLUTION TO THE KNOWN UDEV-208 PROBLEM HAS BEEN PUBLISHED.

From my perspective, not understanding the ROOT CAUSE of a potentially very complex problem is commonplace, and I DO UNDERSTAND that often, ROOT CAUSE identification can take months, if not years.  This type of issue happens to arise ALL OF THE TIME in complex business deals, which is EXACTLY why I UNDERSTAND THE CORRECT PATH TO RESOLUTION!

However, KNOWING, as you do, about a problem with udev-208, and then FAILING TO COMMUNICATE:  THE UNDERLYING NATURE OF THAT PROBLEM, THE STATUS OF THAT PROBLEM AS IT IS CURRENTLY UNDERSTOOD, THE INTENDED RESOLUTION PATH, AND THE PLANNED SCHEDULE FOR RESOLUTION OF THAT PROBLEM, TO ALL POTENTIALLY IMPACTED USERS IS A HALLMARK CHARACTERISTIC OF UNPROFESSIONALISM!!

Leaving UNPROFESSIONALISM aside for a moment, let's also discuss the NEGLIGENCE aspect of this which HAS OCCURRED, HERE, for, at least, the past month.  In my opinion, you could have tried Jack's 2 March 2014 proposed solution.  Jack ALMOST got it right!

Apparently, from my perspective, I ASSUMING what ACTUALLY OCCURRED WAS THIS:  the

The Gentoo developers were notified in early March 2014 of the udev-208 problem.  Despite Jack's 2 March 2014 notification of the udev-208 problem, and my 7 March 2014 confirmation of the same udev-208 problem, NO ONE ON THE GENTOO DEVELOPMENT TEAM TOOK THE TIME TO PERFORM A CLEAN GENTOO HARDENED INSTALLATION AND WITNESS THE RESULTING COMPLETELY BROKEN, AND UNUSABLE GENTOO HARDENED INSTALLATION FOR THEMSELVES!!
 
Now that the Gentoo Hardened developers RESPONSIBLE for udev-208, HAVE BEEN INFORMED OF THE CORRECT UDEV-208 SOLUTION I IDENTIFIED AT THE BEGINNING OF THIS FOLLOW-UP POSTING, IF THE GENTOO DEVELOPMENT TEAMS FAILS TO IMMEDIATELY, AND APPROPRIATELY, ADDRESS BOTH OF MY PREVIOUS POINTS:

A.  NO GENTOO HARDENED END USER COMMUNICATION HAS OCCURRED DESCRIBING THE KNOWN UDEV-208 PROBLEM, AND
B.  NO KNOWN TO WORK SOLUTION TO THE KNOWN UDEV-208 PROBLEM HAS BEEN PUBLISHED.

THEN, IN MY OPINION, MERE UNPROFESSIONALISM SHOULD NO LONGER BE THE PRIMARY CONCERN FOR THE GENTOO DEVELOPMENT TEAM.  UNPROFESSIONALISM IS SUPERSEDED BY, AND PALES IN COMPARISON TO:  GROSSLY INEXCUSABLE, GROSSLY UNFORGIVABLE, AND SIMPLY, INDEFENSIBLE, GROSS NEGLIGENCE!!!

If those ARE THE CHARACTER TRAITS you would like to 

I recommend that both points A and B that I have discussed above are immediately, and appropriately, addressed by the Gentoo Development Team via four, at a minimum, separate END USER communication channels TO ENSURE THE MINIMUM NUMBER OF END USERS ARE VERY NEGATIVELY IMPACTED BY THE KNOWN TO BE BROKEN UDEV-208, AND WHICH IS KNOWN TO BREAK ALL NEW AMD64 GENTOO HARDENED INSTALLATIONS.

Those four primary communication channels impacting new Gentoo Hardened installers are:

1.  The Gentoo Linux amd64 Handbook
2.  The http://gentoo.org homepage
4.  The Gentoo wiki covering udev, and MOST IMPORTANTLY, ALSO ON
3.  The eselect news Item referencing 'upgrading' udev!  On MY rig, this is currently:  eselect news Item #7.  This entire 'news listing' NEEDS TO BE RE-WRITTEN, FROM THE GROUND UP!!!  In its current state, this eselect 'news' Item is INEXCUSABE LACK OF PERTINENT INFORMATION RELATING TO THE KNOWN TO BROKEN STATE OF UDEV-208, AND ALSO THIS UDEV NEWS ITEM LACKING IN ANY KNOWN TO WORK PROCEDURE TO 'FIX' THE BROKEN UDEV-208 YOU ARE, IN FACT, SHIPPING TO NEW HARDENED INSTALLERS!!!

Obviously, given my position AS AN END USER, I CANNOT MOTIVATE, NOR DEMAND, THAT THE GENTOO DEVELOPMENT TEAM AGREE WITH, AND ACT ON ANY OR ALL OF MY RECOMMENDATIONS.

However, based on my considerable business experience, I have lived, and worked, through many similar situations.  Some of these problems originated with mistakes I had made, but the vast majority of, often very serious and very expensive, problems were created by others.

When I have investigated and drilled down into the root causes of known to be complex problems, I have seen EVERY FORM OF HUMAN BEHAVIOR BY THOSE RESPONSIBLE FOR CREATING, OR CONTRIBUTING TO, THE UNDERLYING PROBLEM.  When I have confronted those responsible for problems, the reactions I have witnessed have ranged throughout the entire spectrum of human behavior.

On the positive end of that spectrum, I have seen people who fully admitted their mistakes, and more importantly, assumed 100% ownership for the 100% correction of the problem they created.  While every problem is different in terms of the impact it has on others, I can assure you that the problem resolution process MUST BEGIN WITH HEARTFELT APOLOGIES OFFERED TO ALL THOSE IMPACTED BY THE PROBLEM.  In a business environment, irrespective of the money involved, these APOLOGIES MUST BE DONE IN PERSON, AND MUST BE DONE INDIVIDUALLY, TO EACH PERSON IMPACTED.  As painful as that process may be for ALL of those involved, THIS PROCESS IS THE ONLY HOPE TO BEGIN TO RESTORE ONE'S CREDIBILITY WITH OTHERS!!

Of course, I have also seen every manner and all means of:  cover-up, denial, obfuscation, attempts to delay, sidetrack, or otherwise defer the imposition of justice.  Based, again on my experience, I can only there is ONLY ONE common thread, despite this incredible range of all too common, yet utterly predictable, DISHONEST, human behavior.  THIS COMMON THREAD, IN MY OPINION, ALWAYS STEMS FROM A FUNDAMENTAL PERSONAL FAILURE TO ADMIT RESPONSIBILITY FOR THE CREATION OF A PROBLEM, AND THE PERSONAL UNWILLINGNESS TO ACCEPT 100% OF THE, OFTEN UNFORESEEN, CONSEQUENCES RESULTING FROM THE CREATION OF THAT PROBLEM!

To put things in perspective for you, I have spent many years of my life working for one of the world's most profitable corporations.  While I was there, we had more than 120,000 employees, conducted business in more than 130 countries, and we owned many of the world's largest fabrication plants, which each cost in excess of $5 Billion (USD) to build, and our plants are dispersed around the globe.  As you might imagine, on this scale of global business, complex problems 'emerge' on a daily basis, yet unsurprisingly, none of those problems are EVER the fault of Portage! ;-)

I was the Lead Negotiator on our large, global Fabrication Plant Negotiation Team, which was held 100% responsible by our Senior Executives, for the negotiation, and management, of ALL the contracts involved with our building $5 Billion fabrication plants.  I only tell you this so you will BELIEVE ME when I say that I have seen, and managed, essentially every single type of very serious business problem known to mankind.  As I drilled into these problems, I unfortunately, all too often, discovered: fraud, misconduct, dishonesty or an attempt to cover-up the issue.  I've personally witnessed CEO's, and other senior managers (both in my company, and in others) being fired as a result of this behavior.  Sadly, one man, who was also a father of three, ended up taking his own life due to the shame he felt as a direct consequence of his dishonest behavior.

I can tell you, based on my experience, that I HAVE NEVER SEEN THINGS END WELL FOR ANYONE WHO DID NOT IMMEDIATELY ASSUME 100% RESPONSIBILITY FOR A PROBLEM THEY HAD CREATED, AND THEN, IMMEDIATELY ATTEMPT TO EMPLOY APPROPRIATE CORRECTIVE ACTIONS, AND BEGIN THE PROCESS OF MAKING FULL AMENDS FOR THE DAMAGE THEY HAD CAUSED!!!

In conclusion, from my perspective, I've, completely unnecessarily, spent all too many hours of my life: 

1.  Identifying a solution to the udev-208 problem, which I did not create, nor originally, understand.
2.  Notifying you of that udev-208 problem on 7 March 2014.
3.  Being forced to explain to my i2p user base of the nature of the udev-208 problem, and how to fix it.
4.  Finally, I was forced to write this lengthy letter in an effort to motivate the Gentoo Development Team appropriately address the udev-208 problem they are 100% responsible for.

It is has now been five weeks since Jack first notified you of of udev-208 problem, and to the best of my knowledge, NOT ONE THING HAS BEEN DONE TO:  ACCEPT RESPONSIBILITY FOR THE UDEV-208 PROBLEM, NOR TO COMMUNICATE WITH GENTOO'S IMPACTED BASE OF INSTALLERS, NOR TO PUBLISH A SCHEDULE FOR WHEN WE CAN EXPECT A KNOWN TO WORK RESOLUTION TO THE ROOT CAUSE UNDERLYING THE UDEV-208 PROBLEM!

While I cannot force the Gentoo Development to immediately deploy appropriate corrective actions, you have read my recommendations, and hopefully, I have conveyed all the reasons why Gentoo should act, now.  To be clear, the udev-208 'ball' remains in your court.

Your comments, and feedback, are always welcome here!

Kindest regards,

EncryptedPhreak