| View previous topic :: View next topic |
| Author |
Message |
miket
Guru
Joined: 28 Apr 2007
Posts: 488
Location: Gainesville, FL, USA
|
 Posted: Fri May 29, 2015 5:00 pm Post subject: |
 |
|
| steveL wrote: | So apologies for confusion; I'm trying to be a better user, is all. I think there likely is something in the criticisms I've faced; I'm not as friendly as I used to be, that's for sure, and I don't really like feeling that.
So sorry for that too, to anyone I've offended in the last 18 months of Gentoo devhell. |
Sigh. It's not enough that Poettering's push of code has been destabilizing to our systems and to the Linux ecosystem, but it's also had a bad effect on our community. Friendliness and helpfulness are among our hallmarks--even if we have been challenged of late. You, steveL, are definitely among the helpers. You make great contributions in the Tips and Tricks and in help to users. It's a shame that the Poettering-induced stress has made us edgy.
I hope now that we can find some equilibrium. Even in the face of the continual stream of disruption from yonder lord of misrule, it seems we are getting better in dealing with it and in finding strategies to work through the minefield. I hope that carries on to improved interactions among us. |
|
| Back to top |
|
 |
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Fri May 29, 2015 10:07 pm Post subject: |
|
|
| steveL wrote: |
Basically I was saying "30 seconds thought, and even less for the first comment, resulting in two bad ideas  " which seemed bitchy, and not adding any light to anything; though I still think the above is a bad idea, it's better to back that up with reasoning. |
I was careful to add the "30 seconds of thought" to the remark because I hadn't put any real thought behind it. It just seemed like an amusing idea, no doubt full of holes and race conditions. I'm not insulted, the idea had semi-humorous intent.
OTOH, let's say L.P. were to have another temper tantrum and somehow the kernel started using kdbus (I know, kdbus isn't even, yet.) to report device events, there may well be ways around it, besides a static /dev. I came up with something silly, un-thought-through, etc, in less than 30 seconds. The less silly thought would be to keep a patch around that reverts the netlink->kdbus patch. I'm sure that with some real thought, other ways will emerge. And who knows, maybe it's even possible to hang an inotify on the right place(s) in /sys, if you take the right precautions.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat May 30, 2015 10:02 am Post subject: |
|
|
| Thanks guys; you're the best. |
|
| Back to top |
|
|
augustin
Guru
Joined: 23 Feb 2015
Posts: 318
|
| Posted: Sat May 30, 2015 4:23 pm Post subject: |
|
|
I wanted to publicly acknowledge steveL's nice comment.
I am looking forward to working with him and everybody else here to promote gentoo, systemd-free dom, and the best of Linux community spirit. |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Sun May 31, 2015 11:04 am Post subject: |
|
|
+1 to the previous micket's and augustin's post.
@SteveL: Even making that kind of *harsh* comment should not be considered *errors*... Sometimes it's better to avoid making such comments to avoid... Well, you should know the rst of it.
@micket... you might be forgetting the late ffmpeg/libav debacle. A funny one with an unexpected outcome? Come on, we can work it out easily here. My main system still has +/-libav USE flag (and CPU_FLAGS_X86 expand variable) changes/recompilations pending as that does not add anything but useless hassle and recompilation; so still pending until the affected packages get noticeable version bump.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jun 07, 2015 2:04 am Post subject: |
|
|
| mv wrote: | | The kernel must communicate to the device manager which device is attached/detached. Even if this does not require much information transfer, some channel of communication must be agreed upon. |
Agreed, and here's the follow-up on that (as opposed to simply saying the other stuff is a bad idea.)
Not sure it's really worth changing from rt-netlink at low-level, but that's a starting point for discussion. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Jun 07, 2015 2:07 am Post subject: |
|
|
Thanks augustin and tclover. :-)
I think we all know that there are race conditions inherent in trying to get userland to control the kernel, in response to some event.
That's what configuration is for, afaic. (eg: a proper /etc/mactab read by the kernel.) |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6052
Location: Removed by Neddy
|
| Posted: Sun Jun 14, 2015 11:12 pm Post subject: |
|
|
this is odd.. https://bugs.gentoo.org/show_bug.cgi?id=477498
For some reason systemd cannot handle /etc/mtab being a file and requires it to be a symlink to /proc/self/mounts
| Code: | comm <(sort /etc/mtab) <(sort /proc/self/mounts )
//192.168.0.2/naib /home/naib/documents cifs rw,noexec,nosuid,nodev 0 0
//192.168.0.2/naib /home/naib/documents cifs rw,nosuid,nodev,noexec,relatime,vers=1.0,cache=strict,username=naib,domain=FOO,uid=1000,forceuid,gid=100,forcegid, addr=192.168.0.2,unix,posixpaths,serverino,acl,rsize=1048576,wsize=65536,actimeo=1 0 0
//192.168.0.2/mp3 /var/lib/mpd/music/fluid cifs ro,noexec,nosuid,nodev 0 0
//192.168.0.2/mp3 /var/lib/mpd/music/fluid cifs ro,nosuid,nodev,noexec,relatime,vers=1.0,cache=strict,username=naib,domain=FOO,uid=1000,forceuid,gid=100,forcegid, addr=192.168.0.2,unix,posixpaths,serverino,acl,rsize=1048576,wsize=65536,actimeo=1 0 0
blkio /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cachedir /lib64/splash/cache tmpfs rw,nosuid,nodev,noexec,noatime,size=4096k,mode=755 0 0
cgroup_root /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755 0 0
cpuset /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cpu /sys/fs/cgroup/cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu 0 0
devices /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
/dev/sda1 / ext4 rw,noatime,nodiratime,discard,data=ordered 0 0
/dev/sdb1 /home ext4 rw,noatime,nodiratime,discard 0 2
/dev/sdb1 /home ext4 rw,noatime,nodiratime,discard,data=ordered 0 0
/dev/sdc1 /media/winxp fuseblk ro,nosuid,nodev,noexec,allow_other,default_permissions,blksize=4096 0 0
/dev/sdc1 /media/winxp fuseblk ro,nosuid,nodev,noexec,relatime,user_id=0,group_id=0,default_permissions,allow_other, blksize=4096 0 0
/dev/sdc2 /media/portage ext4 rw,noatime,nodiratime,discard 0 2
/dev/sdc2 /media/portage ext4 rw,noatime,nodiratime,discard,data=ordered 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=10240k,nr_inodes=1021498,mode=755 0 0
freezer /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
fusectl /sys/fs/fuse/connections fusectl rw,nosuid,nodev,noexec,relatime 0 0
mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0
openrc /sys/fs/cgroup/openrc cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release-agent.sh,name=openrc 0 0
perf_event /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
proc /proc proc rw,relatime 0 0
rootfs / rootfs rw 0 0
shm /dev/shm tmpfs rw,nodev,nosuid,noexec 0 0
shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /tmp tmpfs rw,nosuid,relatime,size=1048576k 0 0
tmpfs /tmp tmpfs rw,nosuid,size=1024M,mode=1777 0 0 |
not the same information ... the /proc entry is missing mode and a few other bits. Equally the /proc entry provides more information then mtab for some mounts.
Equally nfs seems to have an issue with /etc/mtab --> /proc/self/mounts (prob due to the difference in information stored) yet systemd is forcing this change on us all...
A better solution would be to patch the kernel to then ensure all the information is presented to /proc/self/mounts AND then such a symlink is doable ...
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 648
|
| Posted: Mon Jun 15, 2015 12:55 am Post subject: |
|
|
| and, of course, williamh is more than happy to dump systemd's shortcomings onto openrc again... let's not forget him abusing his council position to lie to the rest of the council so he could make a separately mounted /usr unsupported because systemd's devs decided they didn't want to allow it anymore. He and most of the council desperately need the boot, but I'm sure they'll mostly get re-elected this cycle too. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Mon Jun 15, 2015 1:49 am Post subject: |
|
|
Naib said:
I got that message from eudev and mdev also. I compared my /etc/mtab to /proc/self/mounts and found them identical.
Like you, I fear this is a way to screw up the kernel so one has to run systemd, but for the moment doing the symlink does nothing but make the warning go away. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6052
Location: Removed by Neddy
|
| Posted: Mon Jun 15, 2015 7:56 am Post subject: |
|
|
| Tony0945 wrote: | Naib said:
I got that message from eudev and mdev also. I compared my /etc/mtab to /proc/self/mounts and found them identical.
Like you, I fear this is a way to screw up the kernel so one has to run systemd, but for the moment doing the symlink does nothing but make the warning go away. |
Well the patch is in OpenRC right now & it is OpenRC that manages the /etc/mtab file mtab: move toward requiring /etc/mtab to be a symbolic link William Hubbs <w.d.hubbs@gmail.com> . I can't see any source for it from eudev/udev
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Mon Jun 15, 2015 8:23 am Post subject: |
|
|
| saellaven wrote: | | systemd's shortcomings |
In this case, systemd is only the messanger of the change. It is more a shortcoming of /etc/mtab being a file: It is better to have something which guaranteed matches reality.
Moreover, it is related with the kernel supporting namespaces (and thus e.g. slave mounts) which cannot be detected otherwise: Some years ago, this played no role, but meanwhile it is crucial for quite some systems.
Yes, it is a problem if the kernel does not store all relevant information, but AFAIK this has changed in current kernels and linux-utils: Perhaps you need to upgrade some packages. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jun 15, 2015 8:32 am Post subject: |
|
|
| mv wrote: | | In this case, systemd is only the messanger of the change. It is more a shortcoming of /etc/mtab being a file: It is better to have something which guaranteed matches reality. |
I'm fine with using /proc/mounts symlinked to /proc/self/mounts to reflect the true state of affairs, so long as it does reflect the true state of affairs, without needing to dupe the same info in another file (/run/mount/utab or w/e it was debian went with.)
| Quote: | | Moreover, it is related with the kernel supporting namespaces (and thus e.g. slave mounts) which cannot be detected otherwise: Some years ago, this played no role, but meanwhile it is crucial for quite some systems. |
This is the bit I take issue with, since the entire basis for namespaces starts with the filesystem; if you're using a chroot, then you can do what you want in that chroot (or newns).
And if you're not, then you're not really using a different namespace, and the discussion is nothing but idiotic.
| Quote: | | Yes, it is a problem if the kernel does not store all relevant information, but AFAIK this has changed in current kernels and linux-utils: Perhaps you need to upgrade some packages. |
From the bug, it still doesn't store everything, which is why debilian has that other file to tell it what's happening.
Now, you may say "so let's solve that problem, then", but it was supposed to be solved already, so how reliable is that..
Yet the issue with namespaces will still be raised, despite being a red-herring. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Mon Jun 15, 2015 9:11 am Post subject: |
|
|
| steveL wrote: | | if you're using a chroot, then you can do what you want in that chroot (or newns). |
I can only tell from my setup without being able to tell whether this is "typical" for many systems: I have a "full" 32 bit chroot partition for my 64 bit system.
With "full" I mean: When I am in the chroot, I also want to have access to my full (outside) 64 bit system, in particular, to everything which is mounted in the (outside) /srv directory, to every USB-stick etc.
Just to mount --bind / somewhere into the chroot could not do this, because every mount after this command (e.g. of a usb stick later on) would have to happen twice: Once inside the chroot and once outside. So I am using the kernel feature of slave mounts to make the mount visible inside.
(Maybe you know a better solution for my problem? So far I do not know any.)
If now my /etc/mtab were just a file, it depends on accident whether I can shutdown my system cleanly: There are no problems if the USB-stick is umounted before the "mount --bind" is umounted. If it happens to be in opposite order, the umounting of the mount --bind fails (or has to be done --lazy which in turn can lead to other problems), and as a consequence also the 32 bit partition itself cannot be umounted cleanly. From /etc/mtab as a file this situation is not visible, because this file knows nothing about slave mounts.
Edit: I would have no problem if /etc/mtab would contain also the slave mount information. But util-linux is dropping more and more the support of /etc/mtab as a file (that's why I said: systemd is only the messenger in this case). Moreover, I do not see why proper container support (although I do not need it in my situation) should be a red herring: If you rely on the kernel to reflect the true situation (for your namespace), both problems are solved simultaneously, so it seems to be the cleaner thing to fix the kernel (or whoever is responsible for this) to put all mount flags in /proc than to fix util-linux to support slave mounts (and still not being sure to have the "true" situation in /etc/mtab and still not being able to handle containers correctly). |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Jun 15, 2015 10:43 am Post subject: |
|
|
I'm the nobody from comment#17 before i change my account to anon it (for the story it's because bugzilla doesn't allow me to prevent sending email to gmail account that some users use).
Here's the problem, nfs-utils doesn't have enough infos when mtab is a symlink to handle nfs shares properly, i don't know for other fs, but if nfs is missing some infos from there, other fs may also have problem with that.
To fix the issue, you need to build nfs-utils with libmount, when using libmount, libmount will record what is missing in /run/utab and nfs-utils will read /run/utab to get missing infos.
To fix the issue in gentoo, devs have default force enable libmount with nfs-utils. While newer install users may never see a problem, for old install like mine, libmount wasn't enable and so the mtab symlink is triggering the bug.
What is still stupid about this bug?
As of today, libmount useflag description is still out of help :
| Code: | | + + libmount : Link mount.nfs with libmount |
If you are not aware of the issue, why will you enable libmount with such a description?
What is again not done right?
Of course you can force enable mtab to be a symlink like williamh message in openrc is doing, but the message should explicitly also tell user to force enable libmount useflag with nfs-utils. If the user is a new user, libmount will be force enable by profile, but if the user is a new user, it will just never get this openrc message because his gentoo already have mtab as symlink and no more a file.
So this message is aiming toward users upgrading their system, and for this kind of users, not telling them to force enable libmount will trigger the bug if they follow williamh advise and symlink mtab like he ask. It's amazing but this advise as-is (without the libmount advise in it) will enable the bug for most users following it! That's more than impressive no?
to sum up the problem
- mtab is a file + "nfs-utils -libmount" -> no issue
- mtab is a file + "nfs-utils libmount" -> no issue
- mtab is a symlink + "nfs-utils libmount" -> no issue
- mtab is symlink + "nfs-utils -libmount" -> bug
In a real world where devs are taking care of openrc users, libmount useflag should had just been removed from nfs-utils and the libmount should had been unconditionally build with nfs-utils (i suppose that's how debian has handle it).
But really, i don't think they care that much about openrc users like i said in the bug report, they are doing all this for systemd. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Mon Jun 15, 2015 1:11 pm Post subject: |
|
|
| krinn wrote: | | libmount useflag should had just been removed from nfs-utils and the libmount should had been unconditionally build with nfs-utils |
Either this, or a block of current openrc to nfs-utils[-libmount]. This is clearly a bug.
As it always happens with bugs, you can claim that they are intentional, and it is hard to prove the contrary.
However, I consider it much more likely that the developers were simply not aware of this issue before it was reported (as it happened for me, too): Probably the developers simply did not test nfs or at least not nfs-utils[-libmount]. In fact, such type of testing is what ~ARCH is for... |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6052
Location: Removed by Neddy
|
| Posted: Mon Jun 15, 2015 1:13 pm Post subject: |
|
|
right, so that needs to be done (is there a bug open on that? ) equally it is mount that relies on /etc/mtab afaik so why not update mount to use /proc/self/mounts
there is still subtle differences between /etc/mtab and /proc/self/mounts (ie a difference between /proc/mounts and /proc/self/mounts) as shown by the comm output above. Either my bash-fu is rusty, /etc/mtab is actually being created too soon & not being updated OR ... there is an actual difference
--edit--
looks like /etc/mtab isn't updated in line with /proc/mounts (where mtab is seeded from) - well my mtab is probably really old .
mtab should be in /var anyway ...
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Mon Jun 15, 2015 1:34 pm Post subject: |
|
|
| Naib wrote: | | looks like /etc/mtab isn't updated in line with /proc/mounts (where mtab is seeded from) - well my mtab is probably really old. |
It should be updated by util-linux, but there have always been many bugs with this, see e.g. (last comment).
And it seems that util-linux is not so keen to fixing this bugs, since IIRC they also recommend using the symlink. Thus, everybody using /etc/mtab as a file uses a no-longer-well-tested setup.
| Quote: | | mtab should be in /var anyway ... |
Except that it cannot be, because you might have /var as a separate partition...
In fact, this is also one of the reasons why I like the symlink: It was very strange to have exactly one file in /etc which was changed at every boot. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6052
Location: Removed by Neddy
|
| Posted: Mon Jun 15, 2015 1:47 pm Post subject: |
|
|
| mv wrote: |
Except that it cannot be, because you might have /var as a separate partition...
In fact, this is also one of the reasons why I like the symlink: It was very strange to have exactly one file in /etc which was changed at every boot. |
exactly, a variable file in the /etc/ directory is very ... so yes a symlink is the next best thing.
Just why it got pushed like this before other parts (ie nfs ebuild) is sorted is well...
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6749
|
| Posted: Mon Jun 15, 2015 2:33 pm Post subject: |
|
|
| Naib wrote: | | Just why it got pushed like this before other parts (ie nfs ebuild) is sorted is well... |
I don't have the impression that it got pushed quickly: The recommendation to have this symlnk existed already briefly after I installed gentoo for the first time. I have this symlink now almost since 10 years, and I did not have the impression that I was an "early adapter" at this time: Already most major (binary) distributions had switched at this time. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Jun 15, 2015 2:37 pm Post subject: |
|
|
| mv wrote: | As it always happens with bugs, you can claim that they are intentional, and it is hard to prove the contrary.
However, I consider it much more likely that the developers were simply not aware of this issue before it was reported (as it happened for me, too): Probably the developers simply did not test nfs or at least not nfs-utils[-libmount]. In fact, such type of testing is what ~ARCH is for... |
williamh is pushing that symlink thru openrc, and without again taking care of the issue, but are you sure the issue is still not known now? Isn't the issue just discuss by myself and A. Tsoy in it? Isn't even the solve easy and given by A. Tsoy (thanks to him) present in the very same bug???
I'm not saying it is intentionally done by williamh, but it isn't really a sane handling again ; and on a program that is default rc for gentoo, and even tagged a gentoo program ; gentoo own openrc as you sure known, how would non gentoo users using openrc will react seeing openrc forcing them to enable a symlink on mtab that would then break their system? Do you think any other distro seeing this kind of handling of openrc will think about switching to use it for themselves?
So i'm just speaking of Gentoo, but in real it's worst, as even forcing libmount on nfs-utils on gentoo will only fix the issue on gentoo, but openrc is not for gentoo only, i couldn't tell you how bad it is as i really don't know how other distro using openrc build themselves nfs-utils, but i just assume some may not use libmount in nfs-utils, and if openrc is not telling them it's a need, openrc will break their system. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6052
Location: Removed by Neddy
|
| Posted: Mon Jun 15, 2015 2:45 pm Post subject: |
|
|
| krinn wrote: | | mv wrote: | As it always happens with bugs, you can claim that they are intentional, and it is hard to prove the contrary.
However, I consider it much more likely that the developers were simply not aware of this issue before it was reported (as it happened for me, too): Probably the developers simply did not test nfs or at least not nfs-utils[-libmount]. In fact, such type of testing is what ~ARCH is for... |
williamh is pushing that symlink thru openrc, and without again taking care of the issue, but are you sure the issue is still not known now? Isn't the issue just discuss by myself and A. Tsoy in it? Isn't even the solve easy and given by A. Tsoy (thanks to him) present in the very same bug???
I'm not saying it is intentionally done by williamh, but it isn't really a sane handling again ; and on a program that is default rc for gentoo, and even tagged a gentoo program ; gentoo own openrc as you sure known, how would non gentoo users using openrc will react seeing openrc forcing them to enable a symlink on mtab that would then break their system? Do you think any other distro seeing this kind of handling of openrc will think about switching to use it for themselves?
So i'm just speaking of Gentoo, but in real it's worst, as even forcing libmount on nfs-utils on gentoo will only fix the issue on gentoo, but openrc is not for gentoo only, i couldn't tell you how bad it is as i really don't know how other distro using openrc build themselves nfs-utils, but i just assume some may not use libmount in nfs-utils, and if openrc is not telling them it's a need, openrc will break their system. |
it almost feels like openRC needs a use flag (or FEATURE flag) that influences the mtab.in file. if libmount is set then push the symlink, else ensure /etc/mtab is seeded as a regular file
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Jun 15, 2015 3:16 pm Post subject: |
|
|
| Naib wrote: | ...
it almost feels like openRC needs a use flag (or FEATURE flag) that influences the mtab.in file. if libmount is set then push the symlink, else ensure /etc/mtab is seeded as a regular file |
You would made the same mistake williamh has done, only solving the issue for gentoo users, on a package that is not only for gentoo.
edit: sorry you're right, you are taking care about non gentoo users/non mtab as symlink users as well by seeding mtab as regular file. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6052
Location: Removed by Neddy
|
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Thu Jun 18, 2015 2:05 am Post subject: |
|
|
From the link: | Quote: | | In exactly which universe is it reasonable to assume that you have a running D-Bus service (or kdbus) and a filesystem containing unit files, all the binaries they refer to, all the libraries they link against, and all the configuration files any of them reference, but that you lack that most ubiquitous of UNIX binaries, /bin/sh? |
In the Universe that sees Windows as a paragon and considers shell as DOS. They want to turn Linux into Windows so that Red Hat can be Microsoft. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
