Problem #2 -> Remove /dev/shm line from /etc/fstab if it's there -- the default permissions are 1777 already, chmod shouldn't be necessary, make sure there are no directory /usr/lib/udev, if there is, recompile the packages it has the files for. And check that there is nothing conflicting in /etc/udev too.

Problem #3 -> You need to `revdep-rebuild --library libudev.so.0` if you haven't already

And the only reason to use eudev currently is older kernel than 2.6.39, so avoid any misleading FUD about eudev being "the solution"

And the only reason to use eudev currently is older kernel than 2.6.39

The other reason is a dislike of the direction which systemd-udev is going._________________"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF

And the only reason to use eudev currently is older kernel than 2.6.39

The other reason is a dislike of the direction which systemd-udev is going.

This solely is political. Likewise:
- Don't use wine. I dislike the direction Microsoft wants to go
- Don't use propr. Nvidia. I want to support Linus
- Dont' use Mysql. We don't like Oracle.
It totally is good intention, but beware poor users of this crap in moments of big trouble._________________fun2gen2

And the only reason to use eudev currently is older kernel than 2.6.39

The other reason is a dislike of the direction which systemd-udev is going.

This solely is political. Likewise:
- Don't use wine. I dislike the direction Microsoft wants to go
- Don't use propr. Nvidia. I want to support Linus
- Dont' use Mysql. We don't like Oracle.
It totally is good intention, but beware poor users of this crap in moments of big trouble.

all these examples are irrelevant, you can go just fine without wine, nVidia driver or MySql but that cannot be said on udev._________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

And the only reason to use eudev currently is older kernel than 2.6.39

The other reason is a dislike of the direction which systemd-udev is going.

This solely is political. Likewise:
- Don't use wine. I dislike the direction Microsoft wants to go
- Don't use propr. Nvidia. I want to support Linus
- Dont' use Mysql. We don't like Oracle.
It totally is good intention, but beware poor users of this crap in moments of big trouble.

all these examples are irrelevant, you can go just fine without wine, nVidia driver or MySql but that cannot be said on udev.

And the only reason to use eudev currently is older kernel than 2.6.39

The other reason is a dislike of the direction which systemd-udev is going.

This solely is political. Likewise:
- Don't use wine. I dislike the direction Microsoft wants to go
- Don't use propr. Nvidia. I want to support Linus
- Dont' use Mysql. We don't like Oracle.
It totally is good intention, but beware poor users of this crap in moments of big trouble.

all these examples are irrelevant, you can go just fine without wine, nVidia driver or MySql but that cannot be said on udev.

I don't care much what are Poettering's dreams, matter to the fact, he decided to take an action the wrong way.

as for the devs, I agree with you but I do tent to agree with yngwin, one cannot say udev is for newer kernels and eudev is for older onces, especially when eudev is toe to toe with udev just with small patch set._________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

I don't care much what are Poettering's dreams, matter to the fact, he decided to take an action the wrong way.

As turned out: It in fact is a dream of him and in no terms any decision made. I wish the mood here was not that paranoid. But no wonder the paranoia came from top down - from Gentoo developers themselfs. The only Udev maintainer that time was overloaded: He made us Gentoo~unstable followers a little journey from /lib/udev -to- /usr/lib/udev -to-again- /lib/udev
Maybe some frustration was a cause. Despite paranoia - in reality:
- openrc and systemd live together in peace (I just had rebooted openrc after longtime only systemd)
- udev and eudev live together in the tree: Why not, and hopefully eudev gets stable soon
- despite systemd is supposed to create GnomeOS - Kde is better supported yet by systemd.

Perhaps the last fact is the most confusing and provoking some extra conspiracy paranoia _________________fun2gen2

I don't care much what are Poettering's dreams, matter to the fact, he decided to take an action the wrong way.

As turned out: It in fact is a dream of him and in no terms any decision made. I wish the mood here was not that paranoid. But no wonder the paranoia came from top down - from Gentoo developers themselfs. The only Udev maintainer that time was overloaded: He made us Gentoo~unstable followers a little journey from /lib/udev -to- /usr/lib/udev -to-again- /lib/udev
Maybe some frustration was a cause. Despite paranoia - in reality:
- openrc and systemd live together in peace (I just had rebooted openrc after longtime only systemd)
- udev and eudev live together in the tree: Why not, and hopefully eudev gets stable soon
- despite systemd is supposed to create GnomeOS - Kde is better supported yet by systemd.

Perhaps the last fact is the most confusing and provoking some extra conspiracy paranoia

look, there are ways to do stuff, he chose the wrong way to do that, in previous versions of udev LP broke everything and didn't gave a fuck, this is no paranoia, no one, especially the "great" LP cannot act like he did and expect flowers._________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

Problem #2 -> Remove /dev/shm line from /etc/fstab if it's there -- the default permissions are 1777 already, chmod shouldn't be necessary, make sure there are no directory /usr/lib/udev, if there is, recompile the packages it has the files for. And check that there is nothing conflicting in /etc/udev too.

Problem #3 -> You need to `revdep-rebuild --library libudev.so.0` if you haven't already

And the only reason to use eudev currently is older kernel than 2.6.39, so avoid any misleading FUD about eudev being "the solution"

#1 Yes, fsck. OK, if I understand the bug reports correctly, the solution will probably be to not print out an error message, but still not checking /usr. So, my /usr partition will not be checked automatically anymore, right?

#2 Permissions are OK after removing the line from fstab.

#3 This said "There are no dynamic links to libudev.so.0". But still chromium seems not to crash anymore on twitter.com after the reboot (without the line in fstab). Before it crashed very often on twitter.com.

....
#1 Yes, fsck. OK, if I understand the bug reports correctly, the solution will probably be to not print out an error message, but still not checking /usr. So, my /usr partition will not be checked automatically anymore, right?

Doesn't dracut already take care about? I would wonder if not.
(Better not using dracut, because it is GnomeOS? The same people advocating unix one tool one purpose philosophy are using the one for all genkernel tool.)_________________fun2gen2

For me I think the issue was mostly due to needed revdep-rebuild as I had already modified /etc/fstab.

Code:

sudo revdep-rebuild --library libudev.so.1

This let's me load sites like Google+ and getpocket.com, but then some other sites still aren't working: notably qz.com (it's a news site). I also have tried clearing the cache and cookies in chromium, that hasn't helped the sites that don't load.