exit

there is no exit

welcome to the hotel california

Your exits are (N)orth and (S)outh >

eat exit

having switched to pkgbase I kinda miss running the freebsd-update scripts :D

haha

anyone has very minimal base system that is enough for poudriere's jail? usually i do have base built from src for my laptop. i also make poudriere jail from /usr/src just verbatim as for the laptop but it might be too big. i do not need many things there ( in a poudriere's jail ), no mans, no docs. i just wonder if there is barebone minimal accepted jail which is enough to build packages

not really but ive been working on a tool that can take an executable, find everything it depends on it, and launches a jail with it. it can also take files.txt and include those in the jail too. So its certainly possible, with a bit of work, and study.

I ran into pam.d configs getting reset during a pkgbase upgrade to 15.1.

Anyone else seen this? forums.freebsd.org/threads/warning-…de-resets-pam-configurations.103113

I just thought yesterday about 15.1 being the first bigger pkgbase upgrade and how it'll probably have a bug or two

hello

EHLO

NO CARRIER

ATH0

is there a preferred pastebin for the freebsd channels?

catbin.site/?__cf_chl_f_tk=dSXd1_sJ…ldDXa8AWOHjxROKOonq3xOsHh.NQqJaGVAA ?

Sorry, I have no idea what that site is, I found it by typing "This paste bin kills cats" and it was the first link

catbin.sh Looks much better

spork_css, There used to be a preferred on in the /topic but the site failed off and now we just use whatever pastebin we happen to use. bpa.st paste.debian.net are both popular. So are others.

I have a list of 18 pastebin sites in my notes file. Some are undesirable with lots of advertising.

I'll go with this for now: bpa.st/JOWQ

spork_css, Is there a question in there?

my question: da0 and da2 are the exact same model ssd. da2, out of the box, was created by doing "gpart backup da0 > da0-part" and "gpart restore da2 < da0-part"...

yet da2 for some reason has an extra empty 6 bytes in front of the EFI partition.

Hmm... I would also not expect there to be a difference.

yeah, I was about to start swapping it in to a pool and didn't like that.

I expect the answer will be that da0 was created using an older version of gpart and da2 created with a newer version is refusing to recreate the original exactly due to some reason.

(Also it is possible to do that on one line. gpart backup da0 | gpart restore -l -F da2)

nope, da0 setup with the 15.1 installer last week, da2 a few days ago - also I write it out so I can change the labels.

Less room for shenanigans. I would be inclined to do it again and verify there are no errors produced anywhere including /var/log/messages (in case the kernel logged something).

rwp: i have exactly the same issue

and i believe i created my mirror the same way

Hmm... First, I don't know and will be brainstorming right along with you. Like suggesting that one could simply dd the partition table from one device to the other as that should result in an exact copy. Beware of UUID duplication.

that said, it's in the pool and works fine

I was going to mention that it should still work and be fine. But, that is curious that they differ.

they absolutely should not differ...

anyhow, here's the full sequence, that includes showing da2 is wiped: bpa.st/UEMA

lol, ok, now this is even more confusing: bpa.st/NSIQ

(gpart backup of da2 does not show the 6 byte hole)

what is on 0-40 on the disk?

anything?

I assume something to align with the block size? When I manually do this I throw 1MB at the head for some cargo cult reason.

i feel like that convention is long past needed

my gpart backups look exactly the same

but the installer is where da0 came from

Because modern SSDs and "Advanced Format" HDDs use 4KB physical sectors, partitions must start on a multiple of 8 sectors (since 4096 ÷ 512 = 8). Sector 34 is not divisible by 8, so gpart rounds up to sector 40, which is the first available 4KB-aligned sector, to prevent severe performance degradation

I one of these SSDs has like a 67% wear indicator, so that just gets me more agitated about wrong boundaries and write amplification.

ok, so that _could_ account for your gap

spork_css: If you toss in a "dd if=/dev/zero of=/dev/da2 bs=1M count=50" after the "gpart destroy -F da2", does it make any difference?

I'd make sure the beginning of that drive was totally wiped before recreation.

(of note, these drives, other than the new one, were all in a vmware box - so I have no idea of the wear is just me thrashing the thing for years or if vmware/Dell RAID setup did something improper)

