/dev/pts and /dev/shm not mounted on boot

Please subscribe a log of the upgrade, output of "mount" and "ls -l /dev"

No response received in a month, please re-open if you can supply the requested information.

I do not have an upgrade log since I update often. But after a month of updates nothing changed.

On boot after a couple of kernel messages there are two warnings:

* Mount point '/dev/pts' does not exist. Skipping mount.
* Mount point '/dev/shm' does not exist. Skipping mount.

I have added both to `/etc/fstab` but even that does not work automatically, I still have to switch to console and type `sudo mount /dev/pts`

Note that the last two lines of output, the ones in question, appeared only after I manually mounted them with these options.

udev 137-2
linux 2.6.28-8-generic
initramfs-tools 0.92bubuntu21

Provide the output of:

 ls /lib/udev/devices

Also provide the output of "ls -l /dev"

and please don't work around the problem first, otherwise you'll just show me a working system and that would be unhelpful ;)

That's how /dev looks just after boot.

This still exists on jaunty/8.10 with all updates installed to date.

sudo mount -t devpts devpts /dev/pts is still required after reboot to access gnome-terminal, konsole etc.
I wonder if shm is configured properly, because on some apps I get (those using pulseaudio, I guess) E: shm.c: shm_open() failed: permission denied

output of mount
/dev/sda5 on / type ext3 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,nosuid,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
shmfs on /lib/init/rw/splashy type tmpfs (rw)
/dev/sda1 on /boot type ext3 (rw,relatime)
/dev/sda6 on /home type xfs (rw,relatime)
tmpfs on /lib/modules/2.6.28-8-generic/volatile type tmpfs (rw,mode=0755)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
/home/jarkko/.Private on /home/jarkko/Private type ecryptfs (ecryptfs_sig=4829f9ebdef48fcd,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)
nfsd on /proc/fs/nfsd type nfsd (rw)
gvfs-fuse-daemon on /home/jarkko/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=jarkko)
devpts on /dev/pts type devpts (rw)

I am at a loss to explain this one, your /dev clearly contains a /dev/pts and /dev/shm directory so I have no idea why you're seeing mount complaining that the mount point does not exist.

There was a suspicious line in your mount output:

shmfs on /lib/init/rw/splashy type tmpfs (rw)

if shmfs is already mounted, perhaps this could cause it. What is "splashy" and where did you download it from?

There is no splashy or any other shmfs on my system so that is not the cause.

What is strange that /etc/init.d/mountdevsubfs.sh which should mount those, does nothing when called, even if manual mount /dev/pts succeeds. I think when I tried to see why, the code

        if mountpoint -q "$MTPT"
        then
                return # Already mounted
        fi

would return from /lib/init/mount-functions.sh and thus not do anything, although the directory exists and the two filesystems are not mounted. Probably some permissions are wrong?

As I have said earlier, this behaviour was introduced by udev 137 or 136 and everything worked if I downgraded to the version from intrepid (124-something), not touching any other packages.

On Fri, 2009-03-13 at 16:45 +0000, Gediminas Paulauskas wrote:

> As I have said earlier, this behaviour was introduced by udev 137 or 136
> and everything worked if I downgraded to the version from intrepid
> (124-something), not touching any other packages.
>
This init script isn't even supplied by udev - it's part of the
initscripts package, so that doesn't make any sense.

Scott
--
Scott James Remnant
<email address hidden>

mountdevsubfs.sh script comes from initscripts, it uses lsb functions, but that's not the point -- it tries to mount /dev/pts but thinks it either does not exist or is mounted and skipts that. So I suspect permissions problem, or initramfs problem. I would like to help solve that but don't know a way to debug things that early in the boot process.

I'm having the same issue after upgrading from Intrepid to Jaunty. If there is any info I can provide to help resolve just let me know.

Just to provide a little more info. I'm running server. Now I'm mounting /dev/pts with rc.local until I can get this resolved.

On Fri, 2009-03-27 at 00:58 +0000, BrandonG777 wrote:

> I'm having the same issue after upgrading from Intrepid to Jaunty. If
> there is any info I can provide to help resolve just let me know.
>
At this point, I'm unable to provide any debugging suggestions - I have
no idea why this isn't working for you; every test suggests this should
just work.

There's no logical reason why it should fail in the boot scripts, but
then succeed when you try it yourself later. Especially not since it
seems to only fail for you three!

Scott
--
Scott James Remnant
<email address hidden>

