Bugzilla Bug 67051

Running udev 0.34-r1, with RC_TARBALL=yes (not that I think it matters) and
didn't delete anything from /dev while migrating from devfs. Emerge updated
tar, which nukes the udev boot script which in turn prevents the system from
booting. The errors (could not capture since coulndn't even get a shell) were
similar to:

udev:
Populating /dev with nodes...

tar: No such device /dev/vcs30
tar: No such device /dev/vcs31
...

and it ended with no such device /dev/shm which is apparently a terrible thing
and the system boot halts. Pressing CTRL+D reboots the system, only to have the
same thing happen over and over.

Rolling tar back to 1.14 from a liveCD chroot solved the problem.

Reproducible: Always
Steps to Reproduce:
1. Emerge tar 1.14.90 with udev system
2. Reboot

Actual Results:  
Can't reboot, process stuck at udev init script, which claims critical error
and
prevents boot.

Expected Results:  
Reboots.

Portage 2.0.51_rc8 (default-x86-2004.2, gcc-3.3.4, glibc-2.3.4.20040808-r1,
2.6.8-gentoo-r7 i686)
=================================================================
System uname: 2.6.8-gentoo-r7 i686 Intel(R) Pentium(R) M processor 2.00GHz
Gentoo Base System version 1.5.3
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.15.92.0.2
Headers:  sys-kernel/linux26-headers-2.6.8.1-r1
Libtools: sys-devel/libtool-1.5.2-r5
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer -mfpmath=sse -mmmx
-msse2"
CHOST="i686-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/control"CONFIG_PROTECT_MASK="/etc/gconf
/etc/terminfo /etc/env.d"
CXXFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer -mfpmath=sse -mmmx
-msse2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache distlocks sandbox"
GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/
http://gentoo.mirrors.pair.com/ http://gentoo.osuosl.org/
http://ftp-mirror.internap.com/pub/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acpi alsa apm avi berkdb bitmap-fonts cdr crypt cups dvd dvdr eds encode
esd f77 fam flac foomaticdb gdbm gif gnome gpm gtk gtk2 hal imap imlib java
jpeg
ldap libg++ libwww mad mikmod mmx motif mozilla mpeg ncurses nls nntp nptl
oggvorbis opengl oss pam pdflib perl png python quicktime readline samba sdl
slang spell sse ssl svga tcltk tcpd tetex truetype x86 xine xml2 xmms xprint xv
zlib"

I can confirm this bug. However, I was able to login in maintenance mode and
rollback app-arch/tar by doing:
1. echo "=app-arch/tar-1.14.90" >> /etc/portage/package.mask
2. emerge tar
3. reboot

Does only this happen if you have RC_DEVICE_TARBALL="yesy" in your
/etc/conf.d/rc ? Hmmm...will try this when I get home.

*** Bug 67165 has been marked as a duplicate of this bug. ***

It doesn't happen if RC_DEVICE_TARBALL="no". It also happens if you try to
untar the device nodes manually.

although a lot of errors are shown, the nodes are created correctly ... the
owners are just not restored correctly

the reason it halts the boot process is that tar will exit with a status value
of '2' instead of the normal '0'

ive sent this upstream

confirming this bug, however it's not only about devices form devfsd, which are
not present in udev. i had this errors with /dev/video* created manually with
bttv's MAKEDEV script and (sic!) with lvm2's partitions (in fact i've lost few
hours to locate and solve the problem, couse the whole portage tree is on
lvm2's partition and i hadn't access to that;/)

*** Bug 67248 has been marked as a duplicate of this bug. ***

*** Bug 67206 has been marked as a duplicate of this bug. ***

the same here but downgrading to tar 1.14 doesn't help :-(

Downgrading to 1.14 worked for me.

you guys are all running x86 right ?

Affirmative on the x86.

actually, this looks like a sandbox problem with latest portage

env FEATURES=-sandbox emerge tar

actually, this looks like sandbox is broken with 2.0.50 and 2.0.51 ... so
nothing new :)

basically the chown() in sandbox isnt behaving exactly as the chown() in the
real system

here's the strace info:

normal:
getuid32()                              = 0
chown32("conftest.dangle", 0, 0)        = -1 ENOENT (No such file or directory)
exit_group(0)                           = ?

sandbox:
getuid32()                              = 0
getcwd("/root", 8192)                   = 6
lstat64("/root", {st_mode=S_IFDIR|0700, st_size=12288, ...}) = 0
lchown32("conftest.dangle", 0, 0)       = 0
exit_group(1)                           = ?

ok, i added a workaround to the ebuild so this bug shouldnt affect that package
anymore

also, this bug only seems to affect those running x86 and ppc ...

removing people since they care about tar, and not glibc/sandbox :)

Created an attachment (id=41688) [edit]
test-sandbox.c

ok, perhaps this isnt sandbox, but glibc ?

find attached a small test file that screws up outside of sandbox ...

lv: take a look at this when you have a minute ?

seems like on x86 boxes, dlsym("chown") doesnt work properly ... i was able to verify this bug in glibc-2.3.3.20040420-r1, 2.3.4.20040808, 2.3.4.20041006 ...

on a bad system strace shows something like this (my broken x86):
lchown32("blah", 0, 0)                  = -1 ENOENT (No such file or directory)
chown32("blah", 0, 0)                   = -1 ENOENT (No such file or directory) 

on a good system strace shows something like this (tested on amd64/s390):
chown("blah", 0, 0)                     = -1 ENOENT (No such file or directory)
chown("blah", 0, 0)                     = -1 ENOENT (No such file or directory)

Hi all, i had this problem just now.

i did upgrade to latest glibc and several other packages (including tar) couple of days ago, today i rebooted and had this problem.

so i downgraded glibc to 2.3.4.20040808, but problem remained

then i thought it could be tar with glibc since strace on the tar command that is executed in the udev script was screwing up with permissions, so the only thing i did was to re-emerge tar so it's compiled with the current glibc, and now everything is back to normal

lv@ayanami lv $ gcc test-sandbox.c -o test-sandbox -ldl ; strace ./test-sandbox
2>&1 | grep ^chown
chown("blah", 0, 0)                     = -1 ENOENT (No such file or directory)
chown("blah", 0, 0)                     = -1 ENOENT (No such file or directory)
lv@ayanami lv $ uname -m
x86_64
lv@ayanami lv $ /lib/libc.so.6 | grep ^GNU
GNU C Library 20041006 release version 2.3.4, by Roland McGrath et al.

dont really know what you wanted, but there...

I can confirm that a rebuild of tar with the new gcc worked for me

I found that it seems to be tar who's evil here. It makes a check on the newly
created files and tries to open them for reading and writing. In this situation
the kernel checks if the device exists and fails in all other cases. This leads
to the tar error "cannot change ownership" - although changing the ownership
works perfectly, just opening the device file is failing.

it may be an error in the new tar implementation. It should not try to open
device nodes at all, creating them, chmoding them and chowning them, setting
the timestamp and maybe stat'ing it should be enough.

i solved the problem by replacing tar in my /sbin/rc by cpio (and bunzip2).

re-emerge tar and your problem will be fixed

it's not a bug in tar at all

I could have sworn that I *did* re-emerge tar and still had the problem.  I'll
try again and report back.

*** Bug 67582 has been marked as a duplicate of this bug. ***

What's the status of this? Spanky?

sorry, not a portage bug, but a glibc bug

Fixed in CVS.

Note, the fix was to do a dlvsym("chown", "GLIBC_2.1") instead of a
dlsym("chown") to get the symbol ...