[SOLVED] I messed up permissions in /usr

seth · 2020-11-15 09:09:51

What happens if you just press enter?

fire100265 · 2020-11-15 09:11:45

I can't. The prompt does not allow me to respond and is instead answered with the hash.

seth · 2020-11-15 09:16:43

Of course you can "just press enter" - the question is what happens next.

Please make a photo, only post a link.

fire100265 · 2020-11-15 09:26:06

https://imgur.com/a/Qg3PDiW

I couldn't press enter to respond.

seth · 2020-11-15 09:30:13

There's an input problem and you're back at the root prompt.
(You should be able to issue another command now?)

Please post an image of the command you actually enter.

fire100265 · 2020-11-15 09:37:03

https://imgur.com/a/3y2ojzB

Yes I can type commands.

seth · 2020-11-15 09:59:07

Sone stray nonsense in the output of the package list?

pacman -r /mnt -Qnq > /tmp/packages.text

Lookat and upload that file. Also pay attention to whether that command leaves you w/ a similar hash.

fire100265 · 2020-11-15 10:11:23

There were no error when executing the command. Here is the link: http://ix.io/2Ee7

seth · 2020-11-15 10:14:41

can you

pacman --sysroot /mnt -S - < /tmp/packages.text

?

fire100265 · 2020-11-15 10:19:17

I still get the hash. Is it better if I reinstall Arch?

Last edited by fire100265 (2020-11-15 10:20:23)

GaKu999 · 2020-11-15 10:58:00

seth wrote:

can you

pacman --sysroot /mnt -S - < /tmp/packages.text

?

I think there may be a hidden bug in there, the process lies in the background, and does not accept terminal input, it's like it's still listening to the redirection...

Let's do it in a way that I haven't managed to replicate that issue.

killall pacman # you probably have a couple of these lingering
rm /mnt/var/lib/pacman/db.lck # remove the lock, it may or may not be there
pacman --sysroot /mnt -S $(pacman -r /mnt -Qnq) # notice that this does not have redirection

fire100265 · 2020-11-15 11:08:27

Thank you so much! I can now press enter to start the download. This time I get another error though:

error: could not open file: /etc/mtab: No such file or directory
error: could not determine filesystem mount points

Last edited by fire100265 (2020-11-15 11:08:47)

GaKu999 · 2020-11-15 11:14:26

Post output of

stat /mnt/etc/mtab

After that, since this is keeping up for quite long with the inevitable outcome:

pacstrap /mnt $(pacman -r /mnt -Qnq)
arch-chroot /mnt
pacman -Qkk | curl -F 'f:1=<-' ix.io # post the link

seth: pacman does not remain alive when calling in a root shell like that, ~~but sudo is an example of something that will make it stay alive.~~ I'll report in the bugtracker.

EDIT: Discard the alive, it was an one time thing it seems.

Last edited by GaKu999 (2020-11-15 11:40:51)

fire100265 · 2020-11-15 11:48:28

Thank you so much! I can boot in and it works now. Output for the first command:

  File: /etc/mtab -> ../proc/self/mounts
  Size: 19              Blocks: 0          IO Block: 4096   symbolic link
Device: 815h/2069d      Inode: 6422560     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2020-11-16 03:35:40.601152256 +0900
Modify: 2020-09-03 06:30:21.000000000 +0900
Change: 2020-11-16 03:33:59.164484446 +0900
 Birth: 2020-11-16 03:33:59.164484446 +0900

Link for the second command: http://ix.io/2EeP

GaKu999 · 2020-11-15 12:03:39

Good to know, now be careful with recursive commands!

fire100265 · 2020-11-15 12:18:59

I will. Thanks to all of you who helped me.

Trilby · 2020-11-15 14:06:34

Sorry about the -r vs --sysroot issue. I suggested the wrong one.

As for the original issue - recursive commands are certainly risky, but honestly everything in your first post would have been fairly easy to recover from *except* the chmod 4755 command. Adding that 4 (setuid / stickybit) opened a much much bigger can of worms which resulted in a couple of us suggesting that'd be best to just delete the entire /usr and rebuild it.

The general lesson is simply never run commands (especially as root) if you don't understand what they are doing. And that's even the case when seasoned members of this community give suggestions - they are suggestions for you to understand first, then implement. As you can see we all make mistakes and give the wrong flag for a command sometimes (and I even editted it a couple times just after posting as I forgot the 'q' in 'Qnq' which would have also caused failure). Don't blindly trust anyone's advice on what commands to run as root.

Arch Linux

#26 2020-11-15 09:09:51

Re: [SOLVED] I messed up permissions in /usr

#27 2020-11-15 09:11:45

Re: [SOLVED] I messed up permissions in /usr

#28 2020-11-15 09:16:43

Re: [SOLVED] I messed up permissions in /usr

#29 2020-11-15 09:26:06

Re: [SOLVED] I messed up permissions in /usr

#30 2020-11-15 09:30:13

Re: [SOLVED] I messed up permissions in /usr

#31 2020-11-15 09:37:03

Re: [SOLVED] I messed up permissions in /usr

#32 2020-11-15 09:59:07

Re: [SOLVED] I messed up permissions in /usr

#33 2020-11-15 10:11:23

Re: [SOLVED] I messed up permissions in /usr

#34 2020-11-15 10:14:41

Re: [SOLVED] I messed up permissions in /usr

#35 2020-11-15 10:19:17

Re: [SOLVED] I messed up permissions in /usr

#36 2020-11-15 10:58:00

Re: [SOLVED] I messed up permissions in /usr

#37 2020-11-15 11:08:27

Re: [SOLVED] I messed up permissions in /usr

#38 2020-11-15 11:14:26

Re: [SOLVED] I messed up permissions in /usr

#39 2020-11-15 11:48:28

Re: [SOLVED] I messed up permissions in /usr

#40 2020-11-15 12:03:39

Re: [SOLVED] I messed up permissions in /usr

#41 2020-11-15 12:18:59

Re: [SOLVED] I messed up permissions in /usr

#42 2020-11-15 14:06:34

Re: [SOLVED] I messed up permissions in /usr

Board footer