When I upgraded I did have some cpan packages installed, which I had to track down afterwards and uninstall. So I got that cleaned up and then did apt-get --reinstall install udev lsb-base initscripts But I'm still having an issue with this. I can't even find anything in any of the logs where it actually reports any sort of error when it fails. The only indication of any problem is the local console on boot. Shouldn't there be some kind of log where it failed that could provide me some more info?

I found some evidence about this issue. When booting in rescue mode there's a message on the screen saying "/dev/pts does not exists. Cannot ..." this message is not recorded in any of the log files in /var/log.

I've tarred everything in /etc if this could help solve this issue.

The problems manifests itself during the executing of /lib/init/mount-functions.sh near line 110.

        if [ ! -d "$MTPT" ]
        then
                log_warning_msg "Mount point '$MTPT' does not exist. Skipping mount."
                        return
        fi

I checked with adding various ls -ld that the /dev/shm and /dev/pts do not exists. However they exist later. I managed to "fix" the issue by creating the missing /dev/shm and /dev/pts directories if they do not exist. Obviously the fix is ugly hack.

                if [ "/dev/shm" = "$MTPT" ]
                then
                        echo Trying to create missing /dev/shm
                        mkdir /dev/shm
                elif [ "/dev/pts" = "$MTPT" ]
                then
                        echo Trying to create missing /dev/shm
                        mkdir /dev/pts
                else

So the /dev at this point of booting must be different than the /dev that's there later? You need need to recreate the missing directories on each reboot so maybe it's initrd related?

