Am 11.02.2013 18:36, schrieb Dale:
> Mick wrote:
>> I would think so. This is the only line that I have in mine and the system
>> boots fine: # glibc 2.2
> and above expects tmpfs to be mounted at /dev/shm for # POSIX shared
> memory (shm_open, shm_unlink). # (tmpfs is a dynamically
> expandable/s
Mick wrote:
> I would think so. This is the only line that I have in mine and the system
> boots fine: # glibc 2.2
and above expects tmpfs to be mounted at /dev/shm for # POSIX shared
memory (shm_open, shm_unlink). # (tmpfs is a dynamically
expandable/shrinkable ramdisk, and will # use almost no m
On Monday 11 Feb 2013 15:38:28 Stefan G. Weichinger wrote:
> Am 07.02.2013 22:38, schrieb Canek Peláez Valdés:
> > For what is worth, you also don't need to specify neither /dev nor
> > /proc in fstab with systemd. I'm not sure the init system has anything
> > to do with it, though; I believe is ud
Am 07.02.2013 22:38, schrieb Canek Peláez Valdés:
> For what is worth, you also don't need to specify neither /dev nor
> /proc in fstab with systemd. I'm not sure the init system has anything
> to do with it, though; I believe is udev work, so with a recent
> version of udev, no matter the init sy
On 7 February 2013, at 21:37, Tanstaafl wrote:
> ...
>> I believe he is correct and /dev/shm is irrelevant for this discussion.
>
> Ok, thanks, but... and no offense...
>
> I am not willing to gamble on breaking a remotely accessed server based on
> someone's 'I believe that this is correct' co
On Thursday 07 February 2013 21:37:27 Tanstaafl wrote:
> On 2013-02-07 4:25 PM, Paul Hartman wrote:
> > On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl
wrote:
> >> I think that a lot of people will misread that like I (we) did...
> >
> > I believe he is correct and /dev/shm is irrelevant for this dis
On Thu, Feb 7, 2013 at 3:37 PM, Tanstaafl wrote:
> On 2013-02-07 4:25 PM, Paul Hartman wrote:
>>
>> On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl
>> wrote:
>>>
>>> I think that a lot of people will misread that like I (we) did...
>
>
>> I believe he is correct and /dev/shm is irrelevant for this dis
On 07/02/2013 23:37, Tanstaafl wrote:
> On 2013-02-07 4:25 PM, Paul Hartman wrote:
>> On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl
>> wrote:
>>> I think that a lot of people will misread that like I (we) did...
>
>> I believe he is correct and /dev/shm is irrelevant for this discussion.
>
> Ok, th
On Thu, Feb 7, 2013 at 3:37 PM, Tanstaafl wrote:
> On 2013-02-07 4:25 PM, Paul Hartman wrote:
>>
>> On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl
>> wrote:
>>>
>>> I think that a lot of people will misread that like I (we) did...
>
>
>> I believe he is correct and /dev/shm is irrelevant for this dis
On Thu, Feb 7, 2013 at 3:25 PM, Paul Hartman
wrote:
> On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl wrote:
>> On 2013-02-07 12:53 PM, Peter Humphrey wrote:
>>>
>>> On Thursday 07 February 2013 17:40:39 Tanstaafl wrote:
>>>
So, since I have:
>
> shm/dev/shm tmpfs nodev,nosui
On 2013-02-07 4:25 PM, Paul Hartman wrote:
On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl wrote:
I think that a lot of people will misread that like I (we) did...
I believe he is correct and /dev/shm is irrelevant for this discussion.
Ok, thanks, but... and no offense...
I am not willing to g
On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl wrote:
> On 2013-02-07 12:53 PM, Peter Humphrey wrote:
>>
>> On Thursday 07 February 2013 17:40:39 Tanstaafl wrote:
>>
>>> So, since I have:
shm/dev/shm tmpfs nodev,nosuid,noexec 0 0
>>>
>>>
>>> I change the type tmpfs to devtmp
On 2013-02-07 12:53 PM, Peter Humphrey wrote:
On Thursday 07 February 2013 17:40:39 Tanstaafl wrote:
So, since I have:
shm/dev/shm tmpfs nodev,nosuid,noexec 0 0
I change the type tmpfs to devtmpfs... ok...
I think that's a mistake (because I did it too!) - you only need t
On Thursday 07 February 2013 17:40:39 Tanstaafl wrote:
> So, since I have:
> > shm/dev/shm tmpfs nodev,nosuid,noexec 0 0
>
> I change the type tmpfs to devtmpfs... ok...
I think that's a mistake (because I did it too!) - you only need to change
the tile type of a /dev line, not
On 2013-02-03 12:51 PM, Alex Schuster wrote:
The question is not whether to halt the build or not (that cannot and
>will not be done) but how to do the communication:
>
>- news item
There is one, from 2013-01-23, ending with 'Apologies if this news came
too late for you.'
Okay, if that one cam
On 02/03/2013 12:24 PM, Alan McKinnon wrote:
>
> - trying to infer something from the current running kernel, or
> /usr/src/linux/.config or some magic name in /boot/ is pointless and
> leads to so many false positives it isn't worth the effort in the
> general case.
It was claimed that this will
On Sun, 03 Feb 2013 19:24:50 +0200, Alan McKinnon wrote:
> So I say to you
>
> "Neil, what is your solution for all the myriad configurations possible
> that DO NOT resemble your own? We know what your preferred solution is,
> as you stated it clearly, but I am interested in all those other users
Alan McKinnon writes:
> On Sat, 2 Feb 2013 16:21:10 +0100
> Alex Schuster wrote:
>
> > Michael Mol writes:
[system does not boot after UDEV upgrade]
> > Ran into the same problem, with my sister's PC. Which I had updated
> > from remote, so I did not see the elogs. I do not think it is correct
On 03/02/2013 16:54, Neil Bothwick wrote:
> This isn't about a lack of convenience, this upgrade WILL break a
> computer that was working beforehand, and not tell the user about it
> until after the damage is done. I'm not saying it is easy to find a
> solution that helps avoid breaking while not i
On Sun, 03 Feb 2013 14:02:39 +0200, Alan McKinnon wrote:
> Nor does it make it wrong. I'm all for Gentoo allowing you to shoot
> > yourself in the foot, I just think it's a good idea to let you know
> > the gun is pointing at your foot before you pull the trigger.
> > Updating udev without the co
On 03/02/2013 13:24, Neil Bothwick wrote:
>>> I may be suffering from faulty wetRAM, but I'm sure I've seen ebuilds
>>> > > bail because f incorrect kernel configuration in the past.
>>> > >
>>> > >
>> > Just because the ebuild does it, does not mean it's correct to do it.
> Nor does it make it w
On Sat, 02 Feb 2013 22:47:15 +0200, Alan McKinnon wrote:
> > I may be suffering from faulty wetRAM, but I'm sure I've seen ebuilds
> > bail because f incorrect kernel configuration in the past.
> >
> >
> Just because the ebuild does it, does not mean it's correct to do it.
Nor does it make it w
On Sat, Feb 2, 2013 at 2:17 PM, Alan McKinnon wrote:
> On Sat, 2 Feb 2013 16:21:10 +0100
> Alex Schuster wrote:
>
>> Michael Mol writes:
>>
>> > So, I botched the upgrade to udev-191. I thought I'd followed the
>> > steps, but I apparently only covered them for one machine, not both.
>>
>> [...]
On 02/02/2013 22:31, Neil Bothwick wrote:
> On Sat, 2 Feb 2013 21:17:38 +0200, Alan McKinnon wrote:
>
>> The question is not whether to halt the build or not (that cannot and
>> will not be done) but how to do the communication:
> I may be suffering from fault wetRAM, but I'm sure I've seen ebuilds
On Sat, 2 Feb 2013 21:17:38 +0200, Alan McKinnon wrote:
> The question is not whether to halt the build or not (that cannot and
> will not be done) but how to do the communication:
I may be suffering from fault wetRAM, but I'm sure I've seen ebuilds bail
because f incorrect kernel configuration i
On Sat, 2 Feb 2013 16:21:10 +0100
Alex Schuster wrote:
> Michael Mol writes:
>
> > So, I botched the upgrade to udev-191. I thought I'd followed the
> > steps, but I apparently only covered them for one machine, not both.
>
> [...]
>
> > Udev also complained about DEVTMPFS not being enabled in
Michael Mol writes:
> So, I botched the upgrade to udev-191. I thought I'd followed the
> steps, but I apparently only covered them for one machine, not both.
[...]
> Udev also complained about DEVTMPFS not being enabled in the
> kernel.[2] I couldn't get into X, but I could log in via getty an
On Thu, Jan 31, 2013 at 1:24 PM, Mick wrote:
> On Thursday 31 Jan 2013 14:37:00 Michael Mol wrote:
>> On Thu, Jan 31, 2013 at 9:30 AM, Peter Humphrey
>>
>> wrote:
>> > On Thursday 31 January 2013 14:05:07 Michael Mol wrote:
>> >> OK, it looks like /dev/pts is not mounted. But darned if I know
>>
On Thursday 31 Jan 2013 14:37:00 Michael Mol wrote:
> On Thu, Jan 31, 2013 at 9:30 AM, Peter Humphrey
>
> wrote:
> > On Thursday 31 January 2013 14:05:07 Michael Mol wrote:
> >> OK, it looks like /dev/pts is not mounted. But darned if I know
> >> why...Isn't udev supposed to handle that?
> >
> >
On Thu, Jan 31, 2013 at 10:23 AM, Alan McKinnon wrote:
> On Wed, 30 Jan 2013 22:35:06 -0500
> Michael Mol wrote:
>
>> So, I botched the upgrade to udev-191. I thought I'd followed the
>> steps, but I apparently only covered them for one machine, not both.
>>
>> The news item instructions specifie
On Wed, 30 Jan 2013 22:35:06 -0500
Michael Mol wrote:
> So, I botched the upgrade to udev-191. I thought I'd followed the
> steps, but I apparently only covered them for one machine, not both.
>
> The news item instructions specified that I had to remove
> udev-postmount from my runlevels. I did
On Thursday 31 January 2013 14:31:58 Michael Mol wrote:
> Two pieces missing.
--->8
> Two, I'm not using an initramfs on this machine, so in *addition* to
> needing to have CONFIG_DEVTMPFS enabled, I also needed to have
> CONFIG_DEVTMPFS_MOUNT enabled.
>
> Rebuilding the kernel with that, and reb
On Thu, Jan 31, 2013 at 9:30 AM, Peter Humphrey
wrote:
> On Thursday 31 January 2013 14:05:07 Michael Mol wrote:
>
>> OK, it looks like /dev/pts is not mounted. But darned if I know
>> why...Isn't udev supposed to handle that?
>
> Why did you remove udev-mount from the sysinit level? I left mine a
On Thu, Jan 31, 2013 at 9:05 AM, Michael Mol wrote:
> On Thu, Jan 31, 2013 at 8:47 AM, Michael Mol wrote:
>> On Thu, Jan 31, 2013 at 8:26 AM, Michael Mol wrote:
>>> On Wed, Jan 30, 2013 at 11:48 PM, Canek Peláez Valdés
>>> wrote:
On Wed, Jan 30, 2013 at 10:45 PM, Canek Peláez Valdés
>>>
On Thursday 31 January 2013 14:05:07 Michael Mol wrote:
> OK, it looks like /dev/pts is not mounted. But darned if I know
> why...Isn't udev supposed to handle that?
Why did you remove udev-mount from the sysinit level? I left mine alone and
it all works just fine.
--
Peter
On Thu, Jan 31, 2013 at 8:47 AM, Michael Mol wrote:
> On Thu, Jan 31, 2013 at 8:26 AM, Michael Mol wrote:
>> On Wed, Jan 30, 2013 at 11:48 PM, Canek Peláez Valdés
>> wrote:
>>> On Wed, Jan 30, 2013 at 10:45 PM, Canek Peláez Valdés
>>> wrote:
On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol
On Thu, Jan 31, 2013 at 8:26 AM, Michael Mol wrote:
> On Wed, Jan 30, 2013 at 11:48 PM, Canek Peláez Valdés
> wrote:
>> On Wed, Jan 30, 2013 at 10:45 PM, Canek Peláez Valdés
>> wrote:
>>> On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol wrote:
So, I botched the upgrade to udev-191. I thought
On Wed, Jan 30, 2013 at 11:48 PM, Canek Peláez Valdés wrote:
> On Wed, Jan 30, 2013 at 10:45 PM, Canek Peláez Valdés
> wrote:
>> On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol wrote:
>>> So, I botched the upgrade to udev-191. I thought I'd followed the
>>> steps, but I apparently only covered the
On Wed, Jan 30, 2013 at 10:45 PM, Canek Peláez Valdés wrote:
> On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol wrote:
>> So, I botched the upgrade to udev-191. I thought I'd followed the
>> steps, but I apparently only covered them for one machine, not both.
>>
>> The news item instructions specifie
On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol wrote:
> So, I botched the upgrade to udev-191. I thought I'd followed the
> steps, but I apparently only covered them for one machine, not both.
>
> The news item instructions specified that I had to remove
> udev-postmount from my runlevels. I didn't
40 matches
Mail list logo
