A wierd thing, can not rm files even as root

I built openwrt failed with nftables, and the libraries has built. But when I run make pakcage/nftables/clean, the process can not rm these libraries, even I sudo rm or su to root and rm them.

And failed to chattr:

This looks indeed a bit weird. Some thoughts / questions:

  • Which operating system is this? Version?
  • Running in a VM or native?
  • Which filesystem is used?
  • Available free space?

I think @robertwenhk is trying to cross-compile OpenWrt on an Ubuntu machine, the problem isn't with OpenWrt iself.

1 Like

Things I would try in this order:

  • Ensure you own the files

    chown -R quanwen ~/work/code/tcu/openwrt-22.03
    
  • Remove all build outputs

    cd ~/work/code/tcu/openwrt-22.03
    make clean
    
  • Delete entire folder using Ubuntu's graphical file explorer

1 Like

I know (I'm not sure about Ubuntu), that's why I asked these questions.

maybe the underlying file system has errors and that's why you can't delete the files, check dmesg or journalctl -r as root user

A random stab in the dark: are you trying to build with the filesystem mounted over sshfs ? don't do that if you are. If you really have to, you're probably going to have to make a filesystem within a file and loop mount it

one way to do it:

qemu-img create -f raw openwrt-dev.btrfs 10G
mkfs.btrfs -f -m single -O no-holes openwrt-dev.btrfs
mkdir openwrt-dev

(as root ?)
mount -t btrfs -o loop openwrt-dev.btrfs openwrt-dev
cd  openwrt-dev
git clone https://git.openwrt.org/openwrt/openwrt.git
chown -R quanwen openwrt
su quanwen                            (or exit back to original user)
cd openwrt-dev/openwrt

etc, though I don't think this will work if this is running in a container

I have tried this way, but it still doesn't work. And I am sure these files belong to the current user.

I am cross-compiling openwrt on ubuntu 20.04. And it is a native machine, instead of a VM. The filesystem I am using is ext4 and there are 800G+ free space.

I cloned the repository in another directory on the same disk and recompiled it, but I didn't encounter the same problem.

I only cross-compiled the firmware on my host, and here is the related kernel journal:

3月 11 17:02:28 jd-dl-054.autox.sz sudo[1975974]: pam_unix(sudo:session): session opened for user root by (uid=0)
3月 11 17:02:28 jd-dl-054.autox.sz kernel: audit: type=1400 audit(1710147748.289:31271): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/etc/selinux/semanage.conf" pid=1975980 comm="selinux_child" requested_mask="r" denied_mask="r" fsuid=0 o>
3月 11 17:02:28 jd-dl-054.autox.sz sudo[1975974]:  quanwen : TTY=pts/1 ; PWD=/home/quanwen/work/code/tcu/openwrt-22.03 ; USER=root ; COMMAND=/usr/bin/journalctl -r
3月 11 17:02:28 jd-dl-054.autox.sz audit[1975980]: AVC apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/etc/selinux/semanage.conf" pid=1975980 comm="selinux_child" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
3月 11 17:02:28 jd-dl-054.autox.sz kernel: audit: type=1400 audit(1710147748.249:31270): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/1975974/cmdline" pid=1894 comm="sssd_pam" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
3月 11 17:02:28 jd-dl-054.autox.sz kernel: audit: type=1400 audit(1710147748.249:31269): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/1975974/cmdline" pid=1893 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
3月 11 17:02:28 jd-dl-054.autox.sz kernel: audit: type=1400 audit(1710147748.249:31268): apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/1975974/cmdline" pid=1896 comm="sssd_sudo" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
3月 11 17:02:28 jd-dl-054.autox.sz kernel: kauditd_printk_skb: 6 callbacks suppressed
3月 11 17:02:28 jd-dl-054.autox.sz audit[1894]: AVC apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/1975974/cmdline" pid=1894 comm="sssd_pam" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
3月 11 17:02:28 jd-dl-054.autox.sz audit[1893]: AVC apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/1975974/cmdline" pid=1893 comm="sssd_nss" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
3月 11 17:02:28 jd-dl-054.autox.sz audit[1896]: AVC apparmor="ALLOWED" operation="open" profile="/usr/sbin/sssd" name="/proc/1975974/cmdline" pid=1896 comm="sssd_sudo" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
3月 11 17:02:26 jd-dl-054.autox.sz sudo[1975899]: pam_unix(sudo:session): session closed for user root
3月 11 17:02:26 jd-dl-054.autox.sz sudo[1975899]: pam_unix(sudo:session): session opened for user root by (uid=0)
3月 11 17:02:26 jd-dl-054.autox.sz sudo[1975899]:  quanwen : TTY=pts/1 ; PWD=/home/quanwen/work/code/tcu/openwrt-22.03 ; USER=root ; COMMAND=/usr/bin/rm build_dir/target-aarch64_generic_glibc/nftables-json/nftables-1.0.2/ipkg-install/usr/lib/libnftables.la

I cloned the repository in another directory on the same disk, and compiled it, but the error did not occur again. Does it mean that the underlying filesystem is not broken?

No, the old directory structure could be broken or there could be other issue.

Could you try:

  • rebooting and trying to remove again?
  • running fsck on the affected filesystem?

I have tried reboot and remove them, but it doesn't work.

The output message of fsck:

$ sudo fsck
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/mapper/vgubuntu-root is mounted.
e2fsck: Cannot continue, aborting.

Ok, so let’s follow the error message. filesystem needs to be unmounted to run fsck. Since it’s root fs, the easiest would be to force fsck on next boot. You probably need to append fsck.repair=force to kernel params on boot.

This works for me. Thanks a lot.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.