jarkko@gandalf:~$ mount
/dev/sda5 on / type ext3 (rw,relatime,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,nosuid,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
securityfs on /sys/kernel/security type securityfs (rw)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
/dev/sda1 on /boot type ext3 (rw,relatime)
/dev/sda6 on /home type xfs (rw,relatime)
tmpfs on /lib/modules/2.6.28-11-generic/volatile type tmpfs (rw,mode=0755)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
nfsd on /proc/fs/nfsd type nfsd (rw)

if [ "/dev/shm" = "$MTPT" ]
                then
                        echo Trying to create missing /dev/shm
                        mkdir /dev/shm
                elif [ "/dev/pts" = "$MTPT" ]
                then
                        echo Trying to create missing /dev/shm
                        mkdir /dev/pts
                else
                         return
                fi

Picture of the screen displaying apparmor failure to allocate temporary file (which could be related?) and also ls -l $MTPT which verify that the /dev/shm and /dev/pts do not exist.

There's also a problem with /dev/shm permission. /dev/shm was set to "drwxr-xr-t root root", no matter how it's permission was set when created in /lib/init/mount-functions.sh

This prevented pulseaudio to use shared memory. A quick fix was to set permission manually in /etc/rc.local by issuing "chmod a+rwx /dev/shm".

This gives
jarkko@gandalf:/dev/shm$ ls -ld /dev/shm
drwxrwxrwx 2 root root 60 2009-03-31 14:44 /dev/shm
Which seem to work.

My system was originally 8.04, which was upgraded to 8.10 and then to 9.04 when it's devel version was launced. Running apt-get update & dist-upgrade quite often.

What's interesting that today after apt-get dist-upgrade (no reboot), then suspend and after resume both /dev/shm and /dev/pts were not mounted. On next reboot they we're not mounted also.
Only after adding them in /etc/fstab they're now there.

tmpfs /dev/shm tmpfs defaults,noexec,nosuid,rw,mode=0777 0 0
devpts /dev/pts devpts defaults,rw,noexec,nosuid,gid=5,mode=620 0 0

Having lines for shm and pts in fstab is not normal and supposedly not required, right?

This issue has been resolved for me. Not sure if it was one of the 15 things I did or someone fixed it in one of the updates but all is well for me again.

On Tue, 2009-03-31 at 19:51 +0000, Jarkko Lietolahti wrote:

> Only after adding them in /etc/fstab they're now there.
>
> tmpfs /dev/shm tmpfs defaults,noexec,nosuid,rw,mode=0777 0 0
> devpts /dev/pts devpts defaults,rw,noexec,nosuid,gid=5,mode=620 0 0
>
> Having lines for shm and pts in fstab is not normal and supposedly not
> required, right?
>
Correct, all of the necessary details are in the mountdevsubfs.sh
script.

Scott
--
Scott James Remnant
<email address hidden>

I also have this issue following an upgrade from Intrepid to Jaunty on 04/04/09. I've attached output of the following commands:

ls -l /dev/udev/devices
ls -l /dev
mount

Please let me know if I can provide any further information to help.

Thanks, Paul.

I would also like to request the importance of this bug is raised. Not been able to use terminals when booted into a graphical desktop is a fairly fundamental problem.

Dito that request, It affects other processes as well which fork a terminal (such as update manager)

On Sun, 2009-04-05 at 07:27 +0000, Paul Elliott wrote:

> I would also like to request the importance of this bug is raised. Not
> been able to use terminals when booted into a graphical desktop is a
> fairly fundamental problem.
>
Right now this bug is only affecting a very small number of people, and
is completely unclear what is causing it.

As I've said above, I am completely at a loss as to why this isn't
working for you - and I have run out of ideas to debug.

At this point, it's up to somebody who is affected by this bug to do the
necessary debugging and figure out what's wrong.

Raising the Importance won't do anything

Scott
--
Scott James Remnant
<email address hidden>

I've not been able to replicate on any of my test machines and the only area that I step out from the norm on my main (affected) machine is that the whole disk is encrypted. Is anyone else here with the issue using fully encrypted disks?

Not using encryption.

Is this a upgrade bug ? I think my machine has come from LTS to Jaunty with this bug appearing from Intrepid to Jaunty.

Happened to me from an upgrade as well. I also went from Intrepid to Jaunty. I'm not using any encrypted disks. Back when the problem first popped up for me I kept getting messages about only "partial upgrades" being possible.

As of the alpha builds I've been able to mount /dev/pts in fstab to work around the issue. I'm not sure that I ever had an issue with shm. This happened on my laptop which is kept pretty sparse in terms of applications (basically just a basic install with a lamp-server and virtualbox).

ghetto2ivy - Was your install previously Hardy or was it a clean Intrepid install upgraded to Jaunty?

It was indeed from hardy, to intrepid, to juanty. Hardy was my last clean install.

fwiw, my machine, which is experiencing the same issue, was installed originally with Feisty, and has been undergoing distro upgrades ever since.

I also have this problem. Forcing mount allowed me to open a terminal.
But mine was a clean install of Intrepid.
update-manager -d upgrade to Jaunty.

Managed to take a photo of the boot process today, /dev/shm and /dev/pts are certainly missing when mountdevsubfs runs as you can see from the ls -l $MTPT entries I added to the mount script. As udev doesn't start until later in the process, what script should be creating the shm/pts device? initramfs?

On Thu, 2009-04-09 at 21:02 +0000, Paul Elliott wrote:

> Managed to take a photo of the boot process today, /dev/shm and /dev/pts
> are certainly missing when mountdevsubfs runs as you can see from the ls
> -l $MTPT entries I added to the mount script. As udev doesn't start
> until later in the process, what script should be creating the shm/pts
> device? initramfs?
>
What do you mean "udev doesn't start until later" ?

S01mountkernfs.sh
 :
S10udev
S11mountdevsubfs.sh

Scott
--
Scott James Remnant
<email address hidden>

On Thu, 2009-04-09 at 21:02 +0000, Paul Elliott wrote:

> Managed to take a photo of the boot process today, /dev/shm and /dev/pts
> are certainly missing when mountdevsubfs runs as you can see from the ls
> -l $MTPT entries I added to the mount script. As udev doesn't start
> until later in the process, what script should be creating the shm/pts
> device? initramfs?
>
Could everyone affected by this bug please provide the output of:

  ls /etc/rcS.d

Scott
--
Scott James Remnant
<email address hidden>

That could be our problem. udev starts at S15udev in my install, see attached. Please ignore the apparmor entry, I disabled it for testing purposes.

...
S04mountkernfs.sh
...
S05mountdevsubfs.sh
....
S32udev
....

S05mountdevsubfs.sh says;
#! /bin/sh
### BEGIN INIT INFO
# Provides: mountdevsubfs
# Required-Start: mountkernfs
# Required-Stop:
# Should-Start: udev
# Default-Start: S
# Default-Stop:
# Short-Description: Mount special file systems under /dev.
# Description: Mount the virtual filesystems the kernel provides
# that ordinarily live under the /dev filesystem.
### END INIT INFO

And the documentation for the tags;

# Required-Start defines which facilities must be available to start and run this service. The init script system should make sure that the required facilities are started before this one.

# Should-Start is an optional field. The function is similar to Required-Start, but it does not define a hard dependency. If a service in Should-Start is not installed or enabled to start, it is silently ignored.

Correction to one of my earlier comments. My machine that is affected by this was a clean Intrepid install, upgraded to Jaunty with do-release-upgrade -d from the command line. I have a full copy of all installed/upgraded packages since first installation that may be of interest. Here's the udev entries:

/root/dpkg.log:1436:2008-12-03 15:21:44 status installed udev 124-8
/root/dpkg.log:12460:2008-12-03 15:55:45 status installed udev 124-9
/root/dpkg.log:31890:2009-04-04 22:16:02 status installed udev 140-2
/root/dpkg.log:45465:2009-04-09 16:00:50 status installed udev 141-1

I'll have a look back through the changelog to see if any of this is relevant. Scott, please let me know if I should be looking somewhere else to diagnose further. Is it the udev package itself that determines what S??udev entry it gets or is that handled by another package?

Could I ask which programs each of you used to re-order your boot sequence? This is expressly not supported, so it's little surprise that this broke things for you. The bug should be reassigned to whatever did the reordering, since it should NOT have touched rcS (and even if it should, udev should appear before mountdevsubfs)

Brian Croom and scottywz - the output you both give appears to be correct - can you give more details ?

I can't remember doing anything that's related to reordering the contents of /etc/rcS.d.

Is there a way to get it back as it should be?

What says that udev must appear before mountdevsubfs?

Programs which I've tried that have something to do with startup are; startupmanager and splashy.

I hope programs like sysrc-rc and others that are meant for configuring which services are activated on what runlevel don't mess with /etc/rcS.d.

Looking at the contents of /etc/rcS.d on my system, I can see that most of the symlinks were modified 2009-03-26 15:28. Comparing this to my dpkg log, I can see that the minute before I installed chkconfig so it looks like that might be the culprit although the only startup script that I remember changing was for puppet. I've never attempted to manipulate the rcS runlevel though, either manually or with chkconfig.

I'm going to play with chkconfig further to see if I can replicate the symlink juggling on another machine.

Certainly looks like chkconfig is the problem. I used chkconfig to turn off rsync, using:

chkconfig -e rsync

and then editing the entry to off. After doing this, all my entries in rcS.d were recreated in a new order:

lrwxrwxrwx 1 root root 19 2009-04-11 14:57 S02readahead -> ../init.d/readahead
lrwxrwxrwx 1 root root 21 2009-04-11 14:57 S03hostname.sh -> ../init.d/hostname.sh
lrwxrwxrwx 1 root root 24 2009-04-11 14:57 S04mountkernfs.sh -> ../init.d/mountkernfs.sh
lrwxrwxrwx 1 root root 14 2009-04-11 14:57 S05udev -> ../init.d/udev
lrwxrwxrwx 1 root root 26 2009-04-11 14:57 S06mountdevsubfs.sh -> ../init.d/mountdevsubfs.sh
<snip>

udev was previously S10 on my system. Now that I've found the culprit, for me at least, how can I restore the correct running order?

It seems my current order rcS.d order, after the previous chkconfig -e rsync change, is working fine now. I've attached my current, working, ls -l rcS.d

It seems that twiddling with chkconfig also made my /etc/rcS.d "better", that is udev is now before mountdevsubfs.sh.
However I didn't have chkconfig installed, I had to install it with sudo apt-get install chdkconfig

jarkko@gandalf:/etc/rcS.d$ sudo chkconfig -e rsync
insserv: warning: script 'K01gdm' missing LSB tags and overrides
insserv: warning: script 'S24linux-restricted-modules-common' missing LSB tags and overrides
insserv: warning: script 'K01asus-lightswitch' missing LSB tags and overrides
insserv: warning: script 'K01acpi-support' missing LSB tags and overrides
insserv: warning: script 'S02powernowd.early' missing LSB tags and overrides
insserv: warning: script 'gdm' missing LSB tags and overrides
insserv: warning: script 'powernowd.early' missing LSB tags and overrides
insserv: warning: script 'linux-restricted-modules-common' missing LSB tags and overrides
insserv: warning: script 'asus-lightswitch' missing LSB tags and overrides
insserv: warning: script 'acpi-support' missing LSB tags and overrides
jarkko@gandalf:/etc/rcS.d$ ls -l
yhteensä 4
-rw-r--r-- 1 root root 783 2009-03-31 12:01 README
lrwxrwxrwx 1 root root 18 2008-12-19 01:57 S02apparmor -> ../init.d/apparmor
lrwxrwxrwx 1 root root 19 2009-03-31 00:26 S02bootchart -> ../init.d/bootchart
lrwxrwxrwx 1 root root 19 2008-12-19 01:57 S02readahead -> ../init.d/readahead
lrwxrwxrwx 1 root root 21 2008-12-19 01:57 S03hostname.sh -> ../init.d/hostname.sh
lrwxrwxrwx 1 root root 24 2008-12-19 01:57 S04mountkernfs.sh -> ../init.d/mountkernfs.sh
lrwxrwxrwx 1 root root 14 2009-04-11 17:22 S05udev -> ../init.d/udev
lrwxrwxrwx 1 root root 26 2009-04-11 17:22 S06mountdevsubfs.sh -> ../init.d/mountdevsubfs.sh
lrwxrwxrwx 1 root root 16 2009-04-11 17:22 S07brltty -> ../init.d/brltty
lrwxrwxrwx 1 root root 24 2009-04-11 17:22 S07keyboard-setup -> ../init.d/keyboard-setup
lrwxrwxrwx 1 root root 21 2009-04-11 17:22 S07pcmciautils -> ../init.d/pcmciautils
lrwxrwxrwx 1 root root 16 2009-04-11 17:22 S07procps -> ../init.d/procps
lrwxrwxrwx 1 root root 22 2009-04-11 17:22 S08checkroot.sh -> ../init.d/checkroot.sh
lrwxrwxrwx 1 root root 26 2009-04-11 17:22 S09cryptdisks-early -> ../init.d/cryptdisks-early
lrwxrwxrwx 1 root root 27 2009-04-11 17:22 S09module-init-tools -> ../init.d/module-init-tools
lrwxrwxrwx 1 root root 17 2009-04-11 17:22 S09mtab.sh -> ../init.d/mtab.sh
lrwxrwxrwx 1 root root 20 2009-04-11 17:22 S11cryptdisks -> ../init.d/cryptdisks
lrwxrwxrwx 1 root root 20 2009-04-11 17:22 S12checkfs.sh -> ../init.d/checkfs.sh
lrwxrwxrwx 1 root root 21 2009-04-11 17:22 S13mountall.sh -> ../init.d/mountall.sh
lrwxrwxrwx 1 root root 31 2009-04-11 17:22 S14mountall-bootclean.sh -> ../init.d/mountall-bootclean.sh
lrwxrwxrwx 1 root root 13 2009-04-11 17:22 S14ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 26 2009-04-11 17:22 S15mountoverflowtmp -> ../init.d/mountoverflowtmp
lrwxrwxrwx 1 root root 21 2009-04-11 17:22 S15udev-finish -> ../init.d/udev-finish
lrwxrwxrwx 1 root root 20 2009-04-11 17:22 S16lm-sensors -> ../init.d/lm-sensors
lrwxrwxrwx 1 root root 27 2009-04-11 17:22 S16readahead-desktop -> ../init.d/readahead-desktop
lrwxrwxrwx 1 root root 20 2009-04-11 17:22 S16res...

From reading the man page of chkconfig and insserv I think it's the insserv which is doing the magic. So running sudo insserv might put the scripts in correct order?

jarkko@gandalf:~$ sudo insserv
insserv: warning: script 'K01gdm' missing LSB tags and overrides
insserv: warning: script 'S24linux-restricted-modules-common' missing LSB tags and overrides
insserv: warning: script 'K01asus-lightswitch' missing LSB tags and overrides
insserv: warning: script 'K01acpi-support' missing LSB tags and overrides
insserv: warning: script 'S02powernowd.early' missing LSB tags and overrides
insserv: warning: current stop runlevel(s) (0 1 6) of script `cpufrequtils' overwrites defaults (empty).
insserv: warning: current stop runlevel(s) (0 1 6) of script `apport' overwrites defaults (empty).
insserv: warning: script 'gdm' missing LSB tags and overrides
insserv: warning: current start runlevel(s) (0) of script `halt' overwrites defaults (empty).
insserv: warning: script 'powernowd.early' missing LSB tags and overrides
insserv: warning: current start runlevel(s) (0 6) of script `sendsigs' overwrites defaults (empty).
insserv: warning: current stop runlevel(s) (1 2 3 4 5) of script `nvidia-kernel' overwrites defaults (empty).
insserv: warning: current stop runlevel(s) (0 1 6) of script `dkms_autoinstaller' overwrites defaults (empty).
insserv: warning: script 'linux-restricted-modules-common' missing LSB tags and overrides
insserv: warning: current start runlevel(s) (0 6) of script `umountroot' overwrites defaults (empty).
insserv: warning: script 'asus-lightswitch' missing LSB tags and overrides
insserv: warning: script 'acpi-support' missing LSB tags and overrides
insserv: warning: current stop runlevel(s) (0 1 6) of script `ufw' overwrites defaults (empty).
insserv: warning: current start runlevel(s) (0 6) of script `umountfs' overwrites defaults (empty).
insserv: warning: current start runlevel(s) (0 6) of script `wpa-ifupdown' overwrites defaults (empty).
insserv: warning: current start runlevel(s) (6) of script `reboot' overwrites defaults (empty).
insserv: warning: current stop runlevel(s) (0 1 6) of script `tpconfig' overwrites defaults (empty).
insserv: warning: current start runlevel(s) (0 6) of script `umountnfs.sh' overwrites defaults (empty).
insserv: warning: current stop runlevel(s) (1) of script `policykit' overwrites defaults (empty).
jarkko@gandalf:~$

Feisty Desktop -> Gutsy -> Hardy -> Intrepid -> Jaunty, with almost every devel version in-between. I experienced the problem upon upgrading to Jaunty and I added
    # pts support
    devpts /dev/pts devpts rw 0 0
to my fstab to work around it. I don't remember doing anything related to startup except for a couple of custom init scripts, which shouldn't be the problem. But I do have webmin installed.

I currently see that requested information has been provided; setting to confirmed.

A comment: Could this be a race condition? There has been speedups in Jaunty's boot process, and this blueprint ( https://wiki.ubuntu.com/FoundationsTeam/Specs/BootPerformance ) talks about when to mount /dev/pts, and that udev has become multithreaded.

I confirm scottywz's workaround of adding a line to fstab. I upgraded from a clean Intrepid install to a Jaunty install on 12/4/09, done by an alternate cd and getting the latest packages from the net. I noticed this error as soon as i rebooted after the upgrade process completed. Simply mounting /dev/pts with the right options did not work. Only editing fstab and rebooting solved the issue. Should I also provide outputs of ls /etc/rcS.d or anything else?

Marking this as invalid.

The original reporter's problem, and most of the duplicates/commentors, is caused by running chkconfig/insserv which re-ordered the directory incorrectly. This is assumedly a bug in those tools for not obeying the Should-Start: udev directive in mountdevsubfs.sh

If other people have this problem and *have not* reordered the init script, they have a different bug

Is this bug tracked by another issue? Simply marking this bug as invalid will not fix the actual problem (which is /dev/shm and /dev/pts not being mounted on reboot after upgrade).

If the tools are not obeying the Should-Start: directive in mountdevsubfs.sh, why not change it to Required-Start then? This fixes the problem.

#! /bin/sh
### BEGIN INIT INFO
# Provides: mountdevsubfs
# Required-Start: mountkernfs udev

This seems to much simpler fix than fixing the insserv and doens't require revert later when it's actually fixed.

Or if udev package required fix is required there's the keyword X-Start-Before (if it's honored) which could placed in /etc/init.d/udev to make it start before mountdevsubfs.

