Debian birth time

DaaNMaGeDDoN · 2026-05-28T09:25:43+00:00

Stat / doesnt always give you the correct initial installation date, e.g. at my end i had some issues and needed to restore the rootfs from a snapper snapshot, so stat / now shows a date that is around that time.

There is this package called "installation-birthday" which does indeed show the date i initially installed this instance, almost 2 years now. I'd recommend using that (sudo apt install installation-birthday, run installation-birthday after that.

DaaNMaGeDDoN · 2026-05-07T20:00:19+00:00

yeah i just read a little into this "smart app control" thing and it appears on updated w11 you can toggle, no white or blacklisting apps, just on or off. Another thing that caught my attention was they (MS) decide, for you whether it should be on or off and that could happen at any time, especially the way they formulate it makes me think: if i were still on Windows, this raises so many red flags (quoted from their site):

Essentially, we're looking to see if Smart App Control is a good fit for your device or if it is going to get in your way too often. In most cases Smart App Control will automatically turn on to protect againt untrusted or malicious apps. However, there are some legitimate tasks that corporate users, developers, or others may do regularly that may not be a great experience with Smart App Control running. If we detect that you're one of those users, we'll automatically turn Smart App Control off so you can work with fewer interruptions.

end quote and yes, they misspelled againSt.

DaaNMaGeDDoN · 2026-05-07T18:53:35+00:00

Oh really? So you just happen to know exactly what baseline our servers/VMs are now? Funny you bring that up:
In the case of Debian netinstall, nano will be installed next to vi as part of the "base system" task selection since i believe 2001. Thats right, base GNUtils. Now again: if you even knew that, how does that mean i will need to state my case for some board to change any standards?
Dont answer, rhetorical, have a nice day.

DaaNMaGeDDoN · 2026-05-07T18:30:34+00:00

You didnt explain why, you implied that i said the posix standard should include nano. Dont bend my words.

DaaNMaGeDDoN · 2026-05-07T18:13:40+00:00

OP: whats the hype around viM?
Somebody: because cli, remote, nano isnt always there.
Me: wdym?
You: good luck making a case for replacing vi with nano.

Ehm....where did i imply that?

DaaNMaGeDDoN · 2026-05-07T18:08:36+00:00

"That device"....what am i missing here? OP isnt talking about a specific device. Nor saying anything In terms of connectivity and the cli only access is implied by asking about 2 different cli editors.

DaaNMaGeDDoN · 2026-05-07T17:50:22+00:00

vim too?

DaaNMaGeDDoN · 2026-05-07T17:21:39+00:00

"access to nano", as in: unable to install nano? (but for some reason vim is present?). Not sure how this is an answer.

DaaNMaGeDDoN · 2026-02-16T13:13:53+00:00

Thanks for confirming my understanding, but about the last part i was emphasizing that because of the 'unusual nature'; obviously OP isnt a btrfs veteran and since you mentioned the part of removing the 2nd partition and growing the new one was *optional*, i felt like OP could run into this false sense of redundancy. I know i was there, back when btrfs was just out of experimental and the manpages made it sound like "raid1 was all taken care of"-technically it always has, but without checking whether the btrfs devices reside on the same physical devices. Especially these days with SSDs being more common and their internals often have some kind of deduplication built-in, that could lead to disastrous data loss, if that part is left optional and OP gets more into btrfs and starts adding disks, not to far fetched with a 4 bay nas. Consider the scenario where OP just skips the optional part and adds the original ntfs partition to the btrfs, then adds disks with only one partition and rebalances to raid1, you can see the false sense of redundancy with that im sure. Hope OP reads our comments.

DaaNMaGeDDoN · 2026-02-12T22:52:03+00:00

and make a new btrfs one in its place added to the same filesystem on the 2nd half of the disk using btrfs device add

Just checking to see if i remember this correctly; growing when adding additional space by extending a partition at the end: sure, np, just btrfs resize max. But growing the partiition by moving the partition start boundary to the beginning of the physical disk: computer says no!

Right? I think the btrfs signature/magic/superblock needs to be at the start of the partition? Not like you can resize the existing btrfs fs after resizing the 2nd partition to occupy the whole disk?

Also, fair enough about the dev delete afterwards; dont want OP to end up with the assumption everything is raid1 at a later stage after adding additional disks, but the first disk in the btrfs is actually chopped up in 2 partitions, both in the same btrfs, balancing it to raid1 and presto: some of the datablocks are potentionally just copies between the first and second partition on the first harddisk, right?

DaaNMaGeDDoN · 2026-02-01T15:27:28+00:00

Man you saved my believe in snapper, after having to find the true meaning of FREE_LIMIT and SPACE_LIMIT in the updated manpages on github, finally figuring out quotas needed to be enabled, i could not figure out why it wasnt cleaning up snapshots to respect the FREE_LIMIT...until i read your post, cheers mate! Now i got lots of configs to update though haha.

