/dev/.static/dev is mounted ro in intrepid

I wonder whether that's a kernel change?

It's a bind mount of the root filesystem, and previously that bind mount just had whatever permissions the underlying root filesystem had.

Of course, I know that the kernel recently gained support for bind mounts being mounted differently - I wonder whether that means the new mount doesn't inherit in the same way it did before.

  mount root ro
  bind /dev to /dev/.static/dev
  mount root rw

Arguably we should just get rid of /dev/.static/dev anyway, since we utterly don't support a static /dev -- it'd mean that postinsts just succeeded.

This issue is apparently fixed in Debian.

They've removed /dev/.static/dev entirely, which is somewhat the direction I was thinking of taking as well. Jumping through hoops just to support systems that don't have udev installed isn't worth the effort, udev is part of our required set of packages.

I'll probably do likewise for 9.04

I was looking into this because it triggered bug 278954.

initramfs bind-mounts /dev to /dev/.static/dev before the init scripts remount / read-write.

I've been working around the XFS bug with a line in fstab:
/dev /dev/.static/dev bind remount,rw 0 0

 This has the side-effect of making /dev/.static/dev writeable again, also enabling things that want to run MAKEDEV to work successfully. Some packages do want to run MAKEDEV in their postinst, IIRC, and fail because of that.

 So if you get rid of /dev/.static/dev, you need to change MAKEDEV so it always returns true, or change all the packages, or something. Or just have the /etc/rcS.d/S20checkroot.sh make the bind mount read-write, just after remounting the root fs.