A quick test shows that X-Start-Before seems to work. For testing I removed any udev dependencies from mountdevsubfs and added "X-Start-Before:mountdevsubfs" to /etc/init.d/udev, removed /etc/rcS.d/S05udev.sh and ran "chkconfig udev S" and /etc/rcS.d/S05udev appeared.

#!/bin/sh -e
### BEGIN INIT INFO
# Provides: udev
# Required-Start: mountkernfs
# Required-Stop:
# Should-Start:
# X-Start-Before: mountdevsubfs
# Default-Start: S
# Default-Stop:
# Short-Description: Start the udev daemon.
# Description: Mounts the /dev virtual filesystem, starts the udev
# daemon and populates /dev.
### END INIT INFO

For double safety/complexity one could change udev to Required-Start: in /etc/init.d/mountdevsubfs.sh and also add the "X-Start-Before: mountdevsubfs" in /etc/init.d/udev.

On Tue, 2009-04-14 at 10:03 +0000, Jarkko Lietolahti wrote:

> Is this bug tracked by another issue? Simply marking this bug as invalid
> will not fix the actual problem (which is /dev/shm and /dev/pts not
> being mounted on reboot after upgrade).
>
> If the tools are not obeying the Should-Start: directive in
> mountdevsubfs.sh, why not change it to Required-Start then? This fixes
> the problem.
>
Because then the initscripts package would have to Depend on udev.

