User talk:Scimmia
Revert edit that fixes dm-crypt instructions
Hi,
I recently noticed that you reverted my edit, i understand why, but the the wiki pages states that the user should use the persistent block device, in which in my recent arch install, i did and it did not work. The #archlinux:archlinux.org matrix room told me to use the blkid command and use the UUID of the LUKS superblock instead of the persistent block device, i think you misunderstood my edit or that i didnt clarify the edited instructions. Pixrobot8 (talk) 21:21, 9 January 2024 (UTC)
- You're confused on what a persistent block device reference is. Using the UUID of the LUKS superblock *IS* persistent block device naming. Scimmia (talk) 00:17, 10 January 2024 (UTC)
- Oh, i got confused. I'm talking about something like /dev/sda2 or /dev/nvme0n1p2 Pixrobot8 (talk) 15:31, 10 January 2024 (UTC)
- Which is not what it tells you to use. It specifically says to use the UUID, and links to the page that tells you how that works. Scimmia (talk) 18:05, 10 January 2024 (UTC)
- But it says "in this case" and says /dev/sda2, and instead of that it should have the blkid command. Pixrobot8 (talk) 19:21, 10 January 2024 (UTC)
- It says that you should get the UUID of that device, yes. It never tells you to use that. And for the last time, it links to how to get and use that. READ THE LINKED PAGE. Scimmia (talk) 19:40, 10 January 2024 (UTC)
- Yes i know, but the thing is that a normal person would assume to put /dev/sda2 instead of the actual UUID of the LUKS superblock Pixrobot8 (talk) 21:00, 10 January 2024 (UTC)
- Like this: Pixrobot8 (talk) 21:01, 10 January 2024 (UTC)
cryptdevice=UUID=/dev/sda2:root root=/dev/mapper/root
Pixrobot8 (talk) 21:04, 10 January 2024 (UTC)- No, a normal Arch user when coming across a term they're not familiar with would have clicked the link. Scimmia (talk) 22:16, 10 January 2024 (UTC)
- Well yeah, but a new user probably wouldn't. Anyways, nl6720 edited the page himself so there isn't any point in arguing about this anymore. Pixrobot8 (talk) 10:45, 11 January 2024 (UTC)
- No, a normal Arch user when coming across a term they're not familiar with would have clicked the link. Scimmia (talk) 22:16, 10 January 2024 (UTC)
- Like this: Pixrobot8 (talk) 21:01, 10 January 2024 (UTC)
- Yes i know, but the thing is that a normal person would assume to put /dev/sda2 instead of the actual UUID of the LUKS superblock Pixrobot8 (talk) 21:00, 10 January 2024 (UTC)
- ,,Scimmia (talk) 19:40, 10 January 2024 (UTC)
- It says that you should get the UUID of that device, yes. It never tells you to use that. And for the last time, it links to how to get and use that. READ THE LINKED PAGE. Scimmia (talk) 19:40, 10 January 2024 (UTC)
- But it says "in this case" and says /dev/sda2, and instead of that it should have the blkid command. Pixrobot8 (talk) 19:21, 10 January 2024 (UTC)
- Which is not what it tells you to use. It specifically says to use the UUID, and links to the page that tells you how that works. Scimmia (talk) 18:05, 10 January 2024 (UTC)
- Oh, i got confused. I'm talking about something like /dev/sda2 or /dev/nvme0n1p2 Pixrobot8 (talk) 15:31, 10 January 2024 (UTC)
Revert on pacman # querying package databases
Hi,
I noticed you reversed my changes on the basis that "Pacman doesn't do fuzzy searching at all -Q is not searching" and I think there was a misunderstanding. I am not a native english speaker. I get that -Q
is for querying, the thing being that the way I formulated my sentences, I meant for "search" to have the user as a subject where "searching packages" would as such be the goal desired by the user and not the internal mechanism pacman uses.
If that wasn't the problem, then I'd be genuinely curious as what it is you would consider to be the difference between "a user searching for packages by asking pacman to query its databases" and "a user querying pacman for its database" or "a user asking pacman to query its database" for, again, I am not a native english speaker.
And for the part about "fuzzy searching", I also intended for that to be expressing the functionality which the user wishes to attain and which can be met by using pacman's -s
suboption and not to be simply about pacman's internals.
Again maybe that was simply a wrong direction I went in, in which case I'd gladly learn which way the wiki should rather document pacman's usage.
Best regards KStor2poche (talk) 20:09, 17 June 2024 (UTC)
- Hi, bumping this question. I'd genuinely like to help improve this wiki but might need some guidance regarding what I did wrong. KStor2poche (talk) 14:18, 28 June 2024 (UTC)
- I really thought I'd just leave this alone, as the summary really said it all, but OK, let's do this.
- Everything you put can be summed up by simply saying 'search'. Seriously, you go on a long explanation, which is wrong, with multiple examples, all to explain what search means? Yes, putting in 2 terms searches for both terms, that pretty much how all searching works! Search doesn't mean 'display info on this specific package', it means search!
- Scimmia (talk) 14:33, 28 June 2024 (UTC)
- Thank you very much for the answer, that clarified it for me. My explanation was just me trying to get what the problem was with my use of the word "search" by exposing my conception of it, as this verb was previously used in this article without any problem for other suboptions.
- While I would agree that "display info on th[ese] specific package[s]" would make much sense for the
-Si
and-Qi
options, I don't think it's as relevant for a single-Q
, for if I really wanted to "display info on this specific package" I'd then rather directly use-Qi
to get the full picture. - But then I guess the way I use pacman doesn't reflect the way the majority of arch users do and I trust by your experience that you know more about it than I do so I'll just leave it there.
- Thanks again for the clarification! KStor2poche (talk) 15:09, 3 July 2024 (UTC)
revert systemd-tmpfiles
Hi, I just noticed you reverted my change in the systemd-tmpfiles article. First thing I want to say is thank you for your contributions to the ArchWiki. Now, I stand by what I wrote in the article. I am not deeply familiar with systemd-tmpfiles, but on my system
- the service
systemd-tmpfiles-setup.service
is enabled by default and starts every boot, - it creates directories I listed in the example.
The service runs the following command systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
When I run the command manually with a --dry-run
flag, the output confirms that the tool creates and handles more than just temporaries, but also essential (/home) and package-specific (/var/lib/gitlab-runner) directories:
Would copy tree "/usr/share/factory/etc/pam.d" to "/etc/pam.d" Would create directory /var/lib/geoclue Would create directory /var/lib/gitlab-runner Would create directory /run/gluster Would create subvolume /home Would create subvolume /srv Would create directory /var/lib/lastlog
Please correct me if I am wrong, but it does seem like my edit was correct. I have not changed the default configuration of the service, nor have I started it manually - I believe these are the defaults on Arch. Staticnoise (talk) 22:31, 18 June 2024 (UTC)
- See the filesystem package. systemd-tmpfiles does NOT create the dirs you mentioned on Arch, the package does. Scimmia (talk) 22:34, 18 June 2024 (UTC)
- Yes, the filesystem package does create them on installation, so my wording was off. And it is also true that systemd-tmpfiles handles more than tmpfiles, including /etc entries and package directories (as you can see in the log above), which was the point of my edit. I will remove the reference to the basic dirs such as /home and update my edit. Staticnoise (talk) 22:43, 18 June 2024 (UTC)
- It mainly handles tmpfiles and permissions in Arch. AFAIK, it shouldn't be handling things in /etc, that's mainly there for immutable type systems. Scimmia (talk) 22:45, 18 June 2024 (UTC)
- Maybe it shouldn’t, but it does, you can see for yourself. This is surprising behaviour for me too, which why I thought it was wothy of an explanatory note. Staticnoise (talk) 22:48, 18 June 2024 (UTC)
- You'll have to give specifics. On the system I'm on, that pam.d line does nothing at all. I would guess it's that way on most, if not all, Arch systems.Scimmia (talk) 22:50, 18 June 2024 (UTC)
- Maybe it shouldn’t, but it does, you can see for yourself. This is surprising behaviour for me too, which why I thought it was wothy of an explanatory note. Staticnoise (talk) 22:48, 18 June 2024 (UTC)
- It mainly handles tmpfiles and permissions in Arch. AFAIK, it shouldn't be handling things in /etc, that's mainly there for immutable type systems. Scimmia (talk) 22:45, 18 June 2024 (UTC)
- Yes, the filesystem package does create them on installation, so my wording was off. And it is also true that systemd-tmpfiles handles more than tmpfiles, including /etc entries and package directories (as you can see in the log above), which was the point of my edit. I will remove the reference to the basic dirs such as /home and update my edit. Staticnoise (talk) 22:43, 18 June 2024 (UTC)