[gentoo-user] udev-191 bit me. Insufficient ptys

[gentoo-user] udev-191 bit me. Insufficient ptys

[Michael Mol]

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 have udev-postmount in my
runlevels, so I didn't remove it. Turns out, that dictum also applies
to udev-mount. So after removing that[1], I was able to at least boot
again.

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 and a
plain old vt, so I enabled it, rebuilt the kernel, installed it and
rebooted...and now that's presumably covered.

I'm now able to get into X, but when I try to run an xterm, it fails.
Checking ~/.xsession_errors, I find:

xterm: Error 32, error 2: No such file or directory
Reason: get_pty: not enough ptys

I find this bizarre, as I'd never had any trouble with xterm in this
way before. What'd I do wrong, and how do I recover? I don't trust
emerging at this point; I tried re-emerging udev, and I aborted after
I saw an stderr line about failing to open a pty, even though portage
does quiet builds for parallel building by default...so I doubt
whatever emitted that line on stderr was being properly guarded
against the failure.

[1] I didn't have a boot cd or similar to work with, so I used the old
init=/bin/sh trick on the command line. That was functional. And then
I tried init=/usr/bin/vim, and things got real. :)

[2] Sparking a bemused discussion with a friend at tonight's LUG
meeting over the devfs->udev->udev+devtmpfs progression, but that's a
different story.

--
:wq

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Canek Peláez Valdés]

On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol <mikemol@gmail.com> 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 have udev-postmount in my
> runlevels, so I didn't remove it. Turns out, that dictum also applies
> to udev-mount. So after removing that[1], I was able to at least boot
> again.
>
> 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 and a
> plain old vt, so I enabled it, rebuilt the kernel, installed it and
> rebooted...and now that's presumably covered.
>
> I'm now able to get into X, but when I try to run an xterm, it fails.
> Checking ~/.xsession_errors, I find:
>
> xterm: Error 32, error 2: No such file or directory
> Reason: get_pty: not enough ptys

Do you have CONFIG_LEGACY_PTYS=y?  If so, do you really need it? A
little over a year ago[1] I had an annoying issue for having that
option enabled in my kernel, with a lot of virtual ttys reported in
systemctl. This is a shot in the dark (I really don't know if it's
related to your problem), but perhaps having the LEGACY_PTYS option
enabled somehow depleted your available pseudo terminals (which any X
terminal needs to run)? I suppose screen is also out of the question
for the same reason.

> I find this bizarre, as I'd never had any trouble with xterm in this
> way before. What'd I do wrong, and how do I recover? I don't trust
> emerging at this point; I tried re-emerging udev, and I aborted after
> I saw an stderr line about failing to open a pty, even though portage
> does quiet builds for parallel building by default...so I doubt
> whatever emitted that line on stderr was being properly guarded
> against the failure.

I don't see how an error about pseudo terminals could affect the
compilation. You could also try to compile with &> to a log file, and
prepare a binary package instead of installing it immediately. The log
file actually could help to find the problem.

[1] http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/3609

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Canek Peláez Valdés]

On Wed, Jan 30, 2013 at 10:45 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol <mikemol@gmail.com> 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 have udev-postmount in my
>> runlevels, so I didn't remove it. Turns out, that dictum also applies
>> to udev-mount. So after removing that[1], I was able to at least boot
>> again.
>>
>> 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 and a
>> plain old vt, so I enabled it, rebuilt the kernel, installed it and
>> rebooted...and now that's presumably covered.
>>
>> I'm now able to get into X, but when I try to run an xterm, it fails.
>> Checking ~/.xsession_errors, I find:
>>
>> xterm: Error 32, error 2: No such file or directory
>> Reason: get_pty: not enough ptys
>
> Do you have CONFIG_LEGACY_PTYS=y?  If so, do you really need it? A
> little over a year ago[1] I had an annoying issue for having that
> option enabled in my kernel, with a lot of virtual ttys reported in
> systemctl. This is a shot in the dark (I really don't know if it's
> related to your problem), but perhaps having the LEGACY_PTYS option
> enabled somehow depleted your available pseudo terminals (which any X
> terminal needs to run)? I suppose screen is also out of the question
> for the same reason.

Also related, if you have LEGACY_PTYS:

"LEGACY_PTY_COUNT:

The maximum number of legacy PTYs that can be used at any one time.
The default is 256, and should be more than enough.  Embedded
systems may want to reduce this to save memory.

When not in use, each legacy PTY occupies 12 bytes on 32-bit
architectures and 24 bytes on 64-bit architectures."

Regards
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Michael Mol]

On Wed, Jan 30, 2013 at 11:48 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Wed, Jan 30, 2013 at 10:45 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol <mikemol@gmail.com> 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 have udev-postmount in my
>>> runlevels, so I didn't remove it. Turns out, that dictum also applies
>>> to udev-mount. So after removing that[1], I was able to at least boot
>>> again.
>>>
>>> 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 and a
>>> plain old vt, so I enabled it, rebuilt the kernel, installed it and
>>> rebooted...and now that's presumably covered.
>>>
>>> I'm now able to get into X, but when I try to run an xterm, it fails.
>>> Checking ~/.xsession_errors, I find:
>>>
>>> xterm: Error 32, error 2: No such file or directory
>>> Reason: get_pty: not enough ptys
>>
>> Do you have CONFIG_LEGACY_PTYS=y?  If so, do you really need it? A
>> little over a year ago[1] I had an annoying issue for having that
>> option enabled in my kernel, with a lot of virtual ttys reported in
>> systemctl. This is a shot in the dark (I really don't know if it's
>> related to your problem), but perhaps having the LEGACY_PTYS option
>> enabled somehow depleted your available pseudo terminals (which any X
>> terminal needs to run)? I suppose screen is also out of the question
>> for the same reason.

No, I don't have CONFIG_LEGACY_PTYs. I do have UNIX98 PTYs, and I
tried enabling alternate namespaces, but that didn't help either.