LSB specifies that Should-Start includes an ordering requirement, but
only if udev is present.

insserv is broken - note that it's never been tested on Ubuntu and is
generally not supported, even the package description notes that it can
cause problems.

Scott
--
Scott James Remnant
<email address hidden>

"insserv is broken - note that it's never been tested on Ubuntu and is
generally not supported, even the package description notes that it can
cause problems."

Ah, OK. Actually i didn't have it installed at all. Only installed it sometimes during testing try to get issue sorted out.

Is there an ubuntu supported tool for making the order in /etc/rcS.d or is it supposed to kept in sync manually?

Or rather, how do I make sure that my /etc/rcS.d is per ubuntu standards?

On Tue, 2009-04-14 at 10:30 +0000, Jarkko Lietolahti wrote:

> "insserv is broken - note that it's never been tested on Ubuntu and is
> generally not supported, even the package description notes that it can
> cause problems."
>
> Ah, OK. Actually i didn't have it installed at all. Only installed it
> sometimes during testing try to get issue sorted out.
>
> Is there an ubuntu supported tool for making the order in /etc/rcS.d or
> is it supposed to kept in sync manually?
>
> Or rather, how do I make sure that my /etc/rcS.d is per ubuntu
> standards?
>
We don't support any tools to reorder /etc/rcS.d - the order was
hand-written as part of our boot work.