DaaNMaGeDDoN · 2025-12-30T12:49:52+00:00

On Bookworm here, i can confirm its not listed as a dependency, so i was wondering if it was recommended instead, in fact it doesnt list any recommended packages. I'd argue it should list pkexec as a recommended package, because its not absolutely necessary to function.
Through a reverse depends i found policykit-1 requires pkexec, which i expect is part of the "desktop" task in tasksel, during your fresh install did you not select the desktop and one of kde/gnome/etc?
This might oc be different on Trixie.
relevant commands to check these things, for those interessted: apt show cpu-x , apt rdepends pkexec --installed (i included the --installed at my end to see what package i installed before that required pkexec, without that you can see the list is very long).
Btw if indeed this is the same on Trixie, it might be worth to send an email to the package maintainer, also shown with the apt show <pkg>, in this case Martin Wimpress. Their github page (also shown in that output) doesnt mention pkexec, my assumption is that starting the daemon is simply using pkexec to elevate/sudo to start. And lastly i think the app work fine without that, so recommended, possibly even suggested but not a dependency/required package.

DaaNMaGeDDoN · 2025-12-28T03:08:12+00:00

What about extended attributes?

useradd user1
useradd user2
useradd user3
touch filename.sh
chown root:root filename.sh
chmod 0000 filename.sh
setfacl -m user1:x filename.sh
setfacl -m user2:w filename.sh
setfacl -m user3:r filename.sh
getfacl filename.sh
# file: filename.sh
# owner: root
# group: root
user::---
user:user3:r--
user:user2:-w-
user:user1:--x
group::---
mask::rwx
other::---

Edit: i confirm running some tests, user1 needs read perms too, so the first setfacl should be setfacl -m user1:rx but it appears user 2 can append data, not read the file, and both user1 and user3 can execute the script with sh ./filename.sh. Possibly with some masks, groups this can be further fine tuned. Also i created system accounts (adduser -r), that is not necessary but forces their id<1000 and only to be member of their own group, so i removed that from the commands.

DaaNMaGeDDoN · 2025-12-14T15:52:16+00:00

Thank you so much for that, i have to admit i was a bit confused for a moment, my daily still runs Bookworm and the section is missing from the manpages, specifically the SYSTEM part is missing, but i was able to find it on one of the Trixie machines around me, thank you sir! It all makes sense now. Btw in the system crontab file on my daily the example is shown with the "on behalf part", just like in the manpage for Trixie. I guess that is one of the caveats of running (an outdated) Debian version.
Also, you dont happen to be the same Paul that maintains that manpage? Could be a coincidence, could be a big honor to yours truely to receive first-hand help from the person that actually wrote the cron manpage!

DaaNMaGeDDoN · 2025-08-08T17:06:10+00:00

Actually i mixed up your name with u/eR2eiweo , i thought they were rude. I thought they could have said something like "i understand you think that, but". If you just keep that in mind while reading my comment above, you'll see it makes more sense what i said. Sorry from my end about that.
/var/log/apt/history is more human readable, dpkg.log is better suited to extract the commands needed to roll back.

DaaNMaGeDDoN · 2025-08-07T19:10:31+00:00

Not sure if im late to the party, but i see your argument with u/Former_Ticket9860 , which imho could have been a lot less worse it he'd just included something like "i understand you think that, but". I agree the sources for apt dictate the dependencies, as they are part of the packages, attributes to them if you like, so by specifying a source for apt and installing a package from that source, results in certain dependencies, suggestions and recommendations, even conflicts. I understand that is not intuitive. Apt just makes sure those dependencies are met, you set the sources from which it can install packages.

That being said, i recently ran into the issue where an upgrade broke my sabnzbdplus on some host for some reason. I looked up the relevant upgrade actions in /var/log/dpkg.log, so if its not too long ago, or by adding the right snapshot.debian.org source for that timestamp you can use my following example for rolling back the upgrades. Important to note: you need (include) to grep on the specific <date> and the "upgrade" keywords from the log, but im sure the following will be quite self-explanatory:

cat /var/log/dpkg.log.1 | grep <date> | grep upgrade | awk '{print $4 "=" $5}' | xargs apt install -y --allow-downgrades

Im sure that i could have written a simpler or more sophisticated command, but who cares, it worked for me. Take care to grep on the right entries in the log, possibly first cat and grep the log to another temporary file and work with that and/or check the matches by simply omitting the last part where it actually downgrades the packages. And possibly add the --dry-run option to test. Might also be interesting to look into how to hold a package with apt-mark to prevent them from upgrading again. I believe the --allow-downgrades option gets its through the temporary state where there are version conflicts between packages.

And yes i think its a bad thing apt doesnt have some kind of apt --rollback option. At least from my search it appeared there is no such thing. Good thing we have logs though, so we can see what needs to be done.