>
> Also related, if you have LEGACY_PTYS:
>
> "LEGACY_PTY_COUNT:
>
> The maximum number of legacy PTYs that can be used at any one time.
> The default is 256, and should be more than enough.  Embedded
> systems may want to reduce this to save memory.
>
> When not in use, each legacy PTY occupies 12 bytes on 32-bit
> architectures and 24 bytes on 64-bit architectures."

Yeah, I'm not using CONFIG_LEGACY_PTY, so LEGACY_PTY_COUNT doesn't
even make itself available in menuconfig.

--
:wq

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Michael Mol]

On Thu, Jan 31, 2013 at 8:26 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Wed, Jan 30, 2013 at 11:48 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Wed, Jan 30, 2013 at 10:45 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol <mikemol@gmail.com> 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 have udev-postmount in my
>>>> runlevels, so I didn't remove it. Turns out, that dictum also applies
>>>> to udev-mount. So after removing that[1], I was able to at least boot
>>>> again.
>>>>
>>>> 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 and a
>>>> plain old vt, so I enabled it, rebuilt the kernel, installed it and
>>>> rebooted...and now that's presumably covered.
>>>>
>>>> I'm now able to get into X, but when I try to run an xterm, it fails.
>>>> Checking ~/.xsession_errors, I find:
>>>>
>>>> xterm: Error 32, error 2: No such file or directory
>>>> Reason: get_pty: not enough ptys
>>>
>>> Do you have CONFIG_LEGACY_PTYS=y?  If so, do you really need it? A
>>> little over a year ago[1] I had an annoying issue for having that
>>> option enabled in my kernel, with a lot of virtual ttys reported in
>>> systemctl. This is a shot in the dark (I really don't know if it's
>>> related to your problem), but perhaps having the LEGACY_PTYS option
>>> enabled somehow depleted your available pseudo terminals (which any X
>>> terminal needs to run)? I suppose screen is also out of the question
>>> for the same reason.
>
> No, I don't have CONFIG_LEGACY_PTYs. I do have UNIX98 PTYs, and I
> tried enabling alternate namespaces, but that didn't help either.
>
>>
>> Also related, if you have LEGACY_PTYS:
>>
>> "LEGACY_PTY_COUNT:
>>
>> The maximum number of legacy PTYs that can be used at any one time.
>> The default is 256, and should be more than enough.  Embedded
>> systems may want to reduce this to save memory.
>>
>> When not in use, each legacy PTY occupies 12 bytes on 32-bit
>> architectures and 24 bytes on 64-bit architectures."
>
> Yeah, I'm not using CONFIG_LEGACY_PTY, so LEGACY_PTY_COUNT doesn't
> even make itself available in menuconfig.

Hm. Some googling suggests this might be a permissions issue.

I do have consolekit enabled, but I'm using gdm, so I'd expect that to
take care of itself. (Although screen fails to launch from vt1, so
it's not a consolekit problem.)

--
:wq

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Michael Mol]

On Thu, Jan 31, 2013 at 8:47 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Jan 31, 2013 at 8:26 AM, Michael Mol <mikemol@gmail.com> wrote:
>> On Wed, Jan 30, 2013 at 11:48 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>> On Wed, Jan 30, 2013 at 10:45 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>> On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol <mikemol@gmail.com> 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 have udev-postmount in my
>>>>> runlevels, so I didn't remove it. Turns out, that dictum also applies
>>>>> to udev-mount. So after removing that[1], I was able to at least boot
>>>>> again.
>>>>>
>>>>> 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 and a
>>>>> plain old vt, so I enabled it, rebuilt the kernel, installed it and
>>>>> rebooted...and now that's presumably covered.
>>>>>
>>>>> I'm now able to get into X, but when I try to run an xterm, it fails.
>>>>> Checking ~/.xsession_errors, I find:
>>>>>
>>>>> xterm: Error 32, error 2: No such file or directory
>>>>> Reason: get_pty: not enough ptys
>>>>
>>>> Do you have CONFIG_LEGACY_PTYS=y?  If so, do you really need it? A
>>>> little over a year ago[1] I had an annoying issue for having that
>>>> option enabled in my kernel, with a lot of virtual ttys reported in
>>>> systemctl. This is a shot in the dark (I really don't know if it's
>>>> related to your problem), but perhaps having the LEGACY_PTYS option
>>>> enabled somehow depleted your available pseudo terminals (which any X
>>>> terminal needs to run)? I suppose screen is also out of the question
>>>> for the same reason.
>>
>> No, I don't have CONFIG_LEGACY_PTYs. I do have UNIX98 PTYs, and I
>> tried enabling alternate namespaces, but that didn't help either.
>>
>>>
>>> Also related, if you have LEGACY_PTYS:
>>>
>>> "LEGACY_PTY_COUNT:
>>>
>>> The maximum number of legacy PTYs that can be used at any one time.
>>> The default is 256, and should be more than enough.  Embedded
>>> systems may want to reduce this to save memory.
>>>
>>> When not in use, each legacy PTY occupies 12 bytes on 32-bit
>>> architectures and 24 bytes on 64-bit architectures."
>>
>> Yeah, I'm not using CONFIG_LEGACY_PTY, so LEGACY_PTY_COUNT doesn't
>> even make itself available in menuconfig.
>
> Hm. Some googling suggests this might be a permissions issue.
>
> I do have consolekit enabled, but I'm using gdm, so I'd expect that to
> take care of itself. (Although screen fails to launch from vt1, so
> it's not a consolekit problem.)

OK, it looks like /dev/pts is not mounted. But darned if I know
why...Isn't udev supposed to handle that?

--
:wq

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Peter Humphrey]

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

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Michael Mol]

On Thu, Jan 31, 2013 at 9:30 AM, Peter Humphrey
<peter@humphrey.ukfsn.org> 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 alone and
> it all works just fine.

Because, when I initially rebooted, openrc failed to launch the
udev-mount service, and I couldn't get any farther in the boot
sequence until I removed it. (Which involved removing the symlink in
/etc/runlevels, since rc-update kept failing while complaining about
being unable to update dependencies.)

It seems possible now that the reason the udev-mount service failed to
start was because of the missing CONFIG_DEVTMPFS kernel config option.
I can try adding udev-mount back to see if it works.