I'm not sure of any automated way to restore the default, you may simply
have to compare with a default-installed system

Scott
--
Scott James Remnant
<email address hidden>

> The original reporter's problem, and most of the duplicates/commentors,
> is caused by running chkconfig/insserv which re-ordered the directory
> incorrectly. This is assumedly a bug in those tools for not obeying the
> Should-Start: udev directive in mountdevsubfs.sh
>
> If other people have this problem and *have not* reordered the init
> script, they have a different bug

I have not used either chkconfig or insserv to re-order the rcS.d
directory, nor did I play it manually. So in that case, bug 360160
which I reported is not a duplicate of this bug, and should not be
marked invalid.

I am new here, so might need a little help. :)

Putting udev before mountdevsubfs.sh fixed this bug for me, too!
I reordered the links manually by looking at the .postinst files of the packages containing those init scripts.
I confirm that I have had insserv installed around the time the bug appeared and that probably broke the order.

But please could a check be added to udev.postinst to ensure udev is started before mountdevsubfs and solve the bug for other users who likewise have broken their systems?

Same problem with 9.04 RC after upgrading from 8.10. Thanks for the workarounds...

I ended up changing the boot order of the services like this:
cd /etc/rcS.d
sudo mv S03mountdevsubfs.sh S11mountdevsubfs.sh

