lol, modern mkfifo (coreutils->=2021) freezes with old Linux kernel v<=4.*

[DiTBho]

So, emerge is based on Python, but it also uses a lot of coreutils utilities.
One of them is mkfifo, and ...

... with the new stage4 I made on Catalyst (2023/12/20), it freezes with old Linux kernel v<=4.*
whereas it perfectly works with kernel v6.*!

Moral of the story, you can no more mix new rootfs with old kernels
You need to update both kernel and rootfs

(that's a serious problem for all the kernel drivers (e.g. PCI-canbus-HBA, PCI-optical-fiber-HBA, etc...) that cannot be easily ported from v4 to { v5, v6, ... })

[DiTBho]

posix fifo freezes when opened in blocking mode, see here

[DavidAlfa]

Ahh this is the stuff I love about linux. So many good things... but so messy after 1-2 years and lots of things got deprecated/changed/updated.
After so many years, I finally understood why vendors providing the firmware sources still used ubuntu 14!
Everything has to be reworked every year if you want to keep it updated... endless work!
Here the "Don't touch if not broken" rule applies heavily, so "I will update because newer means better and..." DON'T if working!

[magic]

Code: [Select]

$ uname -r
3.10.18
$ pwd
/dev/shm/coreutils-9.4
$ time strace ./src/mkfifo test 2>&1 |tail -n 6
close(3)                                = 0
mknod("test", S_IFIFO|0666)             = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++

real    0m0.021s
user    0m0.000s
sys     0m0.000s
 

[DiTBho]

It seems there was a bug report in 2020: has *IT* come back? Who knows ...
It seems mkfifo hangs when using -m 600 (as invoked by emerge), otherwise it works OK.

Perplexed ... 

[magic]

600 also works for me.

Besides, coreutils mkfifo doesn't open the fifo, it only creates it and immediately terminates as indicated by strace.

edit
Actually, it opens the fifo if -m is passed, in the subsequent call to lib/lchmod.c:lchmod()

Code: [Select]

mknod("test", S_IFIFO|0600)             = 0
open("test", O_RDONLY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC|O_PATH) = 3
readlinkat(3, "", 0xbee9b83c, 1)        = -1 ENOENT (No such file or directory)
close(3)                                = 0
readlink("test", 0xbee9b83c, 1)         = -1 EINVAL (Invalid argument)
chmod("test", 0600)                     = 0
close(1)                                = 0
close(2)                                = 0
exit_group(0)                           = ?
+++ exited with 0 +++But it works...


This call hanging despite O_PATH could be a kernel bug perhaps. Not sure why it's OK on my system, maybe it's specific to some 4.x release or maybe my ARM vendor backported fixes to this old 3.x branch... (this is not a vanilla kernel I'm testing with)

[DiTBho]

Also gpg (so, everything related to --sync, --update, ... manifest) now crashes with the hostname "tigra-mips32/be"

It seems it really hates the "/" char (1)
changed it into "tigra-mips32-be", and it's back working again 

... ah, computer science ...


(1) not manually done, not my choice, it got "injected" by the automator due to the profile names

• mips32/be
• mips32/le
• ...