--
:wq

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1462 bytes --]

On Thursday 31 Jan 2013 14:37:00 Michael Mol wrote:
> On Thu, Jan 31, 2013 at 9:30 AM, Peter Humphrey
> 
> <peter@humphrey.ukfsn.org> 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 alone
> > and it all works just fine.
> 
> Because, when I initially rebooted, openrc failed to launch the
> udev-mount service, and I couldn't get any farther in the boot
> sequence until I removed it. (Which involved removing the symlink in
> /etc/runlevels, since rc-update kept failing while complaining about
> being unable to update dependencies.)
> 
> It seems possible now that the reason the udev-mount service failed to
> start was because of the missing CONFIG_DEVTMPFS kernel config option.
> I can try adding udev-mount back to see if it works.

Well, I have udev-mount running:

rc-update -s -v | grep udev
                 udev |                                        sysinit
           udev-mount |                                        sysinit

and do not have CONFIG_DEVTMPFS_MOUNT enabled.  devpts is created fine and I 
have no problems booting:

mount | grep devpts
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)


You may want to try the same in case it works?

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Michael Mol]

On Thu, Jan 31, 2013 at 1:24 PM, Mick <michaelkintzios@gmail.com> wrote:
> On Thursday 31 Jan 2013 14:37:00 Michael Mol wrote:
>> On Thu, Jan 31, 2013 at 9:30 AM, Peter Humphrey
>>
>> <peter@humphrey.ukfsn.org> 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 alone
>> > and it all works just fine.
>>
>> Because, when I initially rebooted, openrc failed to launch the
>> udev-mount service, and I couldn't get any farther in the boot
>> sequence until I removed it. (Which involved removing the symlink in
>> /etc/runlevels, since rc-update kept failing while complaining about
>> being unable to update dependencies.)
>>
>> It seems possible now that the reason the udev-mount service failed to
>> start was because of the missing CONFIG_DEVTMPFS kernel config option.
>> I can try adding udev-mount back to see if it works.
>
> Well, I have udev-mount running:
>
> rc-update -s -v | grep udev
>                  udev |                                        sysinit
>            udev-mount |                                        sysinit
>
> and do not have CONFIG_DEVTMPFS_MOUNT enabled.  devpts is created fine and I
> have no problems booting:
>
> mount | grep devpts
> devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
>
>
> You may want to try the same in case it works?

I probably will re-add udev-mount. It's certainly plausible it only
failed because of the lack of CONFIG_DEVTMPFS, and having
CONFIG_DEVTMPFS_MOUNT enabled fixed basic pty and shm functionality
for me.

It's also worth noting that whether or not you use an initramfs (I
don't on this machine) can make a difference.

--
:wq

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Michael Mol]

On Thu, Jan 31, 2013 at 9:05 AM, Michael Mol <mikemol@gmail.com> wrote:
> On Thu, Jan 31, 2013 at 8:47 AM, Michael Mol <mikemol@gmail.com> wrote:
>> On Thu, Jan 31, 2013 at 8:26 AM, Michael Mol <mikemol@gmail.com> wrote:
>>> On Wed, Jan 30, 2013 at 11:48 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>> On Wed, Jan 30, 2013 at 10:45 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>>>>> On Wed, Jan 30, 2013 at 9:35 PM, Michael Mol <mikemol@gmail.com> 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 have udev-postmount in my
>>>>>> runlevels, so I didn't remove it. Turns out, that dictum also applies
>>>>>> to udev-mount. So after removing that[1], I was able to at least boot
>>>>>> again.
>>>>>>
>>>>>> 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 and a
>>>>>> plain old vt, so I enabled it, rebuilt the kernel, installed it and
>>>>>> rebooted...and now that's presumably covered.
>>>>>>
>>>>>> I'm now able to get into X, but when I try to run an xterm, it fails.
>>>>>> Checking ~/.xsession_errors, I find:
>>>>>>
>>>>>> xterm: Error 32, error 2: No such file or directory
>>>>>> Reason: get_pty: not enough ptys
>>>>>
>>>>> Do you have CONFIG_LEGACY_PTYS=y?  If so, do you really need it? A
>>>>> little over a year ago[1] I had an annoying issue for having that
>>>>> option enabled in my kernel, with a lot of virtual ttys reported in
>>>>> systemctl. This is a shot in the dark (I really don't know if it's
>>>>> related to your problem), but perhaps having the LEGACY_PTYS option
>>>>> enabled somehow depleted your available pseudo terminals (which any X
>>>>> terminal needs to run)? I suppose screen is also out of the question
>>>>> for the same reason.
>>>
>>> No, I don't have CONFIG_LEGACY_PTYs. I do have UNIX98 PTYs, and I
>>> tried enabling alternate namespaces, but that didn't help either.
>>>
>>>>
>>>> Also related, if you have LEGACY_PTYS:
>>>>
>>>> "LEGACY_PTY_COUNT:
>>>>
>>>> The maximum number of legacy PTYs that can be used at any one time.
>>>> The default is 256, and should be more than enough.  Embedded
>>>> systems may want to reduce this to save memory.
>>>>
>>>> When not in use, each legacy PTY occupies 12 bytes on 32-bit
>>>> architectures and 24 bytes on 64-bit architectures."
>>>
>>> Yeah, I'm not using CONFIG_LEGACY_PTY, so LEGACY_PTY_COUNT doesn't
>>> even make itself available in menuconfig.
>>
>> Hm. Some googling suggests this might be a permissions issue.
>>
>> I do have consolekit enabled, but I'm using gdm, so I'd expect that to
>> take care of itself. (Although screen fails to launch from vt1, so
>> it's not a consolekit problem.)
>
> OK, it looks like /dev/pts is not mounted. But darned if I know
> why...Isn't udev supposed to handle that?

SOLVED.

Two pieces missing.

One, I didn't notice the "unable to create /dev/pts" and "unable to
create /dev/shm" messages in the boot sequence...and they didn't
appear in /var/log/messages for whatever reason.

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 rebooting, seems to have fixed things.

--
:wq

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Peter Humphrey]

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 rebooting, seems to have fixed
> things.