Same problem - going from 8.10 -> 9.04.

Yes, 8.10 -> 9.04 did this to me as well. IMHO this should have a MUCH higher importance then "Low".

As a workaround, I'm manually mounting /dev/pts until an official fix is released.

Thirded. I went from 8.10 ->9.04; didn't even have chkconfig installed, nor had I messed with the ordering of services.

I'm manually mounting this dir in fstab, and it's sped up logon, and starting applications (Firefox, Thunderbird) as well; so I think this missing mount is affecting many things, which should (I think) raise its priority.

Ok, I just found out that my /etc/init.d/mountdevsubfs.sh does NOT have
        # Should-Start: udev
at the beginning. This is probably what screwed it up for me. I'll do some fiddling around and report back.

Ok, adding the Should-Start: udev line did not help. But I discovered that mountdevsubfs.sh is calling a program called "domount" which is not on my computer.

Line 32: domount tmpfs shmfs /dev/shm $SHM_OPT
Line 37: domount devpts "" /dev/pts -ogid=$TTYGRP,mode=$TTYMODE

Surely this should be replaced with something else?

scottywz's workaround was successful. As per bug 360160, I replaced the mountdevusbfs.sh with the package maintainers version, and it solved the problem for me.

After seeing the above comments, I checked my incorrectly functioning mountdevusbfs.sh script which I had backed up, and I confirm that the Should-Start did not have udev in it.

Also, a diff of the 2 files shows that the earlier script had mountvirtfs in the Provides line, which is not there in the newer script. The diff has been attached to bug 360160. Kindly refer to that for further details.