ek: nope bpa.st/DQ7A

spork_css: I'm guessing you're using smartctl to get the wear number(s)? Which wear ID did it give you? Depending on the drive, 67% could be either an indication of what it has done or what is left.

yeah, very familiar with that. in this case, smartctl is here, but also the host is now running Sylve, which shows those stats in the UI.

That is so strange. I just checked all my FBSD ZFS mirror setups on UEFI and I don't see anything like that anywhere. All disks are 100% identical.

I went looking too. All of mine are identical as well.

Ah, yes. I am digging Sylve quite a bit. Been testing it out lately. Pretty spiffy.

the other drives in the pool are all correct, it's just taking one out of the pool and futzing with it, then trying to put it back (long story, but I prefer all my drives in a small array to be bootable, Sylve does not).

so: buy new smasnug 870 (for $200! - last one was half that), pop it in, do the "I'm just trying Sylve, let's see if I can do a drive swap without leaving the web UI" and while that worked, it also just used the entire disk.

If it's supposed to be a bootable array, all drives in it should absolutely be bootable.

So that new drive is in, working, but not what I want.

ek: i never had set up an efi partition, i didn't notice that until i updated to 15.1

Is it possible this is some kind of bug in 15.1?

I'll create a VM with 15.1 and add a secondary, identical "disk" and see if I can reproduce this.

So I figure I'll fix up da2 (the drive I was originally replacing) with an identical partition layout (hence the gpart backup/restore of da0), swap it back in the array, fix up da4, swap that in, and then I have my new drive in the pool with partitioning that matches the two others (this is raidz-1).

this isn't in production or anything, really just wanted to get the hell off vmware for home use - all my vmdks and configs are backed up elsewhere.

Maybe I should see if I can pass da2 as a raw device into a 14.x VM. :)

But yeah, I just accidentally discovered that 6 byte hole when checking my results of the gpart restore against da0 and da1.

I gotta run, but definitely checking back in when I come back...

i am installing FreeBSD on an old laptop to learn and experiment with. i read the differences between ZFS and UFS and think UFS is best for my use case. am i correct?

Probably.

Both will work fine, but if you have under 2GB of RAM, ZFS is more poorly-behaved.

ZFS benefits on a single disk system are few. Go with UFS

I see no point in using ZFS unless you're essentially doing software raid on a machine with multiple of the same sized hard drives.

thanks everyone. that is what i thought

compression? clones? error detection?