Now you mention it, I think I did that too; it just seemed like the right 
thing to do. I also have no initramfs.

-- 
Peter

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Alan McKinnon]

On Wed, 30 Jan 2013 22:35:06 -0500
Michael Mol <mikemol@gmail.com> 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 have udev-postmount in my
> runlevels, so I didn't remove it. Turns out, that dictum also applies
> to udev-mount. So after removing that[1], I was able to at least boot
> again.
> 
> 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 and a
> plain old vt, so I enabled it, rebuilt the kernel, installed it and
> rebooted...and now that's presumably covered.
> 
> I'm now able to get into X, but when I try to run an xterm, it fails.
> Checking ~/.xsession_errors, I find:
> 
> xterm: Error 32, error 2: No such file or directory
> Reason: get_pty: not enough ptys
> 
> I find this bizarre, as I'd never had any trouble with xterm in this
> way before. What'd I do wrong, and how do I recover? I don't trust
> emerging at this point; I tried re-emerging udev, and I aborted after
> I saw an stderr line about failing to open a pty, even though portage
> does quiet builds for parallel building by default...so I doubt
> whatever emitted that line on stderr was being properly guarded
> against the failure.
> 
> [1] I didn't have a boot cd or similar to work with, so I used the old
> init=/bin/sh trick on the command line. That was functional. And then
> I tried init=/usr/bin/vim, and things got real. :)
> 
> [2] Sparking a bemused discussion with a friend at tonight's LUG
> meeting over the devfs->udev->udev+devtmpfs progression, but that's a
> different story.

I can't get any kernel >=gentoo-sources-3.7.1 to work properly with
vtys either.

3.7.1 is fine, anything earlier is fine.
I haven't bothered tracking it down further than that (have a severe
dose of laziness right now...)

What kernel are you running on these affected hosts?

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Michael Mol]

On Thu, Jan 31, 2013 at 10:23 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Wed, 30 Jan 2013 22:35:06 -0500
> Michael Mol <mikemol@gmail.com> 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 have udev-postmount in my
>> runlevels, so I didn't remove it. Turns out, that dictum also applies
>> to udev-mount. So after removing that[1], I was able to at least boot
>> again.
>>
>> 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 and a
>> plain old vt, so I enabled it, rebuilt the kernel, installed it and
>> rebooted...and now that's presumably covered.
>>
>> I'm now able to get into X, but when I try to run an xterm, it fails.
>> Checking ~/.xsession_errors, I find:
>>
>> xterm: Error 32, error 2: No such file or directory
>> Reason: get_pty: not enough ptys
>>
>> I find this bizarre, as I'd never had any trouble with xterm in this
>> way before. What'd I do wrong, and how do I recover? I don't trust
>> emerging at this point; I tried re-emerging udev, and I aborted after
>> I saw an stderr line about failing to open a pty, even though portage
>> does quiet builds for parallel building by default...so I doubt
>> whatever emitted that line on stderr was being properly guarded
>> against the failure.
>>
>> [1] I didn't have a boot cd or similar to work with, so I used the old
>> init=/bin/sh trick on the command line. That was functional. And then
>> I tried init=/usr/bin/vim, and things got real. :)
>>
>> [2] Sparking a bemused discussion with a friend at tonight's LUG
>> meeting over the devfs->udev->udev+devtmpfs progression, but that's a
>> different story.
>
> I can't get any kernel >=gentoo-sources-3.7.1 to work properly with
> vtys either.
>
> 3.7.1 is fine, anything earlier is fine.
> I haven't bothered tracking it down further than that (have a severe
> dose of laziness right now...)
>
> What kernel are you running on these affected hosts?

gentoo-sources-3.6.11

Note my vtys worked fine, it was just the ptys which failed.

--
:wq

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Alex Schuster]

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 and a
> plain old vt, so I enabled it, rebuilt the kernel, installed it and
> rebooted...and now that's presumably covered.

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
behaviour to continue building udev although the system wouldn't boot
with that kernel option missing. I would expect the udev ebuild to check
the running kernel for that option, and refuse to build until it has it
set. Or until building is forced by some USE flag or an environment
variable.

Had these things not been handled better in the past?

	Alex

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Alan McKinnon]

On Sat, 2 Feb 2013 16:21:10 +0100
Alex Schuster <wonko@wonkology.org> 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 the
> > kernel.[2]  I couldn't get into X, but I could log in via getty and
> > a plain old vt, so I enabled it, rebuilt the kernel, installed it
> > and rebooted...and now that's presumably covered.
> 
> 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
> behaviour to continue building udev although the system wouldn't boot
> with that kernel option missing. I would expect the udev ebuild to
> check the running kernel for that option, and refuse to build until
> it has it set. Or until building is forced by some USE flag or an
> environment variable.
> 
> Had these things not been handled better in the past?

There's a furious debate going on in -dev about this very thing, and
the bottom line is that your statements above are way too simplistic.

- there is no guarantee that /proc/config.gz represents the kernel the
  binary will actually run on (this emerge might well be the last
  process you ever run on that kernel)
- there is no guarantee that /usr/src/linux corresponds to anything at
  all (it's a symlink and can point to anything, even invalid stuff)
- there is no guarantee that the build host will run the code (think
  build farms, crossdev etc, so every available config cannot possibly
  be valid)
- and a couple more

Basically, the only thing left for the ebuild devs is to notify the
user with the important information.

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
- elog
- README
- some arb notice on a web site somewhere
.....

This is gentoo, the distro that does not hold your hand and gives you
every opportunity to keep both pieces. This is a good example of such. 


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

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 in the past.


-- 
Neil Bothwick

A good pun is its own reword.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Alan McKinnon]

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 bail
> because f incorrect kernel configuration in the past.
>
>
Just because the ebuild does it, does not mean it's correct to do it.

p.s & OT: please let me know if this mail is grossly malformed (trying
Thunderbird for the first time)

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Bruce Hill]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

