Re: [gentoo-user] Systemd reaches "target Emergency Mode" every boot
On Sun, Jan 27, 2013 at 10:07 PM, João Matos wrote: > title Gentoo Linux 3.7.1 systemd > root (hd0,0) > kernel /boot/thekernel2 root=/dev/sda1 rootfstype=ext4 init=/bin/systemd > vga=0x31B resume=/dev/sda3 journalctl -b > Why do you have "journalctl -b" in there? That makes no sense. Also, the "-b" is what is causing systemd to start emergency.target.
Re: [gentoo-user] Systemd reaches "target Emergency Mode" every boot
title Gentoo Linux 3.7.1 systemd root (hd0,0) kernel /boot/thekernel2 root=/dev/sda1 rootfstype=ext4 init=/bin/systemd vga=0x31B resume=/dev/sda3 journalctl -b 2013/1/27 Mike Gilbert > On Sun, Jan 27, 2013 at 5:14 PM, João Matos wrote: > > Is there any way it is not in the "default mode"? > > > > Can you post your complete kernel command line? > > -- João de Matos Linux User #461527 Graduando em Engenharia de Computação 2005.1 UEFS - Universidade Estadual de Feira de Santana
Re: [gentoo-user] openpty() failing with UNIX98 ptys
On Sunday 27 January 2013 04:46:22 Mike Edenfield wrote: > At some point recently, one of my systems has begun having problems > allocating pseudo-terminals via the UNIX98 pty scheme. I am using the > same kernel configuration I've had for years, and running the latest > ~amd64 version of all the relevant packages. The problem manifests > itself on any program that attempts to allocate a pseudo-terminal, > including portage and openssh. I first noticed the problem when I could > no longer ssh into the server because it would not allocate a pty. > > I have the latest udev installed, and udev-mount is running on boot. Both > /dev and /dev/pts are mounted, and /dev/ptmx exists and is > world-readable: What does 'grep devtmpfs /etc/fstab' reveal? (Long shot - I misread the latest news article and changed one of the tmpfs fields to devtmpfs and got similar results to what you describe.) -- Peter
Re: [gentoo-user] udev-197: what to do -- S0LVED
On Sat, Jan 26 2013, Allan Gottlieb wrote:
> I have read the news item and still have questions. The news item
> covers several points.
>
> 1. remove udev-postmount:
>I did this but worry that I now cannot reboot until I upgrade
>udev. Is that correct?
>
> 2. Add CONFIG_DEVTMPFS=y. Easy. Kernel rebuilt and installed
>in /boot (but have not rebooted).
>
> 3. Predictable network interface names.
>I have the problematic udev rule.
>Specifically 70-persistent-net.rules has (on one line)
>
>SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
>KERNEL=="eth*", NAME="eth0"
>
>I read the bug report, but it is not as clear as I would like.
>Is it true that I can change my file to simply
>
>SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
>ATTR{address}=="00:1e:c9:48:f9:a0", ATTR{type}=="1",
>KERNEL=="eth*", NAME="net0"
>
>That is just change the NAME from eth0 to net0 ?
>
> 4. No support for kernels older than 2.6.39. No problem.
>
> 5. Separate /usr not affected. Good.
>
> The news item does not mention the problem of moving files
> from /usr/lib/udev/rules.d to /lib/udev/rules.d. Am I correct in
> believing that we still need one of the equivalents of
>equery belongs -n /usr/lib/udev | xargs emerge -pv
Thanks for all the suggestions. I did the following, which worked.
1. Built and installed kernel with CONFIG_DEVTMPFS=y
2. Moved udev-postmount back to /etc/init.d (I had moved it to /tmp).
rc-update add udev-postmount default.
3. Reboot with new kernel (udev unchanged). Success.
4. Changed NAME=eth0 to NAME=net0 in 70-persistent-net.rules and
eliminated clauses so have only (on one line)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1e:c9:48:f9:a0",
NAME="net0"
Corresponding changes to /etc/init.d /etc/runlevels/default
5. Emerge update world to get new udev (just -1 udev has blocks)
6. Change kernel configs as per udisks emerge output
7. /usr/lib/udev already empty (due to make world?) so nothing to do
8. Reboot with new kernel. Success
allan
Re: [gentoo-user] udev-197 USE=kmod
Am 27.01.2013 22:01, schrieb Canek Peláez Valdés: > On Sun, Jan 27, 2013 at 4:30 AM, Florian Philipp > wrote: >> Am 27.01.2013 03:24, schrieb Canek Peláez Valdés: >>> On Sat, Jan 26, 2013 at 6:15 PM, Florian Philipp >>> wrote: Hi list! Quick question: If I deactivate the kmod use flag in udev and keep sys-apps/module-init-tools, does udev still load modules or is kmod a required flag for that? >>> >>> I'm not 100% sure, but I don't think so. The git repository has not a >>> single instance of the strings "modprobe" or "insmod", apparently the >>> only way to load modules in udev is to use kmod. I think the kmod >>> configure option (which is the one the USE flag activate/deactivate), >>> is for systems where all the modules are built-in, like embedded ones. >>> >> >> Okay. I thought I've heard about some dev patching udev to work with >> modprobe at one point. Could be mistaken or outdated, though. > > The patches in the ebuild don't include anything to use modprobe: > > http://dev.gentoo.org/~williamh/dist/udev-197-patches-1.tar.bz2 > Thanks for looking! >>> Unless udev has no other means to load modules, I think disabling kmod >>> assumes then that all the modules are built-in. And if you use >>> modules, may I ask why you would prefer module-init-tools over kmod? >>> Specially when the later is a drop-in, better supported replacement? >>> >> >> Is it really a drop-in? I was under the impression that for example >> `modprobe -l` is not implemented (mentioned in a comment on the eudev >> fork on LWN). I guess that's outdated as well. > > No, modprobe -l is not supported, but it's trivially to emulate, and > the option was already deprecated in module-init-tools. From the kmod > README: > > "kmod-modprobe gained several features to be a 1:1 replacement for > modprobe. The only missing things are the options '--showconfig' and > '-t / -l'. These last ones have been deprecated long ago and they will > be removed from modprobe. A lot of effort has been put on > kmod-modprobe to ensure it maintains compabitility with modprobe." > > As you yourself commented, using an alias with find more than enough. > > Regards. Yeah, easy enough when you know your way around shell scripts and know where to look. In my opinion, it is still kind of stupid to remove a useful feature with no replacement. Hmm, maybe it's time to write a better replacement. Something more like eix, just for modules ... Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: openpty() failing with UNIX98 ptys
On 01/27/2013 10:48 AM, Alan McKinnon wrote: > I had something similar (details are different though): > > All my virt consoles went away and I couldn't get to them after X > starts. Ctrl-Alt-F1 left the X screen as-is and it wouldn't blank and > give me the KMS framebuffer. Ctrl-Alt-F7 brought X back. > > In my case it's kernel 3.7 - no version of gentoo-sources-3.7-* worked > and 3.6.11 works fine. I'm not seeing that problem. You could do a diff on the /boot/config* files and look for missing stuff in your 3.7 kernels.
RE: [gentoo-user] openpty() failing with UNIX98 ptys
> From: Alan McKinnon [mailto:alan.mckin...@gmail.com] > Sent: Sunday, January 27, 2013 1:49 PM > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] openpty() failing with UNIX98 ptys > > On Sat, 26 Jan 2013 23:46:22 -0500 > "Mike Edenfield" wrote: > > > I have the latest udev installed, and udev-mount is running on > boot. > > Both /dev and /dev/pts are mounted, and /dev/ptmx exists and is > > world-readable: > > > > basement package.use # mount | grep /dev > > /dev/root on / type ext3 > > (rw,seclabel,noatime,errors=continue,barrier=1,data=writeback) > > devpts on /dev/pts type devpts > > (rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) > > shm on /dev/shm type tmpfs > (rw,seclabel,nosuid,nodev,noexec,relatime) > > udev on /dev type devtmpfs > > (rw,seclabel,nosuid,relatime,size=10240k,nr_inodes=248584,mode=755) > > > > basement package.use # ls -alF /dev/ptmx /dev/pts > > crw-rw-rw-. 1 root tty 5, 2 Jan 26 13:18 /dev/ptmx > > > > /dev/pts: > > total 0 > > drwxr-xr-x. 2 root root40 Jan 26 13:18 ./ > > drwxr-xr-x. 10 root root 13300 Jan 26 13:18 ../ > > > > When I trace sshd's attempt to open a new pty, I see it doing this: > > > > * open /dev/ptmx > > * stat /dev/pts > > * stat /dev > > * try (and fail) to open /dev/ptyp0 > > > > Since I know that last bit is openssh trying to open an old-style > BSD > > pty, I can only assume that something is going wrong trying to > > allocate the pty the correct way. > > > > For the time being I've added BSD pty support into my kernel and > > everything seems to be working now, but I'm at a loss as to what I > > did to break things in the first place. > > I had something similar (details are different though): > In my case it's kernel 3.7 - no version of gentoo-sources-3.7-* > worked > and 3.6.11 works fine. > > What kernel are you on? > Have you tested this on 3.6? I first notice the problem on 3.4.2, upgraded to 3.6.4 and the problem persisted. I have not upgraded to 3.7 to see if it's still a problem. --Mike
Re: [gentoo-user] Systemd reaches "target Emergency Mode" every boot
On Sun, Jan 27, 2013 at 5:14 PM, João Matos wrote: > Is there any way it is not in the "default mode"? > Can you post your complete kernel command line?
Re: [gentoo-user] Systemd reaches "target Emergency Mode" every boot
Is there any way it is not in the "default mode"? when it stoped, instead of hitting Ctrl D, I taped my password and "systemctl default", so it could try to start again the default boot process. And it worked. I'll not try the downgrade right now bcz, after a emerge --sync, my portage started do complain about compiling net-misc/networkmanager with support for both systemd and consolekit, but I'm not able to disable consolekit support. So I'll wait them to fix it. 2013/1/27 João Matos > > > > 2013/1/27 Canek Peláez Valdés > >> On Sun, Jan 27, 2013 at 12:31 PM, João Matos wrote: >> > >> > >> > >> > 2013/1/26 Canek Peláez Valdés >> >> >> >> On Sat, Jan 26, 2013 at 7:08 PM, João Matos wrote: >> >> > Hi list, >> >> > >> >> > I'm having this problem for a while, but I've decided to solve it >> know. >> >> > Every time I boot my system (couple times a day), I have to hid Ctrl >> + D >> >> > when the boot process is interrupted by the "emergency mode". >> >> > >> >> > I think it started when I was compiling the kernel myself, and >> removing >> >> > lot >> >> > of stuff. Although, I checked and the mandatory options for systemd >> are >> >> > ok. >> >> > >> >> > When I run "journalctl -b -p err" the only information I get is: >> >> > >> >> > Jan 26 20:29:20 KONOHA NetworkManager[1497]: claim_connection: >> assertion >> >> > `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed >> >> > Jan 26 20:29:24 localhost dhcpcd[1557]: wlan0: sendmsg: Cannot assign >> >> > requested address >> >> > Jan 26 20:30:42 localhost pulseaudio[2073]: [pulseaudio] pid.c: >> Daemon >> >> > already running. >> >> > Jan 26 20:30:42 localhost pulseaudio[2080]: [pulseaudio] pid.c: >> Daemon >> >> > already running. >> >> > >> >> > It give me no clue. >> >> > >> >> > Attached the .conf from my gentoo-3.7.1 >> >> > >> >> > After I hit Ctrl + D, the system works normally. >> >> > >> >> > Any help will be appreciated :) >> >> >> >> Are you using udev-197 with systemd-197? mgorny masked it, and said >> >> this in package.mask: >> > >> > >> > I'm using them. Last time I updated my system there weren't any warning. >> > Anyway, this problem is happening since the previous version. >> > >> >> >> >> # Does not boot. Something with udev is probably broken. Feel free >> >> # to unmask, debug and provide me with a patch. >> >> >> >> You need to be using the same version for udev and systemd (they are >> >> the same package). If you are using the same version for udev and >> >> systemd, are you using an initramfs? When was the last time you built >> >> it, if you do? >> > >> > >> > I don't have initramfs. Just the kernel. But it used to work normaly. >> >> >> >> >> >> Could you boot with "systemd.log_target=kmsg" and >> >> "systemd.log_level=debug", and post the whole output of "journalctl >> >> -b"? It prints only the logs from the last boot. >> >> >> > >> > journalctl -b attached. >> >> From your logs: >> >> Jan 27 15:16:27 KONOHA systemd[1]: Activating default unit: >> emergency.target >> >> You have emergency.target as default unit. The default.target can be >> set in different ways: >> >> - Check /usr/lib64/systemd/system/default.target >> > > Nothing found here. The file is: > > [Unit] > Description=Graphical Interface > Documentation=man:systemd.special(7) > Requires=multi-user.target > After=multi-user.target > Conflicts=rescue.target > Wants=display-manager.service > AllowIsolate=yes > > [Install] > Alias=default.target > > > - Check /etc/systemd/system/default.target >> > > doesn't exist. > > >> - Check if you use --unit=emergency.target in your grub config >> - Check if you pass the "emergency" kernel parametr in your grub config >> > > Nothing wrong with grub. > > >> udev-197 in the tree installs everything to /; systemd-197 installs to >> /usr. I'm pretty sure that is not going to end well; I haven't >> upgraded to 197 in neither package. >> >> Check your default.target; for some reason is set to emergency. >> >> Regards. >> -- >> Canek Peláez Valdés >> Posgrado en Ciencia e Ingeniería de la Computación >> Universidad Nacional Autónoma de México >> >> > I've also tryed "systemctl disable emergency.service" and "systemctl > disable emergency.target" before but got nothing. > > Anyway, thank you for your help :). I'll try to downgrade. But I still > think it is about kernel config. > > -- > João de Matos > Linux User #461527 > Graduando em Engenharia de Computação 2005.1 > UEFS - Universidade Estadual de Feira de Santana > -- João de Matos Linux User #461527 Graduando em Engenharia de Computação 2005.1 UEFS - Universidade Estadual de Feira de Santana
Re: [gentoo-user] Systemd reaches "target Emergency Mode" every boot
2013/1/27 Canek Peláez Valdés > On Sun, Jan 27, 2013 at 12:31 PM, João Matos wrote: > > > > > > > > 2013/1/26 Canek Peláez Valdés > >> > >> On Sat, Jan 26, 2013 at 7:08 PM, João Matos wrote: > >> > Hi list, > >> > > >> > I'm having this problem for a while, but I've decided to solve it > know. > >> > Every time I boot my system (couple times a day), I have to hid Ctrl > + D > >> > when the boot process is interrupted by the "emergency mode". > >> > > >> > I think it started when I was compiling the kernel myself, and > removing > >> > lot > >> > of stuff. Although, I checked and the mandatory options for systemd > are > >> > ok. > >> > > >> > When I run "journalctl -b -p err" the only information I get is: > >> > > >> > Jan 26 20:29:20 KONOHA NetworkManager[1497]: claim_connection: > assertion > >> > `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed > >> > Jan 26 20:29:24 localhost dhcpcd[1557]: wlan0: sendmsg: Cannot assign > >> > requested address > >> > Jan 26 20:30:42 localhost pulseaudio[2073]: [pulseaudio] pid.c: Daemon > >> > already running. > >> > Jan 26 20:30:42 localhost pulseaudio[2080]: [pulseaudio] pid.c: Daemon > >> > already running. > >> > > >> > It give me no clue. > >> > > >> > Attached the .conf from my gentoo-3.7.1 > >> > > >> > After I hit Ctrl + D, the system works normally. > >> > > >> > Any help will be appreciated :) > >> > >> Are you using udev-197 with systemd-197? mgorny masked it, and said > >> this in package.mask: > > > > > > I'm using them. Last time I updated my system there weren't any warning. > > Anyway, this problem is happening since the previous version. > > > >> > >> # Does not boot. Something with udev is probably broken. Feel free > >> # to unmask, debug and provide me with a patch. > >> > >> You need to be using the same version for udev and systemd (they are > >> the same package). If you are using the same version for udev and > >> systemd, are you using an initramfs? When was the last time you built > >> it, if you do? > > > > > > I don't have initramfs. Just the kernel. But it used to work normaly. > >> > >> > >> Could you boot with "systemd.log_target=kmsg" and > >> "systemd.log_level=debug", and post the whole output of "journalctl > >> -b"? It prints only the logs from the last boot. > >> > > > > journalctl -b attached. > > From your logs: > > Jan 27 15:16:27 KONOHA systemd[1]: Activating default unit: > emergency.target > > You have emergency.target as default unit. The default.target can be > set in different ways: > > - Check /usr/lib64/systemd/system/default.target > Nothing found here. The file is: [Unit] Description=Graphical Interface Documentation=man:systemd.special(7) Requires=multi-user.target After=multi-user.target Conflicts=rescue.target Wants=display-manager.service AllowIsolate=yes [Install] Alias=default.target - Check /etc/systemd/system/default.target > doesn't exist. > - Check if you use --unit=emergency.target in your grub config > - Check if you pass the "emergency" kernel parametr in your grub config > Nothing wrong with grub. > udev-197 in the tree installs everything to /; systemd-197 installs to > /usr. I'm pretty sure that is not going to end well; I haven't > upgraded to 197 in neither package. > > Check your default.target; for some reason is set to emergency. > > Regards. > -- > Canek Peláez Valdés > Posgrado en Ciencia e Ingeniería de la Computación > Universidad Nacional Autónoma de México > > I've also tryed "systemctl disable emergency.service" and "systemctl disable emergency.target" before but got nothing. Anyway, thank you for your help :). I'll try to downgrade. But I still think it is about kernel config. -- João de Matos Linux User #461527 Graduando em Engenharia de Computação 2005.1 UEFS - Universidade Estadual de Feira de Santana
Re: [gentoo-user] Systemd reaches "target Emergency Mode" every boot
On Sun, Jan 27, 2013 at 12:31 PM, João Matos wrote: > > > > 2013/1/26 Canek Peláez Valdés >> >> On Sat, Jan 26, 2013 at 7:08 PM, João Matos wrote: >> > Hi list, >> > >> > I'm having this problem for a while, but I've decided to solve it know. >> > Every time I boot my system (couple times a day), I have to hid Ctrl + D >> > when the boot process is interrupted by the "emergency mode". >> > >> > I think it started when I was compiling the kernel myself, and removing >> > lot >> > of stuff. Although, I checked and the mandatory options for systemd are >> > ok. >> > >> > When I run "journalctl -b -p err" the only information I get is: >> > >> > Jan 26 20:29:20 KONOHA NetworkManager[1497]: claim_connection: assertion >> > `nm_connection_get_path (NM_CONNECTION (connection)) == NULL' failed >> > Jan 26 20:29:24 localhost dhcpcd[1557]: wlan0: sendmsg: Cannot assign >> > requested address >> > Jan 26 20:30:42 localhost pulseaudio[2073]: [pulseaudio] pid.c: Daemon >> > already running. >> > Jan 26 20:30:42 localhost pulseaudio[2080]: [pulseaudio] pid.c: Daemon >> > already running. >> > >> > It give me no clue. >> > >> > Attached the .conf from my gentoo-3.7.1 >> > >> > After I hit Ctrl + D, the system works normally. >> > >> > Any help will be appreciated :) >> >> Are you using udev-197 with systemd-197? mgorny masked it, and said >> this in package.mask: > > > I'm using them. Last time I updated my system there weren't any warning. > Anyway, this problem is happening since the previous version. > >> >> # Does not boot. Something with udev is probably broken. Feel free >> # to unmask, debug and provide me with a patch. >> >> You need to be using the same version for udev and systemd (they are >> the same package). If you are using the same version for udev and >> systemd, are you using an initramfs? When was the last time you built >> it, if you do? > > > I don't have initramfs. Just the kernel. But it used to work normaly. >> >> >> Could you boot with "systemd.log_target=kmsg" and >> "systemd.log_level=debug", and post the whole output of "journalctl >> -b"? It prints only the logs from the last boot. >> > > journalctl -b attached. >From your logs: Jan 27 15:16:27 KONOHA systemd[1]: Activating default unit: emergency.target You have emergency.target as default unit. The default.target can be set in different ways: - Check /usr/lib64/systemd/system/default.target - Check /etc/systemd/system/default.target - Check if you use --unit=emergency.target in your grub config - Check if you pass the "emergency" kernel parametr in your grub config udev-197 in the tree installs everything to /; systemd-197 installs to /usr. I'm pretty sure that is not going to end well; I haven't upgraded to 197 in neither package. Check your default.target; for some reason is set to emergency. 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-197 USE=kmod
On Sun, Jan 27, 2013 at 4:30 AM, Florian Philipp wrote: > Am 27.01.2013 03:24, schrieb Canek Peláez Valdés: >> On Sat, Jan 26, 2013 at 6:15 PM, Florian Philipp >> wrote: >>> Hi list! >>> >>> Quick question: If I deactivate the kmod use flag in udev and keep >>> sys-apps/module-init-tools, does udev still load modules or is kmod a >>> required flag for that? >> >> I'm not 100% sure, but I don't think so. The git repository has not a >> single instance of the strings "modprobe" or "insmod", apparently the >> only way to load modules in udev is to use kmod. I think the kmod >> configure option (which is the one the USE flag activate/deactivate), >> is for systems where all the modules are built-in, like embedded ones. >> > > Okay. I thought I've heard about some dev patching udev to work with > modprobe at one point. Could be mistaken or outdated, though. The patches in the ebuild don't include anything to use modprobe: http://dev.gentoo.org/~williamh/dist/udev-197-patches-1.tar.bz2 >> Unless udev has no other means to load modules, I think disabling kmod >> assumes then that all the modules are built-in. And if you use >> modules, may I ask why you would prefer module-init-tools over kmod? >> Specially when the later is a drop-in, better supported replacement? >> > > Is it really a drop-in? I was under the impression that for example > `modprobe -l` is not implemented (mentioned in a comment on the eudev > fork on LWN). I guess that's outdated as well. No, modprobe -l is not supported, but it's trivially to emulate, and the option was already deprecated in module-init-tools. From the kmod README: "kmod-modprobe gained several features to be a 1:1 replacement for modprobe. The only missing things are the options '--showconfig' and '-t / -l'. These last ones have been deprecated long ago and they will be removed from modprobe. A lot of effort has been put on kmod-modprobe to ensure it maintains compabitility with modprobe." As you yourself commented, using an alias with find more than enough. 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] Subdirectories on NFS server missing 'executable' permission
On 27.01.13 19:21, Alan McKinnon wrote: > so essentially you have an nfs client that by design can't do nfs? You could put it that way. I purchased this satellite receiver a few days ago and upgraded to the latest firmware available (version 1.2.61 released 2013-01-07). Unfortunately, the manufacturer's support page and FAQ are available in Greek only. :-/ > What does the vendor say about this? I'll try to contact the vendor tomorrow (Monday). -Ralph
Re: [gentoo-user] openpty() failing with UNIX98 ptys
On Sat, 26 Jan 2013 23:46:22 -0500 "Mike Edenfield" wrote: > At some point recently, one of my systems has begun having problems > allocating pseudo-terminals via the UNIX98 pty scheme. I am using the > same kernel configuration I've had for years, and running the latest > ~amd64 version of all the relevant packages. The problem manifests > itself on any program that attempts to allocate a pseudo-terminal, > including portage and openssh. I first noticed the problem when I > could no longer ssh into the server because it would not allocate a > pty. > > I have the latest udev installed, and udev-mount is running on boot. > Both /dev and /dev/pts are mounted, and /dev/ptmx exists and is > world-readable: > > basement package.use # mount | grep /dev > /dev/root on / type ext3 > (rw,seclabel,noatime,errors=continue,barrier=1,data=writeback) > devpts on /dev/pts type devpts > (rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) > shm on /dev/shm type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime) > udev on /dev type devtmpfs > (rw,seclabel,nosuid,relatime,size=10240k,nr_inodes=248584,mode=755) > > basement package.use # ls -alF /dev/ptmx /dev/pts > crw-rw-rw-. 1 root tty 5, 2 Jan 26 13:18 /dev/ptmx > > /dev/pts: > total 0 > drwxr-xr-x. 2 root root40 Jan 26 13:18 ./ > drwxr-xr-x. 10 root root 13300 Jan 26 13:18 ../ > > When I trace sshd's attempt to open a new pty, I see it doing this: > > * open /dev/ptmx > * stat /dev/pts > * stat /dev > * try (and fail) to open /dev/ptyp0 > > Since I know that last bit is openssh trying to open an old-style BSD > pty, I can only assume that something is going wrong trying to > allocate the pty the correct way. > > For the time being I've added BSD pty support into my kernel and > everything seems to be working now, but I'm at a loss as to what I > did to break things in the first place. I had something similar (details are different though): All my virt consoles went away and I couldn't get to them after X starts. Ctrl-Alt-F1 left the X screen as-is and it wouldn't blank and give me the KMS framebuffer. Ctrl-Alt-F7 brought X back. In my case it's kernel 3.7 - no version of gentoo-sources-3.7-* worked and 3.6.11 works fine. What kernel are you on? Have you tested this on 3.6? -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: openpty() failing with UNIX98 ptys
On 01/26/2013 08:46 PM, Mike Edenfield wrote: > At some point recently, one of my systems has begun having problems > allocating pseudo-terminals via the UNIX98 pty scheme. I am using the same > kernel configuration I've had for years, and running the latest ~amd64 > version of all the relevant packages. The problem manifests itself on any > program that attempts to allocate a pseudo-terminal, including portage and > openssh. I first noticed the problem when I could no longer ssh into the > server because it would not allocate a pty. > > I have the latest udev installed, and udev-mount is running on boot. Both > /dev and /dev/pts are mounted, and /dev/ptmx exists and is world-readable: > > basement package.use # mount | grep /dev > /dev/root on / type ext3 > (rw,seclabel,noatime,errors=continue,barrier=1,data=writeback) > devpts on /dev/pts type devpts > (rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) > shm on /dev/shm type tmpfs (rw,seclabel,nosuid,nodev,noexec,relatime) > udev on /dev type devtmpfs > (rw,seclabel,nosuid,relatime,size=10240k,nr_inodes=248584,mode=755) > > basement package.use # ls -alF /dev/ptmx /dev/pts > crw-rw-rw-. 1 root tty 5, 2 Jan 26 13:18 /dev/ptmx > > /dev/pts: > total 0 > drwxr-xr-x. 2 root root40 Jan 26 13:18 ./ > drwxr-xr-x. 10 root root 13300 Jan 26 13:18 ../ > > When I trace sshd's attempt to open a new pty, I see it doing this: > > * open /dev/ptmx > * stat /dev/pts > * stat /dev > * try (and fail) to open /dev/ptyp0 > > Since I know that last bit is openssh trying to open an old-style BSD pty, I > can only assume that something is going wrong trying to allocate the pty the > correct way. > > For the time being I've added BSD pty support into my kernel and everything > seems to be working now, but I'm at a loss as to what I did to break things > in the first place. Do you have any files left in /usr/lib/udev ? If so, try re-emerging the package that owns those files.
Re: [gentoo-user] Subdirectories on NFS server missing 'executable' permission
On Sun, 27 Jan 2013 18:46:30 +0100 Ralph Seichter wrote: > On 27.01.13 17:23, Alan McKinnon wrote: > > > You config certainly looks right to me, and I don't know of any > > config that makes it work differently. > > I suspected as much. The trouble is that the Pingulux is unable to > write data to the directories it creates. Thus, your idea of using > chmod from a cron job won't help. I can only assume that the shell's > umask 0022 is not being used by the process which records video data. > Bummer. so essentially you have an nfs client that by design can't do nfs? assuming that the gadget creates a directory in which to store the video it's about to record that is. What does the vendor say about this? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Subdirectories on NFS server missing 'executable' permission
On 27.01.13 17:23, Alan McKinnon wrote: > You config certainly looks right to me, and I don't know of any config > that makes it work differently. I suspected as much. The trouble is that the Pingulux is unable to write data to the directories it creates. Thus, your idea of using chmod from a cron job won't help. I can only assume that the shell's umask 0022 is not being used by the process which records video data. Bummer. -Ralph
Re: [gentoo-user] Subdirectories on NFS server missing 'executable' permission
On Sun, 27 Jan 2013 00:54:52 +0100 Ralph Seichter wrote: > On 27.01.13 00:04, Alan McKinnon wrote: > > > What sort of client is this, and what umask is it using? > > The client is an Edision Argus Pingulux Plus satellite receiver. > > [root@stlinux]#uname -a > Linux stlinux 2.6.32.42_stm24_V4.1-SAT7111_7111-STSDK #56 PREEMPT Tue > Oct 16 16:17:14 CST 2012 sh4 GNU/Linux > > > That's regular shell umask, not some fancy thing related to fs > > mounts. > > [root@stlinux]#umask > 0022 > > This umask looks OK to me. > > -Ralph > You config certainly looks right to me, and I don't know of any config that makes it work differently. I've always found default permissions on NFS shares to be a difficult thing to implement. One can do it with POSIX file attributes on the server but I always found that cumbersome and very susceptible to being forgotten about I usually end up running chmod in a cron on the server :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] udev-197 USE=kmod
Am 27.01.2013 12:33, schrieb Matthias Hanft: > Florian Philipp wrote: >> >> Is it really a drop-in? I was under the impression that for example >> `modprobe -l` is not implemented (mentioned in a comment on the eudev >> fork on LWN). I guess that's outdated as well. > > I'm using kmod's modprobe, and there is *no* "-l" option. > > -Matt > Hmm, any replacement in sight? Otherwise I guess I'll use an alias like this: alias modprobe-l="find \"/lib64/modules/\$(uname -r)\" -name '*.ko' -printf '%P\n'" signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] udev-197 USE=kmod
Florian Philipp wrote: > > Is it really a drop-in? I was under the impression that for example > `modprobe -l` is not implemented (mentioned in a comment on the eudev > fork on LWN). I guess that's outdated as well. I'm using kmod's modprobe, and there is *no* "-l" option. -Matt
Re: [gentoo-user] udev-197: what to do
Am 26.01.2013 19:30, schrieb Allan Gottlieb: > I have read the news item and still have questions. The news item > covers several points. > > 1. remove udev-postmount: >I did this but worry that I now cannot reboot until I upgrade >udev. Is that correct? > It's a bit of a gamble but I guess the worst that could happen is that you are dropped into a basic shell. Then it is easy to add udev-postmount again and reboot. > The news item does not mention the problem of moving files > from /usr/lib/udev/rules.d to /lib/udev/rules.d. Am I correct in > believing that we still need one of the equivalents of >equery belongs -n /usr/lib/udev | xargs emerge -pv > > I used that successfully when one of my testing systems went to > udev-197. I would think it is needed (before reboot) on my stable > systems as well so I am surprised it is not in the news item. > I wondered about this as well but at least on my systems, /usr/lib/udev is already gone. I guess all packages were rev-bumped to fix it. BTW: A fast way to express `equery belongs -n /usr/lib/udev | xargs emerge -pv` is simply `emerge -pv1 /usr/lib/udev` Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] udev-197 USE=kmod
Am 27.01.2013 03:24, schrieb Canek Peláez Valdés: > On Sat, Jan 26, 2013 at 6:15 PM, Florian Philipp > wrote: >> Hi list! >> >> Quick question: If I deactivate the kmod use flag in udev and keep >> sys-apps/module-init-tools, does udev still load modules or is kmod a >> required flag for that? > > I'm not 100% sure, but I don't think so. The git repository has not a > single instance of the strings "modprobe" or "insmod", apparently the > only way to load modules in udev is to use kmod. I think the kmod > configure option (which is the one the USE flag activate/deactivate), > is for systems where all the modules are built-in, like embedded ones. > Okay. I thought I've heard about some dev patching udev to work with modprobe at one point. Could be mistaken or outdated, though. > Unless udev has no other means to load modules, I think disabling kmod > assumes then that all the modules are built-in. And if you use > modules, may I ask why you would prefer module-init-tools over kmod? > Specially when the later is a drop-in, better supported replacement? > Is it really a drop-in? I was under the impression that for example `modprobe -l` is not implemented (mentioned in a comment on the eudev fork on LWN). I guess that's outdated as well. Thanks, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] udev-197: what to do
Allan Gottlieb wrote: > > 1. remove udev-postmount: >I did this but worry that I now cannot reboot until I upgrade >udev. Is that correct? Based on my experience, you just don't care about udev-postmount. It will automagically be removed when you upgrade from udev-171 to udev-197. -Matt
