00:15:30 <_xor> Oh good lord. 00:15:34 * _xor shudders after reading... 00:16:19 <_xor> "The utility to build the packages requires the GNU tar in PATH. The BSD tar isn’t compatible. We need to rename the existing executable: `mv /usr/bin/tar /usr/bin/bsdtar && ln -s /usr/local/bin/gtar /usr/bin/tar`" 00:17:29 <_xor> That's their solution instead of using a proper ${MAKE} macro :/ 00:18:44 <_xor> I kind of wish BSD tar would have an environment variable or something it can read as a hint for the expected behavior, and then invoke gmake instead where required. It would make porting easier. 00:19:05 <_xor> ...or tar/gtar, etc. 06:07:52 Hi, I'm new to freebsd, comming from openbsd. On reboot /etc/rc.conf get apanded by ifconfig_iwlwifi0="DHCP", since I configured lagg0, I dont see a reason why this should be there. 06:48:37 Voyager_MP: did you configure WPA? 06:57:20 yes 07:37:15 Voyager_MP: i reckon it might be responsible for that then 07:37:28 although it feels like a bit of overreach 08:02:59 Then I have a sound issue on a x1gen9, any help on this one ? 09:24:18 I have ng net 09:25:54 with ng_bridge connected to ng_ether and one ng_eiface connected to this bridge 09:27:15 after creating jail with vnet.interface = ngeth0 and starting ipfw on the host 09:28:45 i automatically get default rule in jail "65535 deny ip from any to any" 09:29:02 is this normal behavior? 09:32:46 Greetings! 09:37:43 I've tried to use make world to install FreeBSD into a jail 09:37:53 but then, the etc directory in the jail ends up not being populated 09:38:04 i.e. no /etc/rc, and an empty /etc/rc.d 09:38:07 what am I doing wrong? 09:38:15 I'm on a recent 14-CURRENT and ran 09:38:25 "make -j8 world DESTDIR=/myjail" 09:38:35 maybe,run make distribution instead? 09:39:01 that target is not listed in build(7) 09:39:10 <_xor> Not sure where the world target is these days, but I always do buildkernel buildworld installkernel installworld. 09:39:24 <_xor> distribution is a valid target. 09:39:31 oof 09:39:37 why is this shit not documented anywhere 09:39:57 <_xor> It is, at least for 13.x, unless they're changing it for 14.x. 09:40:05 where is it documented? 09:40:10 build(7) doesn't even list the target 09:40:28 <_xor> build(7), search for "distribute" 09:40:35 <_xor> It's distribute*, not distribution. 09:41:14 oh,sorry, it is distribute, indeed 09:42:40 <_xor> Also, for distribute it's DISTDIR, not DESTDIR. That bit me when I was originally trying to figure it out. 09:42:43 the distribute target is not listed either 09:42:54 and nowhere does it say that it needs to be run to properly install a system 09:42:57 <_xor> Maybe you're missing man pages too heh. 09:43:04 no they are all there 09:43:05 <_xor> You shouldn't need to run distribute*. 09:43:08 <_xor> https://man.freebsd.org/cgi/man.cgi?build(7) 09:43:10 Title: build(7) 09:43:11 (also make distribution did indeed work) 09:43:14 <_xor> It's on that page. 09:43:24 there is no target named "distribute" on that page 09:43:48 <_xor> Heh, which browser are you using? 09:43:49 distributeworld it is 09:43:59 _xor: recent Chromium 09:44:00 <_xor> Search for "Distribute everything compiled" 09:44:07 that is a differently named target 09:44:19 <_xor> Scroll up, I mentioned that. 09:44:41 and it is not documented that this target needs to be run to get a full system installation 09:44:42 <_xor> Also, I've had issues searching on some FreeBSD pages using browser find. It was odd. 09:44:57 <_xor> Scroll up, I mentioned that too. 09:45:01 I can assure you that I am able to search for strings in man pages just fine 09:45:23 mentioned what? 09:45:31 <_xor> I haven't used world target, but I remember it being used with mergemaster, which has been migrated to etcupdate now. 09:45:44 I am trying to create a new jail, not update an existing one 09:45:49 <_xor> That you shouldn't need to run distribute. 09:45:49 so using mergemaster seems pointless 09:46:10 <_xor> You don't need to use mergemaster, or etcupdate. 09:46:15 then what do I need? 09:46:35 just "make world" or "make buildworld installworld" did not install etc files 09:47:28 <_xor> I'm saying that because you ran the `world` target, which I haven't seen recommended in a long time. It might be stale, might not be managing /etc the same way, etc. 09:47:57 <_xor> Point is, I'd try to run buildworld installworld and see what happens. Also, would give a quick review of /etc/src.conf and /etc/src-env.conf as well. 09:48:03 I already did 09:48:07 it does the exact same thing 09:48:17 these two config files are empty 09:48:40 (make distribution did the trick but is entirely undocumented) 09:49:11 <_xor> I use those to create tarballs to use later for this exact purpose. 09:50:16 have you tried this with 14-CURRENT? 09:50:18 <_xor> Though AFAIK installworld should populate /etc, though I could be wrong about that I guess. distribute creates archive media from which to install. 09:50:20 <_xor> No. 09:50:42 maybe it changed 09:50:59 So to summarise: you have not actually tried to create a jail from source and had it work? 09:51:27 instead, you always build tarballs (which is a different sequence of steps)? 09:51:35 <_xor> From 14-CURRENT? No. From 13-*, 12-*, ...? Yes, many times. 09:52:13 <_xor> Now I do, but that's just because I create a lot of jails and it's easier to just fetch + extract tarballs. 09:52:39 <_xor> I still have to go through the build process to create the tarballs to begin with. 09:52:54 <_xor> Also, I keep the tarballs for multiple reasons, but my primary method now is actually to use pkgbase. 09:53:07 I would usually do something like this 09:53:18 but right now I'm setting up a jail for development on freebsd itself 09:53:25 so I need to be able to constantly work with the source 09:53:53 <_xor> I just use a variation of `pkg install --rootdir /path/to/my/jail FreeBSD-runtime FreeBSD-utilities ...` to install a jail. Super easy and fast. 09:54:57 and not applicable to my use case 09:55:20 as I will be modifying the source code and frequently rebuild/reinstall the jail 09:55:58 <_xor> Probably not, depends on what you're developing. I can build 14-CURRENT packages if I want and then create/destroy jails within a minute after that if I want. 09:56:51 Building packages takes a lot of time 09:57:04 I do not want to take any detours 09:57:34 why build packages just to immediately install them and then throw them away? 09:57:37 this is entirely pointless 10:57:06 t went dead when you left 11:13:53 I upgraded from 13.1-RELEASE to 13.2-RELEASE by freebsd-update tool, everything seems fine, rebooted multiple times, the system is back now. However, "bectl list" shows; 11:14:01 13.1-RELEASE-p7_2023-05-30_130402 - - 20.4M 2023-05-30 13:04 11:14:07 13.2-RELEASE_2023-05-30_130545 - - 3.75M 2023-05-30 13:05 11:14:13 default NR / 809G 2022-03-22 09:40 11:14:49 My question is, why the "default" is active? (Created in 2022?) 11:15:22 freebsd-version, uname -r, cat /etc/os-release all report the OS version is 13.2. 11:24:10 (Trying to delete older snapshots listed in "bectl list") 11:35:15 is it normal to have the "default" one created in 2022 but is up-to-date? 12:25:34 Then I have a sound issue on a x1gen9, any help on this one ? 15:29:53 hi all 16:52:01 I have an Android phone with photos I like to copy via USB cable to my FreeBSD system. I know it uses MTP. What's the least invasive way to do this? 16:52:22 I say as I start looking around the net and trying things... 16:52:38 there's an mtp client, let me look 16:53:11 gmtp. 16:53:30 * V_PauAmma_V found out about recently and uses it. 16:55:54 that looks like a GUI client 16:56:08 libmtp is the underlying implementation, I believe 16:59:48 I'll try gmtp. Thanks! I also just now found this forum posting: https://forums.freebsd.org/threads/mount-android-phone-using-mtpfs.75653/ 16:59:49 Title: Solved - mount Android phone using mtpfs | The FreeBSD Forums 17:03:49 RhodiumToad, it is. I guess "least invasive" is in the eyestalk of the beholder. 17:05:19 I never had much luck with mtpfs, though my use-case wasn't typical 17:06:03 FUZxxl: As you found by yourself, the target to use is "distribution". 17:06:24 FUZxxl: So, to install on an empty FS, you have to do "make installworld installkernel distribution". 17:07:50 OlCe: do you know why this is not documented? 17:09:07 I believe it is documented 17:09:11 where? 17:10:02 hm... FreeBSD handbook § 16.3.1.3 mentions it offhand 17:10:53 "distributeworld" is used to build a release, where you have to specify DISTDIR. Several "packages" will be created under this DISTDIR (such as "base", and at some point debug stuff, not sure if still the case today). 17:10:59 Don't know, no. 17:11:17 OlCe: distributeworld and distribution are distinct targets that do different things 17:11:31 When I say "least invasive" I pretty much mean not something which requires /etc/rc.conf setup for example. :-) Just run and go is best. 17:12:23 tercaL, 13.1-RELEASE-p7_2023-05-30_130402 created during 1st run of freebsd-update install - before install kernel from 13.2 17:12:46 FUZxxl: Yes, this is what I'm saying. 17:13:01 In your case, you want "distribution". 17:13:06 13.2-RELEASE_2023-05-30_130545 created during 2nd run of freebsd-update install - after 1st boot with kernel from 13.2 and before install world from 13.2 17:14:02 you can zfs destroy both if 13.2 work fine for you 17:15:04 rwp, that definition WFM in this case. I needed nothing more than was already needed to run Xfce. 17:18:09 I installed and ran gmtp and it runs but when I plug my phone into USB I don't see any device created. 17:18:25 I presume I need to figure out how to enable it in my phone since I assume it is not due to security reasons. 17:19:14 access control is in fact usually an issue 17:19:40 when you plugged the phone in, did you see a message in /var/log/messages reporting it being detected as a usb device? 17:20:38 I see "May 30 11:20:02 madness kernel: ugen1.3: at usbus1" logged to /var/log/messages. 17:20:43 I have in a /usr/local/etc/devd/blah.conf file a command that detects devices of the appropriate type and changes the ownership of the device node to my user 17:21:36 "gmtp" upon start says "No device attached". Selecting Connect says "Detect: No raw devices found." 17:21:44 but if it's just a one-off, you can find the device node manually 17:22:04 if you look at /dev/ugen*, you should see a recently created one 17:22:23 by default new usb devices are accessible only by root 17:22:34 I do find "crw------- 1 root operator 0x1c9 May 30 11:20 /dev/usb/1.3.0" having been created. 17:22:59 as root or sudo, do chown youruser /dev/usb/1.3.0 17:23:13 then see if gmtp can detect the device 17:23:35 Same as RhodiumToad here, plus I need to be logged in to my phone and authorize the connection request at the phone prompt. 17:23:56 right, that was going to be the next thing I was going to point out :-) 17:23:56 s/in to/in on/ 17:24:41 I am in group wheel already. "chgrp wheel /dev/usb/1.3.0" "chmod g+rw /dev/usb/1.3.0" should give me access as me. gmtp now says "Detect: No available Storage found on device?" 17:25:16 Interestingly the phone display doesn't change in any noticeable way at all. I expected it would say something. 17:25:16 It's group operatoe, not wheel. 17:25:47 s/operatoe/operator/ 17:25:56 they did do a chgrp 17:25:58 It gets created as group operator and not rw by that group. But I changed it to wheel since I am already in group wheel. 17:26:08 chown would have been simpler 17:26:19 anyway, the next step is to look at the phone settings 17:26:21 original: crw------- 1 root operator 0x1c9 May 30 11:20 /dev/usb/1.3.0 changed to: crw-rw---- 1 root wheel 0x1c9 May 30 11:20 /dev/usb/1.3.0 17:26:45 Agreed. Let me dig into phone settings. And I have a meeting coming up. Thanks! 17:26:58 the fact that gmtp is detecting _something_ means it can see the device and communicate 18:16:58 is there a way to optimize zfs to occupy less space for symlinks ? 18:18:32 Store in metadata if possible? 18:18:50 how long are the symlinks? 18:19:08 I have a backup job that basically symlinks a whole bunch of files arounds. For one backup job for example symlinks occupy 60Gb 18:19:19 it is stored in metadata, in my special device 18:19:28 Ok 18:20:04 https://pastebin.com/pWcs3WVd 18:20:05 Title: special - - - - - - Pastebin.com 18:20:10 symlinks take up that much space? aren't they just.... names? 18:20:32 the thing is I think I may run out of storage on the special device 18:20:43 didn't realize symlinks can occupy this much space 18:21:06 each symbolic link contains the path of the source (or, target; whatever) 18:21:28 is it like a symbolic link takes physical space on the disk itself and it's a minimum number like 4k? 18:22:04 if so maybe it can be optimized somehow to use less space per unit 18:22:30 aah, ok. yes, the symlinks would be pretty long 18:22:39 symlinks in zfs should be stored as a system attribute, but if they're long, that could overflow 18:23:15 I've also set the recordsize to 1M because it helps with my files 18:23:22 not sure if that has an influence on symlinks 18:24:45 That 1M recordsize is also set on the "specical device"? 18:25:29 last1: can you put numbers on that "pretty long"? 18:25:45 MAXPATH 18:25:47 heh 18:26:05 parv: ah, good catch. no, just on the data 18:26:15 rhodium: let me count the characters 18:26:46 last1, Whew😅 18:27:38 i guess it's actually PATH_MAX 4096? 18:28:10 no 18:28:22 the symlinked directory is 93 characters long 18:28:33 the original one is 62 18:28:42 that shouldn't be enough to overflow 18:28:51 unless there are a lot of other system attributes 18:29:21 it looks like by default, there's about 300 bytes available for attributes 18:30:37 not that I know, I'm basically doing: cp -alR $srcdir $dstdir 18:30:48 how much space per symlink do you see used? 18:31:06 how can I see that ? 18:31:54 you're saying that the symlinks are taking a lot of space, so you must have some idea of how much space is used and how many symlinks you have 18:32:47 ah yes, by comparing between backup jobs 18:33:00 let me get a total count of dirs which are symlinked 18:34:16 .oO( "readlink(1)" is what I was looking for, not "cat(1)", "less(1)" ) 18:37:53 ah yes, turns out I'm an idiot 18:37:58 with cp -al I'm creating hardlinks 18:38:02 not symlinks 18:38:21 is that different in terms of used storage ? 18:39:33 hardlinks don't use any storage at all 18:39:40 except in the directory 18:40:24 so if I do : cp -al $srcdir $dstdir , $dstdir won't occupy any space ? 18:40:32 that's essentially what I'm doing 18:44:53 dstdir will take only the space needed for the directory itself 18:46:38 directories do get stored in "special", iirc, if possible 18:49:30 ok, let me see how many directories I have in total in this backup job 18:49:46 not 100% sure about directory storage 18:50:49 about 860 000 hardlinked directories 18:51:34 last1, Are you making hard link to directories, not files? 18:52:28 to directories yes 18:53:00 each backup job is about 860k directories and 125M files 18:53:18 cp -l only links to plain files, not to dirs 18:53:36 860k directories is a nontrivial amount of space in itself 18:54:08 for example, inodes used shows as : 549 149 229 18:54:28 directories cost an inode but hardlinks don't 18:54:43 "ln dir name-link" fails on 13/stable with "ln: dir: Is a directory" 18:54:44 I think I see where this is going, I need another special mirror :) 18:59:34 Another thing to note hardlink cannot be create across file systems, from first paragraph after option description in "ln(1)" manual page 18:59:43 s/create/&d/ 19:03:53 last1: was it you a while back who asked for a way to detect/block IPs that weren't responding to syn+ack ? 19:16:37 might have been me, I was looking for something like fail2ban to act on them 19:16:50 one of my servers was getting probed with tons of SYN packets 19:17:01 netstat was just showing SYN_RECVD I believe 19:17:13 I ended up just blocking a few /16s 19:17:25 did you find anything? I needed something similar recently, but it stopped before I did anything much 19:17:58 I _suspect_ it was an attempt at some sort of reflection attack 19:18:45 I worked out a possible solution but didn't complete an implementation 19:19:54 What FS support hardlinks on dirs? AFAIK zfs and FFS/UFS/UFS2 doesn't. 19:20:02 the idea was to snag logs of outgoing syn+ack using an ipfw rule and tcpdump, look for high-frequency targets, and use the hostcache.list to exclude likely legitimate IPs 19:21:04 (hostcache is updated on connection _end_, but something shouldn't be sending a lot of SYNs without having made some previous connection) 19:23:07 VVD: ln(1) says "Directories may not be hardlinked" without mentioning that it's related to fs limitations, so probably none? 19:23:44 RhodiumToad: is a reflection attack sending packets to server A so that it sends a much larger number to server B? 19:23:57 link(2) also says "The name1 argument may not be a directory". 19:24:00 yes. 19:24:33 sort of like ordering a million pizzas for the person next door 19:24:34 yuripv: way way back in the day they could be. but when the directory structure is not actually a tree, file operations can deadlock. 19:25:18 This is to guarantee that file structure is a D... what RhodiumToad said. 19:25:44 yuripv, it's message to last1. 19:25:47 johnjaye: for example, if some host has a large DNS entry, the attacker can forge B's IP address in a DNS query to DNS server A, which then sends a response to B 19:26:11 so then what does cp -alR $srcdir $dstdir do exactly ? 19:26:27 B's dns entry? 19:26:32 or is that not necessary 19:26:45 last1: it creates directories recursively and populates them with hardlinks to the original files 19:26:58 johnjaye: any DNS entry that server A will provide 19:27:15 johnjaye: NTP has been abused in similar ways 19:27:16 oh wow, so then my space usage is coming from the directories being actual directories 19:27:16 VVD: right, sorry, i read that as a question out of context :) 19:27:33 and the files themselves are just hardlinks that don't take up space (?) 19:28:11 i typed it into google and it said dns, ntp, and snmp are all possible vectors for that. 19:28:18 and you can't do anything because you don't control the dns 19:28:34 syn issue: I think someone was doing some sort of crude syn attack 19:28:43 that's what I saw too 19:29:05 as i understand it the design of tcp/ip itself is flawed. in that ddos attack is built into it 19:29:20 so the only way around it would be a redesign or else giant companies like Cloudflare 19:29:22 128.116.0.0/17 <-- blocked this one 19:29:25 it's not possible to prevent attacks while still allowing communication 19:29:26 and a few others 19:29:57 185.141.34.0/24 , this was another big source 19:30:34 what I saw was only from a small number of IPs, which is why i suspect it was a reflection attack 19:31:00 (because in that case the IPs seen are the targets, not the attackers) 19:31:28 johnjaye: the biggest factor in allowing attacks is networks not doing ingress filtering, which is nothing to do with tcp 19:32:02 it was a few IPs in my case as well but I checked these blocks on ARIN and they're colo / hosting providers 19:32:09 same here 19:32:24 and I don't need their traffic anyways which is why I blanket blocked large subnets 19:33:01 any of these look familiar: 20.2.248.166 38.238.153.234 38.238.213.146 45.15.145.92 102.60.8.14 103.116.15.134 172.247.80.213 172.247.80.61 19:33:46 what is "large" for that kind of scenario? 45.15.*.*? 19:35:24 last1: what was the targetted service? web? 19:35:36 (in my case it was dns) 19:36:26 yes, ports 80/443 19:37:00 ips: nope, I got hit with entirely different ones 19:37:20 45.237.112.0/24 19:39:28 I'm compiling a list of ips that send weird packets so I can block across multiple servers 19:39:33 so far I have 300 000 entries :) 19:40:12 the entire colohosting range can be blacklisted 19:41:01 99% of their traffic *is* malicious 19:41:06 well that rather depends on what service you're trying to provide :-) 20:07:12 all vpn providers mostly exit through colo ip ranges 20:07:22 so we'd be banning that as well 20:07:26 something I don't mind doing at all actually 20:42:51 <_xor> RhodiumToad: https://stork.readthedocs.io/en/v1.10.0/install.html#installing-on-freebsd 20:42:52 Title: 2. Installation — Stork 1.10.0 documentation 20:43:04 <_xor> RhodiumToad: Second code fence is what I was talking about earlier. 20:44:42 <_xor> FUZxxl: Huh? All I was describing is how I built & installed jails, either from source or from pkgbase. You seemed to be arguing a strawman, as I wasn't advocating for doing that and against what you were trying to do. Chill out. 20:46:05 _xor: sorry, answers of the kind "I don't know an answer to your question but here is $COMPLICATED_THING you should totally sink hours into doing instead" are something that is mildly triggering me 20:46:13 I should get a grip on myself 20:47:15 especially as is often the case if the person recommending me to do $COMPLICATED_THING doesn't actually know if it'll solve my problem 20:47:37 <_xor> Yes, you should. I didn't imply that you should do $COMPLICATED_THING, you inferred that. I was just giving you another potential option. I didn't know the details of why you were doing what you were trying to do. 20:48:00 <_xor> I even said you it probably wouldn't in your case once you said that you were working on src. 20:48:51 Thank you. I will strive to improve my conduct. 20:49:37 <_xor> Again, you read what I was telling you as me recommending you do it. I literally said "Here's what I do in my case..." AND I was just going off of you trying to build a jail. That's literally it. It's shit like that which turns people off from wanting to add anything that might be of value. 20:51:21 I tend to read these as "and don't come back until you have tried doing that" 20:54:27 <_xor> Yes, I know. That's exactly why I say stuff like "Here's what I've done for that..." not "Here's what you need to do..." I don't like getting static when I'm trying to contribute something, whether it ends up having value or not, I leave that for you to decide. The alternative is that people just don't contribute, but it's easier to contribute and 20:54:27 <_xor> let the person decide since they know their situation best (just not the available options). 20:55:20 <_xor> For me, at least, it makes me slightly less apt to contribute in the future. Like if I see a question that I might have an answer for, I might think, "Eh, I'm in a hurry. Not worth it, especially if they're going to be ungrateful." 20:55:24 <_xor> Anyway, no worries. Back to work. 20:56:56 I've really started to prefer answers that do not try to think out of the box and instead directly answer the question 20:57:23 I'm not a beginner. If the answer is "no" or "it won't work this way" I can think for myself about other ways to do it. 20:57:42 * _xor sighs 20:57:46 If I ask a question, I'm usually looking for an answer to the exact question I asked and no other. 20:58:09 FUZxxl: my rule of thumb is to give a short answer, then clarify that you're probably asking the wrong question and the thing you just said won't do what you want. 20:58:20 However, for some reason people tend to immediate go off and try to respond with anything but answers to the question 20:58:34 "Can I drive my car off a cliff?" Yes you can, but it's not going to fly the way you imagine. 20:59:07 E.g. I just asked a complex question about locking and atomics in ##c and had to spend the first 15 minutes fending off attempts of people to tell me how to use a different locking approach before I got to an answer to my question 20:59:18 this just sucks 20:59:54 <_xor> Ok I'm going to go against my better judgement and continue this. 1) Outside of the box is qualitative. You might see it as outside of the box, I certainly don't. 2) Directly isn't always clear, maybe to the speaker, not to the listeners. 3) I know you're not a beginner. 4) I wouldn't give you definitive statements without knowing details behind 20:59:54 <_xor> the question, I was literally just giving you another potential option. 21:00:28 _xor: well on the internet there is no nuance or tone. if you ask you how to do x. and you reply well i did y. that sort of implies that i should try y. or at least think about it. 21:00:29 <_xor> It just sounds like you were frustrated at the problem and taking it out on me because I couldn't immediately end that problem for you. 21:00:40 the thing that tends to happen is that once people give these "alternatives" and "out of the box answers" others assume the question has been answered 21:01:04 I found that the only way to get an answer is often to continuously press that I want an answer to my question and not an alternative solution 21:01:04 <_xor> johnjaye: Yes, that's exactly why I VERY EXPLICITLY say, "Well, to do that, here's what I do..." 21:01:12 I understand that part 21:01:24 i couldn't see the scrollback. i'm just saying how both of you have valid points. 21:01:34 this is becoming tedious 21:01:40 <_xor> All right, now I actually don't have time for this. 21:01:43 ok 21:01:46 have a good day! 21:01:48 <_xor> I need to go workout. 21:02:21 fwiw I use make installworld distribution installkernel a lot 21:02:41 <_xor> Is distribution needed to populate /etc? I thought installworld did that. 21:02:46 yes 21:02:51 installworld does not do that 21:02:58 <_xor> Good to know. I was wrong then. 21:03:11 i didn't know that either. 21:03:12 noted, I have compiled several custom kernels and assumed that installworld did that. 21:03:28 <_xor> Did world do that before? I think maybe that's where the confusion comes from. 21:03:40 the docs focus on installworld on the assumption that you're updating an existing system 21:04:01 make distribution is DANGEROUS because it will clobber /etc if DESTDIR is not set 21:04:16 <_xor> Yes, I've been bitten by that :| 21:04:18 installworld has never installed /etc 21:04:51 I guess that makes sense, absent any conflict resolution (a la .pacnew) 21:04:55 <_xor> I got DESTDIR and DISTDIR confused. 21:06:20 the one letter difference isn't encouraging 21:06:38 <_xor> Yes, I copied and pasted a line and boom...bye bye. 21:07:02 <_xor> Boot environments are nice. 21:08:22 <_xor> RhodiumToad: Did you mistype that or did you mean DISTDIR above? 21:08:43 _xor: it's weird that the distribution target seems to be largely undocumented 21:08:55 the only documentation mach I found was in the handbook on creating jails 21:09:26 _xor: I should perhaps go and file a bug on that 21:09:28 <_xor> It's on that page I linked earlier for build(7). Though it should be more thoroughly documented. 21:10:01 _xor: which page was that? build(7) does not document the distribution target (only distribute{kernel,world} which are for release making and do something different but related) 21:10:49 <_xor> Oh, I misinterpreted. You literally mean distribute, not distribute*. Yes, I'm not sure where that's documented (if it is at all). 21:10:58 distribution 21:11:11 yes I literally mean what I write (usually) 21:13:00 * RhodiumToad_ apparently missed a few minutes there 21:13:53 <_xor> I just ripgrep'ed /usr/src to look at distribution targets and see what they do. 21:14:16 <_xor> Well, 'distribution|distribute.*' 21:14:35 note that the old distribution target in etc/Makefile, which checks DESTDIR, is apparently not used now 21:15:11 <_xor> Yeah, I was wondering why distribution was ringing a bell and I used to use it a while back. I was looking at my notes/scripts and saw that I'm explciitly invoking distribute*. 21:15:14 there was a reorganization some time back which moved a lot of stuff out of src/etc and into the subdirs for the programs owning the files 21:15:49 which means that making /etc now requires recursing through the whole tree rather than just into src/etc 21:17:13 * _xor is looking at /usr/src/Makefile 21:17:15 it looks like now, make distribution actually invokes make installconfig 21:17:35 see Makefile.inc1 21:17:55 <_xor> L155 & L200:L217 illuminate a bit. 21:17:59 * _xor opens Makefile.inc1 21:18:44 installconfig is I think not a user-visible target 21:22:00 * _xor is glad he looked at the targets 21:22:13 <_xor> I see build32, install32, & distribute32. 21:22:35 <_xor> Was wondering why I wasn't able to generate the tarballs for lib32. Are those the targets of interest in that case? 21:26:22 <_xor> Ah, apparently so. 21:28:14 installworld certainly installs lib32 21:32:02 last1, Did you find your backup directory size issue? 21:55:37 parv: I guess it's actual usage 21:55:49 how can I find out the actual size of a directory name in zfs 21:56:03 last1, Ok. What was the situation with the hard links? 21:56:04 not the contents of the dir, but rather how much the dir entry 21:56:35 the directory contents - the files are hardlinked, but the directories themselves are created anew each time 21:57:48 so if I have 850 000 directory names and I get 60Gb of usage = 70Kb/directory name 21:57:54 seems kind of excessive 21:59:15 I do not know how to get the size for a directory entry other than diving in the source. There may be some presentation/papers, possibly outdated, where the minute details from developers' perspective would be mentioned 22:00:16 how many files per directory? 22:01:01 there's no set number, average, etc. it can be any number from 0 to 80 000 22:05:07 Then use the worst case for the maximum size 22:05:38 is compression on? 22:06:13 I wonder, can I set compression for the special device 22:07:55 also there might be something off with what I'm doing in my backup job 22:08:07 for example if I do stat -f '%l' it prints 13 for a file 22:08:14 but there shouldn't be 13 copies of that file 22:10:58 stat -f '%b' on a directory on zfs reports _something_, which is nominally the size of the directory file in 512-byte blocks 22:11:08 whether it is accurate or not I don't know 22:12:40 (ls -ls also reports that size, but in blocks of size BLOCKSIZE as set in the environment) 22:14:17 eh, it's probably correct and I just deal with lots of data - I'll but two more ssd special devices and be done with it 22:23:52 On use of stronger passwords & PAM: https://lists.freebsd.org/archives/freebsd-current/2023-May/003784.html 22:23:54 Title: Re: Surprise null root password