On Sat, Feb 02, 2013 at 10:47:15PM +0200, Alan McKinnon wrote:
> 
> p.s & OT: please let me know if this mail is grossly malformed (trying
> Thunderbird for the first time)

Not a superfluous us of Mutt, but the look-see is attached.

Bruce
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

[-- Attachment #2: screenshot.png --]
[-- Type: image/png, Size: 120621 bytes --]

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

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 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 correct kernel options WILL break the currently running
system. While there are times you may want to do this, like the examples
you mentioned, the warning should come damage is done, not a "BTW I've
just rendered your computer unbootable" message from portage.

Allow overriding this by all means but the sensible default for any
action that is known to cause breakage is to not proceed until you are
ready.

> p.s & OT: please let me know if this mail is grossly malformed (trying
> Thunderbird for the first time)

The layout is fine, just fix the content :P


-- 
Neil Bothwick

There is so much sand in Northern Africa that if it were spread out it
would completely cover the Sahara Desert.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Alan McKinnon]

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 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 correct kernel options WILL break the currently running
> system. 

And that is the problem.

WHICH kernel config and for WHICH kernel? The ebuild has no way of
knowing and there is no sane mechanism for the user to indicate which
one the ebuild should use.

Any solution you come up with is going to be fraught with difficulties.
Remember that kernel ebuilds are unique, it is the one packages where
nothing is built or put into a runnable state, the ebuild only unpacks
the tarball. So the ebuild cannot know what the config is going to be,
it cannot know what kernel is going to run, it cannot fix any flag
errors it finds, it cannot even know where your sources are or even if
you have a kernel package installed at all. You quite possibly do not
have a /boot/.config and you might not have enabled /proc/config.gz.

See how deep this goes?

In short, there is absolutely no sane approach the ebuild could follow
to protect you from yourself. Yes, it might help YOU in YOUR particular
setup, whilst infuriating others who do it differently.

Think it through logically, the only thing you are left with that works
is to inform the user of what is found and suggest approaches to take.
If you are going to go that route, you might as well print a generic
message that applies to all, backed up with a news item.

I'm not saying the ebuild should not help you out, I'm saying that
ebuild cannot help you sanely, and the existing ebuilds that get it very
wrong whilst trying to be helpful re kernel configs simply prove the point.

-- 
alan.mckinnon@gmail.com

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 2721 bytes --]

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 correct kernel options WILL break the
> > currently running system.   
> 
> And that is the problem.
> 
> WHICH kernel config and for WHICH kernel? The ebuild has no way of
> knowing and there is no sane mechanism for the user to indicate which
> one the ebuild should use.

The current kernel, the one it already uses to determine whether to print
the warning. All I'm asking is the the warning says "I'm going to break
your computer" instead of "I've just broken your computer and let's hope
you can fix it before anything causes a reboot".

> Any solution you come up with is going to be fraught with difficulties.
> Remember that kernel ebuilds are unique, it is the one packages where
> nothing is built or put into a runnable state, the ebuild only unpacks
> the tarball. So the ebuild cannot know what the config is going to be,
> it cannot know what kernel is going to run, it cannot fix any flag
> errors it finds, it cannot even know where your sources are or even if
> you have a kernel package installed at all. You quite possibly do not
> have a /boot/.config and you might not have enabled /proc/config.gz.
> 
> See how deep this goes?

Oh yes, and I don't see how it is possible to cover all situations. But
if the ebuild can detect that a warning is needed, it should give that
warning in time to avoid breakage.
 
> In short, there is absolutely no sane approach the ebuild could follow
> to protect you from yourself.

This sin;t about protecting the user from themself. They have a perfectly
working system which portage then renders unbootable with absolutely no
warning

> Yes, it might help YOU in YOUR particular
> setup, whilst infuriating others who do it differently.

There are already ways to skip warnings, like $I_KNOW_WHAT_I_AM_DOING.

> Think it through logically, the only thing you are left with that works
> is to inform the user of what is found and suggest approaches to take.

My criticism is not of that approach, it is of WHEN the warning is given.

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 inconveniencing others, but
that is no reason to not try.


-- 
Neil Bothwick

IBM - Incredibly Bastardized Multitasking...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Alan McKinnon]

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 inconveniencing others, but
> that is no reason to not try.

OK.

So here's what we have. gentoo-dev thrashed this same conversation to death
with equally ambiguous results. There too a lot of people were saying

"But we shouldn't break user's machines!"

And there was vast consensus about that. The next post invariably said
something like

"We must do <insert current poster's bright idea here>!"

And the reply to that was almost always

"OK hotshot, you covered situation A (coincidentally your situation)>
Now, what about valid situations `seq B J` - *all of which are
supported*. Please provide a plan for those."

And the response to that usually started with "Um..." and didn't
actually contain an answer.

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
not covered by that. Please provide a well thought out solution that
works for them as well as yours would work for you."

I'll bet good money you come to the same conclusion I did (based on the
conclusions on gentoo-dev)::

- 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.
- a console message and an elog generated in one of the *pre hooks is
about as good as it gets ...
- ... backed up by a news item before the time so forewarned users are
forearmed users
- the devs did in fact cock up gloriously by omitting all prior
notification and learned a bitter lesson
- whatever the devs do, this version of udev is going to fuck things up
horribly for a lot of people
- despite what Lennart and co will whinge after the fact, the real
problem lies with udev and it's complete lack of any fallback
should DEVTMPFS not be available.

This last one is to my mind crucial. Who cares what kind of filesystem
/dev is mounted as? It's a filesystem, it's not uber-magic. it's a place
where udev can stick it's nodes. If it doesn't have a tmpfs, well then
it can wait till / is mounted and write it's stuff there. udev already
has a guarantee that /dev will exist as soon as / is mounted, even if
/dev is part of /

What's this mandatory tmpfs all about anyway? Why is a userspace daemon
dictating mandatory kernel behaviour, especially regarding something
that, by design (mount points), is supposed to be transparent to
everything under the sun moon earth and stars?

-- 
alan.mckinnon@gmail.com

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

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
> not covered by that. Please provide a well thought out solution that
> works for them as well as yours would work for you."
> 
> I'll bet good money you come to the same conclusion I did (based on the
> conclusions on gentoo-dev)::