@scottywz

Just saw your second comment. domount is a shell function and has been included from the /lib/init/mount-functions.sh script on line 28. Please see if the fix at bug 360160 helps you, which is due to a modified mountdevusbfs.sh script. In case it works, we might have found out where things are going wrong.

Thanks very much; that was the problem!

I had also modified mountdevsubfs.sh to get VirtualBox working, and dpkg wasn't updating it. Replacing it with mountdevsubfs.sh.dpkg-dist worked, and it also seems that the VirtualBox workaround isn't needed anymore. Thanks again.

PEOPLE!!

For Debian 9.04 jaunty Desktop Edition, upgraded from 8.10: chkconfig mountdevsubfs.sh 1 (need to start on level 1, 2, 3 and so one).

You don't need to change files or something about it.

I have several medical instruments running with 8.10. Today Wed Apr 29 I upgraded one of the test systems to 9.04 (with a history of 7.xx, 8.04, 8.10 and today 9.04 using "Update Manager" and I immediately found the same problem attempting to launch Gnome Terminal. I have attached the output of ls -l /etc/rcS.d/ > rcS.d and note that S10-udev is indeed before S11mountdevsubfs.sh.

I applied the none /dev/pts devpts gid=5,mode=620 0 0 line to fstab, mounted /dev/pts and the termina sessions now work.

Has anyone see this on a clean new Jaunty install?

I upgraded from 8.10 to 9.04 and had this problem ("There was an error creating the child process for this terminal" when starting terminal in GNOME). Fix 1 solved this for me (`sudo mv /etc/rcS.d/S03mountdevsubfs.sh /etc/rcS.d/S11mountdevsubfs.sh`).

Please let me know if I can provide any further helpful information.

I'm surprised this bug is marked low priority...

How do I fix the sound? I updated from 8.10 to 9.04 and suffered with the /dev/pts issue but still have a problem with sound.

$ grep pulseaudio /var/log/messages
May 1 22:26:57 illya pulseaudio[3464]: core.c: failed to allocate shared memory pool. Falling back to a normal memory pool.

I saw in this or a duplicate of this bug that shm wasn't loaded. It's there and loaded.

$ ls -ld /dev/shm
drwxrwxrwx 2 root root 40 2009-05-01 23:10 /dev/shm

$ mount | grep shm
tmpfs on /dev/shm type tmpfs (rw,noexec,nosuid,mode=0777)

What gives?

Would a clean install of 9.04 fix this or should I go back to 8.10 until 9.xx has passed beta testing?

Did you try the fixes listed in the bug's description?

The fixes let Gnome terminal work but sound doesnt.

I have now done a clean 9.04 install and everthing is working.

I am having the same issue on a clean install of 9.04. It occured after updating my packages. During the update I had a kernel panic and on rebooting my mouse refused to work. I then tried to reinstall my kernel through aptitude and that was when I got to know the /dev/pts and /dev/shm were not being mounted.

I do have the same problems. The differents is that I'm working with 4 different systems. I've upgraded a Medion E1210 UMPC and a no name desktop from Ubuntu 8.10 with the standard upgrade procedure. No problem with all of them. A third system with a new installation, also everything works fine, My fourth system is a Laptop from Fujitsu Siemens, this system reports the same problem. I receive this error during installation of updates and during new installation of software. ( e.g. Amarok etc.) Does anybody has a solution or does somebody need logs and traces to resolve this issue??

To mobileuser:
Does mountdevsubfs.sh starts during booting OS?

If it's not,
#chkconfig mountdevsubfs.sh 1

in recovery mode

I have the same problem after upgrade to 9.04 today.

Ubuntu 8.10
Google Chrome fails to load/show web pages.

I ran with "chrome --debug_code --log_code" and saw a SLEW of error messages about accessing /dev/shm

I googled, found this thread.

I added lines to /etc/fstab
I ran "sh /etc/init.d/S03mountwhateveritis.sh start" -- no mounted /dev/pts or /dev/shm
So, I manually mounted /dev/shm -- works

Now google chrome shows web pages.

*sigh*

-- joe

Hello,

It is possible that your file /ect/group to be corrupt. I posted the report on resolution 313947 : https://bugs.launchpad.net/bugs/313947

FWIW, I just hit this problem after upgrading to 10.04 from 8.04. System won't boot, I'm left attempting all sorts of repairs from the rescue shell, none of which seem to work ... Arghhh.