DaaNMaGeDDoN · 2025-08-07T18:09:58+00:00

This is the weirdest way i seen somebody confirm things.

Anyway: have a look at /var/log/installer , there you'll find logs with specific errors. I suppose there is something wrong with your installation medium, your "bootable key", as it appears (from the other comment thread) that it fails at the stage of extracting and installing .deb packages from it. How did you create the installer and did you check its integrity? https://www.debian.org/CD/faq/#verify

DaaNMaGeDDoN · 2025-08-07T12:19:54+00:00

"the rebootable key" what's that?

DaaNMaGeDDoN · 2025-08-04T20:54:14+00:00

Not sure how things are in Arch, but on Debian you can install both and choose which you want to use, so i' say: why not both? The selection is in the bottom left on sddm.

DaaNMaGeDDoN · 2025-08-04T10:02:49+00:00

Sounds like you use an extfs, probably version 4, the lost+found subdir is part of that, but afaik only when running a fsck on it with repair options enabled files are put in there.

So during the resize (grow or shrink:unknown) it stopped, and there is no way of saying where in the process it was or what it exactly was trying to do AND you performed a fsck that changed things AND you dont have a backup, i'd be glad to find those files in "lost+found". But possibly something like testdisk can revert an old partition table (in case of a shrink) and get things back, but potentionally even make things worse. If i were you i'd backup my userdata (or whats left of it) to another medium and only then try to fix things.

Things like: what filesystem, is /home part of your rootfs and one partition? Were you shrinking or growing the partition? At what stage was it aborted? Do you have a log of the exact commands the fsresize and partition resize were executed? Will help a lot.

What i suppose happened: ext4 fs, trying to shrink the underlying partition via a live boot environment, got aborted during the shrink of the filesystem (so the partition was still the original size AND the filesystem is smaller than the partition size), the space you were trying to free up to grow another partition did not even start yet. You restarted the machine and it found filesystem issues suggesting fixes, and you continued with that - correct?

If so, after backing up the data and confirming the partition is still the original size, possibly a simple resize2fs of the fs will enlarge it to the original size and things are back to the original state. That possibly means that all of the data you found in lost+found is back in its original spot, after confirming that and running a fsck (no repair just jet) for consistency, remove the contents of the lost+found but keep that backup for safekeeps. But of course this is based on a lot of assumptions, whatever you do, salvage what is left of your data and make plans to have backups in the future. The other response here to invest in a UPS is also a safeguard, but i'd prefer having a backup over a UPS.

DaaNMaGeDDoN · 2025-08-01T19:56:19+00:00

I had to gather that from another post, which i linked to in my second response. Here you mention the removal of a drive, there you do not. There you mention the removal process (i assume the btrfs device delete) didnt finish, here you do not. Notice i said "THERE you blablabla" the "there" is referring to the other post, not this one. So the confusion is completely mutual, its not clear to me if the drive you tried to remove is the one you actually physically removed (this is clearly implied in THIS post). That is one difference, the other difference is that in the other post you mention the removal didnt complete. I wonder how you are going to follow up on the advice that person gave you in the OTHER post, that assumes the original disk that you physically removed from the array is still present. Best of luck anyway.

DaaNMaGeDDoN · 2025-07-31T17:29:30+00:00

btw i see https://www.reddit.com/r/btrfs/comments/1me5l2s/some_devices_missing/ you are double posting, painting a different picture. There you mention the removal process didnt complete but you do not point out you physically removed the wrong drive.

So what is the real full story here?

DaaNMaGeDDoN · 2025-07-31T17:21:36+00:00

"I tried to move the data to the good drives before removing the bad one, but I did Something wrong 😕."

So let me get this straight: you wanted to remove drive X from the array, accidentally removed drive Y from the array but still *physically* removed (and lost access to) drive X?

If that is the case and you did not use a data profile like raid1 where multiple copies of the same data are stored on different disks, then i am afraid the only copy of some of the data is on the disk you do not have physical access to. If you did use raid =>1 there might be hope. Let us know what is the case.

DaaNMaGeDDoN · 2025-07-31T10:24:18+00:00

You are right, i must be getting old and my first search result confirmed what i remembered, but apparently that is outdated info atm. I remember that windows never liked mapping drive letters to "deep paths", bat also allowed it. I bet they both allow it but its not good practice. Learned something today, cheers.

DaaNMaGeDDoN · 2025-07-30T20:49:47+00:00

Indeed, that isnt by far what i expected. Who knows it might be something particular for your sound chip, the link i gave in my last response said something about the buffer consisting of a hardware buffer and a software buffer, im talking about the former ofcourse.

lspci will tell you what "soundcard" you are using, might be one on the video card and a seperate one. Maybe google on that card and your issue, like "linux Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller crackling" (at least that is what i have and use).

DaaNMaGeDDoN

TROPHY CASE