I haven't had a chance to read the -dev threads but

> - 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.

That's what I was thinking of based on

1) Breaking a system to be unbootable is a bad idea
2) The current running kernel is bootable
3) As long as you have that, anything else can be dealt with post-install

Cases like compiling for another system aren't relevant, because the
message will be seen before the update is applied to the other system.
The post-install message can be read on the build host and acted upon
before the target system is broken.

Rendering a new kernel unbootable is still not a massive problem as long
as the current kernel still works.

The checks should be run before the emerge process starts, like the
pre-emerge checks for the likes of libreoffice and kdelibs. That avoids/
the problem of the /usr/src/symlink being changed in the middle of a
world update.

> - a console message and an elog generated in one of the *pre hooks is
> about as good as it gets ...

Which is still a damn sight better than the current "oops, sorry" method.


-- 
Neil Bothwick

Normal people believe that if it ain't broke, don't fix it. Engineers
believe that if it ain't broke, it doesn't have enough features yet."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Michael Orlitzky]

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 result in false positives, but no one
would give any examples. You need /usr/src/linux to point to the right
place anyway, if you want to compile out-of-tree modules, or e.g. video
drivers.

Most people have it pointed to the right place. If it's pointed to the
wrong place by accident, it should be fixed. So the config check alerts
them to that fact.

Considering that there are no consequences for false positives, and big
consequences for false negatives, I think it makes sense to trigger the
warning and let people override it with I_KNOW_WHAT_I_AM_DOING in one of
the rare cases where the kernel config is unavailable (or wrong).

But alas, this horse is dead.

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Michael Mol]

On Sat, Feb 2, 2013 at 2:17 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Sat, 2 Feb 2013 16:21:10 +0100
> Alex Schuster <wonko@wonkology.org> 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 the
>> > kernel.[2]  I couldn't get into X, but I could log in via getty and
>> > a plain old vt, so I enabled it, rebuilt the kernel, installed it
>> > and rebooted...and now that's presumably covered.
>>
>> 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
>> behaviour to continue building udev although the system wouldn't boot
>> with that kernel option missing. I would expect the udev ebuild to
>> check the running kernel for that option, and refuse to build until
>> it has it set. Or until building is forced by some USE flag or an
>> environment variable.
>>
>> Had these things not been handled better in the past?
>
> There's a furious debate going on in -dev about this very thing, and
> the bottom line is that your statements above are way too simplistic.
>
> - there is no guarantee that /proc/config.gz represents the kernel the
>   binary will actually run on (this emerge might well be the last
>   process you ever run on that kernel)
> - there is no guarantee that /usr/src/linux corresponds to anything at
>   all (it's a symlink and can point to anything, even invalid stuff)
> - there is no guarantee that the build host will run the code (think
>   build farms, crossdev etc, so every available config cannot possibly
>   be valid)
> - and a couple more
>
> Basically, the only thing left for the ebuild devs is to notify the
> user with the important information.
>
> 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
> - elog
> - README
> - some arb notice on a web site somewhere
> .....
>
> This is gentoo, the distro that does not hold your hand and gives you
> every opportunity to keep both pieces. This is a good example of such.

I'm no longer subscribed to -dev, so I must have missed that
thread.[1] My *preference* in these matters is twofold:

1) Don't depend on the running kernel. I'd like to be able to use
portage to cross-compile from one amd64 box to another[2], and the
running kernel will be different from the kernel I'm compiling for.
2) Just as we have autounmask-write to force us through a manual
confirmation step if we have to change USE flags or unmask something,
I'd like autounmask to be able to service an "are you sure you want to
override this particular serious warning?" behavior. It'd actually be
pretty simple to do with per-package USE flags, and, since autounmask
only operates on exact versions of packages, you'd be asked for
confirmation on every upgrade. Yes, autounmask makes a mess of
/etc/portage/package.use over time, but that's why you should
periodically go through and sweep the cobwebs out of there.

[1] What with unexpectedly losing my job, I suddenly had even less
time than I already had, since I needed to dive full-bore into job
hunting.
[2] Different CFLAGS, distcc isn't a good option in my circumstance,
and I'd risk an "illegal instruction" error a binary in a chroot used
an instruction available on the target machine's CPU, but not on the
source machine's CPU.

-- 
:wq

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Alex Schuster]

Alan McKinnon writes:

> On Sat, 2 Feb 2013 16:21:10 +0100
> Alex Schuster <wonko@wonkology.org> 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
> > behaviour to continue building udev although the system wouldn't boot
> > with that kernel option missing. I would expect the udev ebuild to
> > check the running kernel for that option, and refuse to build until
> > it has it set. Or until building is forced by some USE flag or an
> > environment variable.
> > 
> > Had these things not been handled better in the past?
> 
> There's a furious debate going on in -dev about this very thing, and
> the bottom line is that your statements above are way too simplistic.
> 
> - there is no guarantee that /proc/config.gz represents the kernel the
>   binary will actually run on (this emerge might well be the last
>   process you ever run on that kernel)
> - there is no guarantee that /usr/src/linux corresponds to anything at
>   all (it's a symlink and can point to anything, even invalid stuff)
> - there is no guarantee that the build host will run the code (think
>   build farms, crossdev etc, so every available config cannot possibly
>   be valid)
> - and a couple more

Sure, all this is not guaranteed. But IF there is a /proc/config.gz and
a /usr/src/linux/.config without the DEVTMPFS entry, it is quite probable
that the system will not boot. And I think a single line 'DEVTMPFS is not
set in this kernel. Udev will not run.' along many others is not enough.

> Basically, the only thing left for the ebuild devs is to notify the
> user with the important information.

That's okay with my PC I am sitting at. But on my sister's PC, I just
logged in and started a world update, not monitoring the process all the
time. She turned the thing off before I was able to read the elog, and
she was surprised when it did not boot the next day. How should I have
known what would happen?


> 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 came a little earlier, I would have been fine.

> - elog
> - README
> - some arb notice on a web site somewhere
> .....
> 
> This is gentoo, the distro that does not hold your hand and gives you
> every opportunity to keep both pieces. This is a good example of such. 

I'm using Gentoo for > 10 years now, and this is the first time such
a thing has happened to me. Normally, the devs do quite a good job
informing people about such changes that need to be dealt with, but this
time I was not pleased.

But I'll stop complaining. This incident just seems a little odd to me,
unusual for Gentoo.

	Alex

[gentoo-user] Re: udev-191 bit me. Insufficient ptys

[»Q«]

On Sun, 3 Feb 2013 18:51:45 +0100
Alex Schuster <wonko@wonkology.org> wrote:

> Alan McKinnon writes:

> > - news item
> 
> There is one, from 2013-01-23, ending with 'Apologies if this news
> came too late for you.'
> 
> Okay, if that one came a little earlier, I would have been fine.

I would have too.  IMO, given the difficulties of putting in automagic
checks and/or failures that would work for everyone, news items are the
best way to handle info like this.

I'm a bit concerned that there wasn't one earlier for udev-197-r*.
AFAICT from the changelog, udev-197.ebuild hit the tree on 9 January,
and the stabilization bug* for a later revision was filed on 16
January.  The stabilization request makes it clear devs should not
rush and should report any further issues they run across, yet
udev-197-r3 was stabilized just a few days later, at which point stable
users started hitting the issues.

I'm not clear on why udev-197-r* needed stabilization without having
~arch keywords for a period.  I rely on the kindness of ~arch testers
who are willing to encounter the issues I later read about in a news
item before an ebuild is stabilized.

* https://bugs.gentoo.org/show_bug.cgi?id=452556

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Tanstaafl]