mount -n /dev /dev/.static/dev -o remount,rw
(-n because my fstab workaround puts it in mtab, but that's not the default.)

 I think (the real, on root fs) /dev would be needed by people who build their own non-initramfs not-so-modular kernel. You need a /dev/null until /etc/rcS.d/S10udev, probably.
I don't know if that's still supported, either. I used to do that, before I had too many different machines to customize kernels for (and plenty of RAM in most of them :). Oh, the good old days of worrying about kB used by the kernel.

Appears to have triggered bug #296477 and bug #295510.

tim@thinkpad:~$ grep static /proc/mounts
/dev/disk/by-uuid/7b58a11b-972a-4a67-909a-b8e48cb29da5 /dev/.static/dev ext3 ro,errors=remount-ro,data=ordered 0 0
/dev/disk/by-uuid/7b58a11b-972a-4a67-909a-b8e48cb29da5 /var/chroot/hardy/dev/.static/dev ext3 ro,errors=remount-ro,data=ordered 0 0

hth

btw, sorry for the unnecessary attachments, but launchpad seems to be broken, when not uploading an attachment

Just a note that "/etc/init.d/udev restart" does not fix this problem; only stopping and starting the service removes the read-only problem.

kernel 2.6.27-8 and udev 124-11 didn't fix this problem

i dont see a seperate bug for when mythtv-backend fails while setting up devices
http://pastebin.com/m4e2553f9

stopping and starting udev then a dpkg-reconfigure mythtv-backend prompted me about created the devices which succeeded this time around. I imagine this will revert after a reboot and fail with the next install that needs to create devices

This bug was fixed in the package udev - 136-1

---------------
udev (136-1) jaunty; urgency=low

  One of the biggest changes in this release is that the default rules
  are no longer conffiles and are now installed into /lib/udev/rules.d

  You may still add your custom rules to /etc/udev/rules.d and these
  will be processed after the default ones, and can thus override
  anything they do.

  To avoid side-effects of default rules (ie. running of programs),
  create the file with the same name.

  * New upstream release:
    - Changed to use autoconf
    - Default rules moved to /lib/udev/rules.d
    - udevadm symlinks removed.
    - udevadm info output for --device-id-of-file changed.
    - udevadm trigger has new --type option.
    - libvolume_id soname change.
    - libvolume_id now able to return multiple matches for a single block
      device, or no matches if conflicting metadata found.
    - libudev shared library introduced.
    - by-id/scsi-* and by-id/ieee-* links both created by Firewire disks.
    - Optical devices no longer probed for raid signatures. (LP: #283316).
    - DEVTYPE=disk/partition no longer exported by default.
    - pnp support removed now that we have MODALIAS support in kernel.
    - Introduced /dev/block and /dev/char (see changelog for 124-6).
    - Rule matching engine changed, limits such as 5 ENV and ATTR matches
      and only one match for any other key are now gone. NAME assignment
      is no longer special cased (subsequent assignments will now overwrite
      unless := is used).
    - Substantial memory footprint reduction work.

  * debian/patches/01-cdrom-vol_id-probing.patch:
    - Dropped, included in upstream release.
  * debian/patches/80-extras-dvb_device_name.patch:
    - Dropped, no longer compiles and won't be needed from the next kernel
      onwards. Since these aren't boot critical, just do it in shell.
  * debian/patches/80-extras-firmware.patch:
    - Dropped, no longer compiles anyway so we may as well just use the
      upstream firmware.sh which also supports crazy PackageKit stuff
  * debian/patches/80-extras-ide_media.patch:
    - Dropped, the ide subsystem has had MODALIAS support since hardy using
      the media type.
  * debian/patches/80-extras-usb_device_name.patch:
    - Dropped, we no longer need to support the legacy usb_device subsystem
      since we've had the newer ENVTYPE=usb_device objects since hardy.
    - Bump minimum kernel version to 2.6.24 for the initramfs.
  * debian/patches/80-extras-vio_type.patch:
    - Dropped, we don't even build these modules.
  * debian/patches/80-extras-watershed.patch:
    - Dropped, we do not used it in any udev rules shipped in this package;
      it can be separated out into another source package if other things
      still use it (which we should try to make them not).

  * Merged our rules with Upstream default rules, this results in a number
    of minor changes but achieves consistency with other distributions:
    * /dev/net/tun is now mode 666, the kernel documentation says this is safe
      since you still need CAP_NET_ADMIN to create tunnels.
    * /dev/srN are now the definitive names of SCSI CD-ROM devices, with
...

Will this be fixed for Intrepid too?

I don't know if it means that it would become available in the proposed updates for intrepid or not. I don't enable that repo. Also, I think we all got notified that a guy testing the new udev in jaunty still has this problem with libsensors. Since I have 3 machines with this issue I have implemented what i think Peter Cordes was hinting at by modifying /etc/init.d/checkroot.sh for the time being:

after:
 #
 # Remove /lib/init/rw/rootdev if we created it.
 #
 rm -f /lib/init/rw/rootdev

added:
 echo "UDEV /dev/.static/dev REMOUNT RW HACK"
 mount -o remount,rw /dev /dev/.static/dev

after reboot:
$ cat /proc/mounts |grep /dev
udev /dev tmpfs rw,mode=755 0 0
/dev/disk/by-uuid/8a22bb23-7295-4efc-9d0a-a0b6c25dba27 / ext3 rw,relatime,errors=remount-ro,data=ordered 0 0
/dev/disk/by-uuid/8a22bb23-7295-4efc-9d0a-a0b6c25dba27 /dev/.static/dev ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0

hopefully this is sane and sets aside the symptom long enough for things to get sorted out the way they should be

hi folks,

After upgrading to 8.10 my mythtv setup stopped working. running "sudo dpkg-reconfure mythtv-backend" I notice lots of these errors:
udev active, devices will be created in /dev/.static/dev/
rm: cannot remove `video0-': Read-only file system
mknod: `video0-': Read-only file system
makedev video0 c 81 0 root video 0660: failed
rm: cannot remove `video0-': Read-only file system

After googling for a while, I found other packages suffering the same problem:
lm-sensors: #289372
mdadm: #270043
#496287
dvb-utils:#292974
xawtv:#283007
I don 't find a way to report properly that all these depend on this bug. Can someone help me you ?

I just installed dvb-utils in intrepid, and the bug is still present.

I have just tried to install dvb-utils in Intrepid and this bug is still present.

Is there a workaround for this?