mkdir doesnt do anything

[nobody13]

Im installing gentoo on an old computer for a dvr and suddenly i cant create new directories. I can create files though. The hard mounted rw.

mtab :
/dev/sdb2 / ext4 rw,noatime,data=ordered 0 0

fstab :
UUID=f6d0e5ee-73e9-4611-a7c9-1101e9a75e9a /boot ext2 noatime 1 2
UUID=0cf488fb-9ff5-4548-97da-7595e7aa2310 / ext4 noatime 0 1

and emerge fails for the same reason : (and sadly i don't have revdep-rebuild installed yet)

[nobody13]

update :
TO see if it is the drive or not i rebooted with the gentoo disk. I can mkdir /mnt/gentoo/home/dave/aaa - and it works. Once i chroot in - it fails (doesnt give an error ,just doesnt write anything)

[khayyam]

nobody13 ...

please provide the output of 'emerge --info', 'env', and (if you have strace) 'strace mkdir /tmp/test'.

best ... khay

[nobody13]

spB610 dave # strace mkdir /tmp/test
bash: strace: command not found

[cboldt]

emerge will throw that error if /var/tmp doesn't exist, too. It makes /var/tmp/portage (or $PORTAGE_TMPDIR/portage), but depends on $PORTAGE_TMPDIR existing in the first place.

[nobody13]

var/tmp does exist

drwxrwxrwt 3 root root 4096 Mar 21 16:08 tmp

[cboldt]

var/tmp and /var/tmp aren't necessarily the same thing. I'll take your word for it that /var/tmp exists in whatever environment your "mkdir doesn't work" occurs. I'd be looking at free space there, and any mount details that apply to /var/tmp, before I'd check the mkdir program. Especially on a report that the program works when applied to different locations.

[nobody13]

I manually downloaded the revdep-rebuild script and ran it. It doesn't show anything broken

[nobody13]

[cboldt]

Are those the values you get from your chroot environment?

And what does `df` show?

[nobody13]

no i rebooted back to normal env when chroot didnt help. i posted df above

[cboldt]

You don't have to reboot to get out of chroot, just `exit`.

My impression is that mkdir works fine when you are not in chroot. You made /mnt/gentoo/home/dave/aaa

Further, my impression is that mkdir doesn't work "sometimes," and I'm trying to get a handle on what those "sometimes" are.

You seem to have plenty of room on /dev/sdb2; but I do not assume that /mnt/gentoo exists on that device. /mnt/gentoo is a creation (usually) of sysrescuecd.

[nobody13]

It seems to not work at all unless i boot from external media. i used the gentoo minimal disk to start up (and from there mkdir functioned normally) then chrooted into my normal enviroment hoping that i could run revdep -rebuild from there and install missing files. It didnt work so rebooted

[limn]

[John R. Graham]

[nobody13]

I don't have strace.

here's the other :
spB610 dave # mkdir /tmp/test
spB610 dave # ls /tmp
spB610 dave # ls /tmp/test
ls: cannot access '/tmp/test': No such file or directory
spB610 dave #

it was the same when I chrooted into this env. It doesn't give an error. It acts like it's working. It just doesn't do anything. I can copy and create files, just not directories.

[nobody13]

heres my last activity before things went south. I installed sddm and started x. my keyboard and mouse didnt work in x so i installed a couple of usb packages then it quit working.

[cboldt]

When you "reboot," what do you "reboot" from? /dev/sdb1, mounted at /boot off off (root filesystem) /dev/sdb2?

Just want to clarify the environment that has the trouble. There may be some setting (permissions) on /tmp that preclude creation of directories. And you say you can create a file in /tmp, but I don't recall reading an experiment that proved this.

Also, the UID of the user doing this "failed mkdir" may be pertinent. Are you running the mkdir command as root, or as some other user?

For us to see what is going on, either `ls -a -l /tmp`, or `stat /tmp` is much better than plain `ls`

I do agree, absence of failure report from mkdir is weird at best. mkdir here reports a variety of errors.

[cboldt]

I think your emerge activity is unrelated. You may be having a hardware failure, and your /bin/mkdir is a casualty. Or somebody has intruded and substituted a mkdir.

My system has the following details ...

[nobody13]

Grub is installed on sda.

fdisk -l :

[nobody13]

[cboldt]

From your mtab (the command `mount` would give similar but more info), /dev/sdb2 is what one would expect. It holds /tmp, /bin (and other directories, including a mount point /boot to attach /dev/sdb1).

Further, /dev/sdb2 is mounted read-write (rw), so that setting isn't the cause of trouble.

In addition to my previous (examining /bin/mkdir), the thread includes a suggestion to show what is actually running when you command `mkdir` ... what does `which mkdir` show? (or bash built-in equivalents, `command -v mkdir` and `hash -l`)

[cboldt]

Yeah, well, a zero byte file there explains something. It doesn't though, explain how that file came to be zero bytes, and you need to be be concerned that there is another file by that name that is running. Not saying there is, just prove it one way or the other.

[John R. Graham]

Interesting experimental results here:

[nobody13]

I hope its not some hacker's dirty trick but i'm leaning more to some kind of corruption from failing hardware. It was running unstable do to overheating a couple days ago but i thought i had that worked out. Now i have to figure out a way to reinstall mkdir with out re-emerging because emerge cant make temporary work directories.