On 2013-02-03 12:51 PM, Alex Schuster <wonko@wonkology.org> 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 came a little earlier, I would have been fine.

Ok, I'm actually now toying with the idea of updating udev on my older 
server, since a separate /usr is now supported...

So, reading this news item:

<snip>

> - The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the
>   fstype for possible /dev line in /etc/fstab is devtmpfs (and not,
>   for example, tmpfs)

So, since I have:

> shm    /dev/shm     tmpfs      nodev,nosuid,noexec     0 0

I change the type tmpfs to devtmpfs... ok...

Last...

> And read every message printed by the emerge of udev and
> udev-init-scripts to ensure the system is in order before booting as
> this news item might not be complete.

All of these messages will be in the emailed emerge message(s), correct? 
Meaning, I won't have to be sitting there watching the emerge output?

Thanks...

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Peter Humphrey]

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 /dev/shm.

-- 
Peter

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Tanstaafl]

On 2013-02-07 12:53 PM, Peter Humphrey <peter@humphrey.ukfsn.org> 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 to change
> the tile type of a /dev line, not /dev/shm.

Oh... well, glad I asked...

Can anyone (a dev maybe) please confirm this?

I think that a lot of people will misread that like I (we) did...

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Paul Hartman]

On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2013-02-07 12:53 PM, Peter Humphrey <peter@humphrey.ukfsn.org> 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 to change
>> the tile type of a /dev line, not /dev/shm.
>
>
> Oh... well, glad I asked...
>
> Can anyone (a dev maybe) please confirm this?
>
> 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.

The important thing to note is that entries for precisely /dev and
/proc don't need to be in fstab at all for most people if they are
using the standard gentoo openrc/udev combination. I have 3 gentoo
systems running latest ~amd64 openrc and udev and none have /dev or
/proc in fstab and all boot up just fine for me. Obviously if you are
experimenting with other init system or udev alternatives then YMMV
but those people are probably smart enough to figure it out for
themselves already. :)

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Tanstaafl]

On 2013-02-07 4:25 PM, Paul Hartman <paul.hartman+gentoo@gmail.com> wrote:
> On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl <tanstaafl@libertytrek.org> 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 gamble on breaking a remotely accessed server based 
on someone's 'I believe that this is correct' comment.

When the news item says:

> need to verify the fstype for possible /dev line in /etc/fstab is
 > devtmpfs (and not, for example, tmpfs)

'Possible /dev line' in no way is clear that it means a line that has 
ONLY /dev on it. /dev/shm - which is also of type tmpfs - can easily be 
read to be included.

> The important thing to note is that entries for precisely /dev and
> /proc

Mine has this in it:

> # NOTE: The next line is critical for boot!
> none                    /proc           proc            defaults        0 0

So, you're saying that this line, that is prefaced with a comment that 
says it is CRITICAL FOR BOOT, is not even needed?

This is a server that was initially installed back in 2005, so maybe 
this is cruft that is no longer needed?

Obviously I don't understand most of this stuff, so am at the mercy of 
those more knowledgeable.

Thanks,

Charles

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Alecks Gates]

On Thu, Feb 7, 2013 at 3:37 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2013-02-07 4:25 PM, Paul Hartman <paul.hartman+gentoo@gmail.com> wrote:
>>
>> On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl <tanstaafl@libertytrek.org>
>> 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 gamble on breaking a remotely accessed server based on
> someone's 'I believe that this is correct' comment.
>
>
> When the news item says:
>
>> need to verify the fstype for possible /dev line in /etc/fstab is
>
>> devtmpfs (and not, for example, tmpfs)
>
> 'Possible /dev line' in no way is clear that it means a line that has ONLY
> /dev on it. /dev/shm - which is also of type tmpfs - can easily be read to
> be included.
>
>
>> The important thing to note is that entries for precisely /dev and
>> /proc
>
>
> Mine has this in it:
>
>> # NOTE: The next line is critical for boot!
>> none                    /proc           proc            defaults        0
>> 0
>
>
> So, you're saying that this line, that is prefaced with a comment that says
> it is CRITICAL FOR BOOT, is not even needed?
>
> This is a server that was initially installed back in 2005, so maybe this is
> cruft that is no longer needed?
>
> Obviously I don't understand most of this stuff, so am at the mercy of those
> more knowledgeable.
>
> Thanks,
>
> Charles
>
My kernel .config (linux-3.7.4-gentoo) has the following:
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