I use ZFS on my single-disk laptop where I dual boot with Linux (which I'm currently in because I had a breakup with FreeBSD at the edge, again)

Yeah, the rule of thumb for ZFS is 1 GB per TB of raw disk space, on top of what you're OS & applications require.

I heard that was only for deduplication

s/you\'re/your

+1 for deduplication only

and that the minimum RAM was 2GB otherwise

CrtxReavr: that rule of thumb applies to deduplication

you can use zfs with 512MB of RAM for the system, but that requires a bit of tuning, not sure about between 512MB and 2GB

Probably overkill, but I run zfs on two single-disk pools and third pool of two external drives (mirrored). Makes it quite nice if I ever want snapshots or to move to a new disk relative to UFS

Haha. Of course dvl already ran into the "3.0K before efi free" thingy: dan.langille.org/2025/11/20/gpart-b…ot-alway-give-you-exact-replication

Yes. Yes, I did. I'm there for you.

Slight typo in the article title

dvl: As always!

With the last mention of the "What gives?", did you ever get an answer?

What is the actual explanation for this?

ek: What brought you there?

dnp1: And the correction?

ek: I think the PR is the only explanation I got.

always not alway

fixed. thanks.

dvl: Not sure how far back your buffer goes, but spork_css was here earlier asking about the same thing and rtprio said he saw the same thing.

huh

All mine match on my EFI systems so I started to poke around. Spun up a VM and then added a secondary disk to gpart restored it and also saw the same thing.

[Jun 29 14:31] <spork_css> yet da2 for some reason has an extra empty 6 bytes in front of the EFI partition.

So, a quick online search pointed me to your page, of course.

Yep. That same 6 bytes (3.0K) free buffer in from of EFI partition. Very strange.

But, if I do a fresh install and mirror the disks then, they are the same. So, this is definitely a gpart backup/restore thing.

And, it's fine, I guess. Everything still works. Just weird to not see an actual mirrored partition table.

Kinda throws you off.

dvl: Sorry, got distratcted, but see you found it.

re: ZFS I run a number of VPS' that have 512MB and zfs and I have zero issues. I'd also hate to have a laptop where I have to wait on a lengthy fsck if it gets an unceremonious shutdown...

I think that there's a lot of very old ZFS info floating around the internet (I did run it as far back as 8.x and, yes RAM was an issue then).

So the folks in charge say this bug in gpart isn't a bug to worry about is that the gist?

I don't like that because I feel like one of the most basic troubleshooting tools I have, esp. when wandering into something new is "comparing two things" and a tool that in some part of that comparison shows me they are not the same when they are... kind of hate that.

spork_css: So, it's basically done on purpose. cgit.freebsd.org/src/commit/sys/geo…f72f47ea5315e5147185e47c2efca2e8c85

If you wiped da0 and restored from da2, they would then match with the 3K free before the EFI partition.

So, I think what will need to happen is whatever gpart is doing when restoring needs to be done during the initial install as well.

Not sure why that isn't the case right now.

ek: that comment on the commit leaves me more confused, it sounds like they opt to *not* maintain the 512B/4K boundary which seems odd.

Anyhow, I'll nuke it and then do partitions by hand one-by-one to see if that works correctly.

spork_css: Yeah. That's what it sounds like to me.

I'm quite certain a manual partition will work just fine.

that backup/restore thing has been my go-to method whenever I add more drives to an array. :(

I don't know who runs this site, but this page is nice - I never really touched EFI ("UEFI" now I guess?) and the handbook just never mentions how to create that - this kind of reminds me of a (now) outdated page from wblock that brought all the disk partitioning stuff together in one place: freebsdsoftware.org/blog/freebsd-disk-management.html

Even the most recent server haul, which I think was 2023-ish, all the supermicro boxes we bought obviously fully support UEFI, but I just stuck with old-timey BIOS as I didn't have the time to poke at UEFI (most importantly recovery should something go wrong).

Kind of amazed that in 2026 we still gotta deal with FAT32, and on *nix machines no less! :)

i don't think we'll ever not deal with it

efi is here to stay

i didn't add primary user to wheel group. useradd command doesn't seem to exist. logged in as root

to wheel group at install*

sorry usermod*

`pw usermod`

`man pw` for more info. no, idk why it's not split up.

you can also yolo and add your username after `wheel:*:0:root,glenny` in /etc/group

thanks

rtprio: oh yeah, I know - I also had the misfortune of running some old IBM servers from the early days of EFI and the pre-boot time in EFI mode was like 10 minutes to the OS boot start (BIOS mode was a bit more normal), so I just kind of figured "I'll get back to this one day when this is less crazy". :)

i was frustrated as i had several practice installs in efi mode / bios mode and bios settings on my new to me r730

this old Dell R-720 I'm experimenting on though is about 3:30 pre-boot in either mode, so I guess boot time isn't an excuse.

because several combos didn't work

oh yes, those lifecycle controllers, whatever they do, are slow as balls

Although that whole "EFI firmware crashes" thing from the other day is very annoying - and it leaves that sort of open question of "if the EFI firmware is crashing all the time, isn't something wrong somewhere?".

I've been meaning to google the "Lifecycle Controller" bit because I suspect it does nothing for me, esp. for a home lab server and I noticed somewhere in the bios setup there's an option to disable it.

ek: lol, rofl even... bpa.st/LZWQ

spork_css: something looks not quite right

I'm guessing working off the "gpart backup" is my mistake (I hope).

i don't know why but at boot the system is connecting to some other wifi network

funny part is that doing a "gpart backup" on da0 and da2 with the above results spits out a *matching* backup. So yeah, I guess it's just fuzzying things up...

glenny1: I'm just futzing around here, so I'll shut up while you work through an actual problem. :)

the /etc/wpa_supplicant.conf is configured correctly as well

spork_css: sorry :(

no, no - I'm apologizing to you!

ok, the interface went down...did ifconfig interfancename up and now it is connected properly...

i don't think i did anything and the problem corrected itself???

i still get an error message at boot but it's connecting to the correct wifi now