I believe the automount is the important part, as I do recall someone
else on this list missing that.  My /etc/fstab has neither /dev nor
/proc mounts, although my case may be different than yours.

Alecks

[gentoo-user] Re: udev-191 bit me. Insufficient ptys

[»Q«]

On Thu, 7 Feb 2013 16:00:06 -0600
Alecks Gates <alecks.g@gmail.com> wrote:

> My kernel .config (linux-3.7.4-gentoo) has the following:
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> 
> I believe the automount is the important part, as I do recall someone
> else on this list missing that.  My /etc/fstab has neither /dev nor
> /proc mounts, although my case may be different than yours.

CONFIG_DEVTMPFS_MOUNT=y isn't crucial.  It's a good idea, but if the
kernel doesn't mount /dev, then udev-init-scripts will.

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Alan McKinnon]

On 07/02/2013 23:37, Tanstaafl wrote:
> On 2013-02-07 4:25 PM, Paul Hartman <paul.hartman+gentoo@gmail.com> wrote:
>> On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl <tanstaafl@libertytrek.org>
>> 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 gamble on breaking a remotely accessed server based
> on someone's 'I believe that this is correct' comment.
> 
> When the news item says:
> 
>> need to verify the fstype for possible /dev line in /etc/fstab is
>> devtmpfs (and not, for example, tmpfs)
> 
> 'Possible /dev line' in no way is clear that it means a line that has
> ONLY /dev on it. /dev/shm - which is also of type tmpfs - can easily be
> read to be included.
> 
>> The important thing to note is that entries for precisely /dev and
>> /proc
> 
> Mine has this in it:
> 
>> # NOTE: The next line is critical for boot!
>> none                    /proc           proc           
>> defaults        0 0
> 
> So, you're saying that this line, that is prefaced with a comment that
> says it is CRITICAL FOR BOOT, is not even needed?
> 
> This is a server that was initially installed back in 2005, so maybe
> this is cruft that is no longer needed?


Yes, that is a line that came out of an ancient baselayout. I have a few
of those lying around myself.

To get back to the original topic, it is only /dev and /proc that are in
scope of this discussion.

/dev/shm is just a filesystem which just happens to be mounted inside
the /dev hierarchy and it's that way because a standard (POSIX?) just
happens to mention that it's a good idea. Completely irrelevant to udev.

The confusion comes about because the dev who made the original
announcement is probably not a native English speaker and got his
grammar and language mangled. The missing step is not no-one proof-read
and clarified the original message for him



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Paul Hartman]

On Thu, Feb 7, 2013 at 3:37 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
> On 2013-02-07 4:25 PM, Paul Hartman <paul.hartman+gentoo@gmail.com> wrote:
>>
>> On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl <tanstaafl@libertytrek.org>
>> 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 gamble on breaking a remotely accessed server based on
> someone's 'I believe that this is correct' comment.


No offense at all, it's your system and you make the call. My story
was anecdotal, not authoritative. :)

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Peter Humphrey]

On Thursday 07 February 2013 21:37:27 Tanstaafl wrote:
> On 2013-02-07 4:25 PM, Paul Hartman <paul.hartman+gentoo@gmail.com> wrote:
> > On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl <tanstaafl@libertytrek.org> 
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 gamble on breaking a remotely accessed server based
> on someone's 'I believe that this is correct' comment.

If you go ahead with your proposed change against the advice you've been 
offered, you WILL break it.

-- 
Peter

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Stroller]

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' comment.

<facile response>

You wouldn't have to worry about it, had you ensured out-of-band access!

</facile response>

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Canek Peláez Valdés]

On Thu, Feb 7, 2013 at 3:25 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Thu, Feb 7, 2013 at 2:53 PM, Tanstaafl <tanstaafl@libertytrek.org> wrote:
>> On 2013-02-07 12:53 PM, Peter Humphrey <peter@humphrey.ukfsn.org> 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 to change
>>> the tile type of a /dev line, not /dev/shm.
>>
>>
>> Oh... well, glad I asked...
>>
>> Can anyone (a dev maybe) please confirm this?
>>
>> 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.
>
> The important thing to note is that entries for precisely /dev and
> /proc don't need to be in fstab at all for most people if they are
> using the standard gentoo openrc/udev combination. I have 3 gentoo
> systems running latest ~amd64 openrc and udev and none have /dev or
> /proc in fstab and all boot up just fine for me. Obviously if you are
> experimenting with other init system or udev alternatives then YMMV
> but those people are probably smart enough to figure it out for
> themselves already. :)

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 system (I think), /dev and /proc
are unnecessary (and perhaps even problematic) in /etc/fstab.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Stefan G. Weichinger]

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 system (I think), /dev and /proc
> are unnecessary (and perhaps even problematic) in /etc/fstab.

In my fstab there is the line(s):

# NOTE: The next line is critical for boot!
proc                    /proc           proc            defaults        0 0

both outdated?

;-)

Stefan

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1108 bytes --]

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 udev work, so with a recent
> > version of udev, no matter the init system (I think), /dev and /proc
> > are unnecessary (and perhaps even problematic) in /etc/fstab.
> 
> In my fstab there is the line(s):
> 
> # NOTE: The next line is critical for boot!
> proc                    /proc           proc            defaults        0 0
> 
> both outdated?
> 
> ;-)

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 memory if not populated with files)
tmpfs           /dev/shm        tmpfs           nodev,nosuid,noexec     0 0

-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Dale]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

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 memory if not
populated with files) tmpfs /dev/shm tmpfs nodev,nosuid,noexec 0 0

+1

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 845 bytes --]

Re: [gentoo-user] udev-191 bit me. Insufficient ptys

[Stefan G. Weichinger]

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/shrinkable ramdisk, and will # use almost no memory if not
> populated with files) tmpfs /dev/shm tmpfs nodev,nosuid,noexec 0 0
> 
> +1

Addition:

I even had that wrong and it worked:

"patch" ->

-shm                    /dev/shm        tmpfs
nodev,nosuid,noexec     0 0
+tmpfs                  /dev/shm        tmpfs
nodev,nosuid,noexec     0 0

Stefan