<samueldr>
>> This can also be configured at boot with "random.trust_cpu=on/off".
<samueldr>
gchristensen: ^ probably preferable
<gchristensen>
yeah, giving that a go
<gchristensen>
thanks!
<gchristensen>
looking at dmesg for related words and comparing messages + grep solves so many things
<samueldr>
whenever I encounter a kernel config I don't know, cateee is the place I go first
<gchristensen>
oh cool
<samueldr>
the data is indexed with versioning
dmj` has joined #nixos-dev
<samueldr>
and if it's defined multiple times (e.g. once per arch) they're shown that way
<gchristensen>
might be worth comparing the ubuntu aws kernel config to their default config and see if we should crib some defaults
<samueldr>
do we want to maintain diverging kernel configurations?
<samueldr>
but yes if it's universal enough
<gchristensen>
probably not, but some of those options might happily become kernel config options like random.trust_cpu
<samueldr>
and that's a real question
<samueldr>
yeah
<gchristensen>
but also, maybe we do
<samueldr>
I think we do, but we can't at the maintainer scale we are at
<gchristensen>
yeah
<gchristensen>
agreed
<samueldr>
we'd have to have maintainers on a pay roll [any pay roll] doing that
<samueldr>
where their day job is maintaining cloud images, and only that
<gchristensen>
tell me about it
* gchristensen
looks at the 6mo old request from packet to update support
<samueldr>
what's a missed version release?
<gchristensen>
or 2
<samueldr>
:x
<gchristensen>
part of that was their fault
<gchristensen>
but yeah
<gchristensen>
it is hard to test images on a dozen types of hardware, when each image is unique to the hardware and each test takes ~1h and a given hardware name might have subtle differences across actual sleds of hardware
<samueldr>
*and* you can't touch it at all
<gchristensen>
yup
<samueldr>
not that it really helps most of the time
<gchristensen>
and it was slow to roll out updated installers, so the pressure was extremely high to deliver as-good-as-possible images from the start
<gchristensen>
booted at :11, ...aaand whoops my new AMI didn't have the kernel option set.
<samueldr>
oh
<gchristensen>
turns out you can't just put kernel parameters into the list of kernel modules.
<samueldr>
ugh, and it's not an error because it's lenient for compatibility across different kernel versions
<samueldr>
successfully square peg in a round hole there
<gchristensen>
:)
<gchristensen>
well, I'll start the AMI upload and test it tomorrow. I don't want to be up another 30min.
<samueldr>
30 minutes test cycle? ew
<gchristensen>
2 minutse to build the AMI, uploading the 1.4GiB AMI at 2.5MiB/s upload rate + about 10-15 minutes for AWS to "import" it + 30s to 15 minutes boot time
<samueldr>
that's what I figured, minus the import
<gchristensen>
:) good night! let's see what this gets us in the morning
red[evilred] has quit [Quit: Idle timeout reached: 10800s]
zarel has quit [Ping timeout: 256 seconds]
maljub01 has quit [Ping timeout: 256 seconds]
maljub01 has joined #nixos-dev
zarel has joined #nixos-dev
maljub01 has quit [Client Quit]
maljub01 has joined #nixos-dev
ashkitten has quit [Quit: WeeChat 2.9]
ashkitten has joined #nixos-dev
andi- has quit [Remote host closed the connection]
<{^_^}>
Mic92/nixpkgs-review#142 (by SuperSandro2000, 1 day ago, open): Add platform run on to report
<Mic92>
supersandro2000: Thanks. I will take this to the weekend. This evening I am on Nix Friday, which I prepared this morning
<gchristensen>
I'm running resize2fs with -d62 to get timing information from the offline resize to see if there is something obvious
<supersandro2000>
Mic92: I will remind you again in a few days.
<Mic92>
gchristensen: are you aware of off-cpu- flamegraphs?
<gchristensen>
yeah, but I haven't tried too hard to implement it since it is so early in boot. samueld\r mentioned it'd probably be easy to save the data but I wasn't feeling up to figuring that out yesterday. I can try that today
<Mic92>
bcc has this very nice tool called offcputime, which can be fed into brendan greggs flamegraphs.
<Mic92>
ok
<gchristensen>
strace on resize2fs in stage1 going to the console was a bad idea though :)
<Mic92>
yeah, maybe log to tmpfs
__monty__ has joined #nixos-dev
<gchristensen>
the test cycle is a punishing 30min, so not keen on doing things which have tricky bits
<Mic92>
gchristensen: it is not reproducible locally?
<gchristensen>
I didn't think to try. It only happens during early boot, and up until now I was still thinking maybe some kernel + hypervisor things were getting in the way.
<gchristensen>
next :)
<gchristensen>
(good thing I have a system nearby with 5T free ... )
<Mic92>
So doing non-online resize in a later boot stage is faster?
<gchristensen>
yup
<gchristensen>
iirc. let me double check.
<Mic92>
Really weird. From a kernel perspective, once you start calling init, it's already quite late from a kernel perspective.
<gchristensen>
yeah, that and a nearby "crng init done" message is what took me down the rng road
<gchristensen>
but that doesn't appear to be related
<Mic92>
I still see the non-online vs online resizement as the biggest difference. Once the kernel initialized virtio-blk it should work the same the whole time.
<gchristensen>
[Fri Oct 30 11:21:09 UTC 2020] adjust_superblock: Memory used: 396k/4556k (295k/102k), time: 654.21/ 0.59/ 5.13
<Mic92>
gchristensen: things I miss in nixos-rebuild: nixos-rebuild kexec and nixos-rebuild boot-once
<Mic92>
using systemctl kexec and bootctl set-oneshot
<gchristensen>
oh gosh me too
<gchristensen>
confirmed: time resize2fs -d 62 /dev/xvdf2 (xvdf2 is a 5T disk from the exact same snapshot which took 12 minutes to expand) took 37s when the system is fulling running, but xvdf2 is unmounted
<delroth>
gchristensen: not immediately, sorry (on my work laptop right now). do you strongly prefer a PR for cherry-picks in general? (I'm assuming so it goes through CI)
<gchristensen>
yeah
<delroth>
opening two PRs is kind of annoying and time consuming
<delroth>
I really wish ofborg had an option for simple stuff like this to run tests against master + 20.09
<delroth>
(and maybe automate the cherry-pick! :P)
<gchristensen>
me too
<delroth>
maybe one day I'll figure out how to do a local ofborg setup and see how hard that would be to implement.
<Mic92>
gchristensen: so the issue is that it tries to zero everything manually?
<gchristensen>
Mic92: as far as I can see, it initializes the entire inode table if the ext4 kernel module isn't loaded
costrouc has joined #nixos-dev
<Mic92>
gchristensen: but the inode table should not increase if you are not adding inodes, no? Is it not rather that it uses efficient block discard if ext4 is loaded rather than writing zeros to disk?
<gchristensen>
not sure
* gchristensen
splunks
<Mic92>
FALLOC_FL_ZERO_RANGE
<Mic92>
this allocates zero bytes
<Mic92>
*writes zero bytes
<Mic92>
anyway modprobing ext4 should be an easy fix.
<gchristensen>
yeah, testing that now
<gchristensen>
(I mean, I did test it locally and it fixed it. checking it in an AMI now)
justanotheruser has joined #nixos-dev
alp_ has quit [Ping timeout: 264 seconds]
alp_ has joined #nixos-dev
<gchristensen>
resize started: DATEMARK: Fri Oct 30 14:59:58 UTC 2020, resize finished: DATEMARK: Fri Oct 30 15:00:55 UTC 2020
saschagrunert has quit [Quit: Leaving]
cole-h has joined #nixos-dev
justanotheruser has quit [Ping timeout: 268 seconds]
justanotheruser has joined #nixos-dev
jonringer has joined #nixos-dev
<cole-h>
gchristensen: "zfs create -V 3G rpool/scratch/ext4" and "mkfs.ext4 /dev/zvol/rpool/scratch/ext4"...
<cole-h>
Wait that's illegal
<gchristensen>
lol
<gchristensen>
I also have zvols for windows and macos ...
<cole-h>
I can't swear at you for that -- I do have a Windows zvol for my VM :P
<{^_^}>
#102174 (by grahamc, 33 minutes ago, open): AMI root partition table: use GPT to support >2T partitions
<gchristensen>
launched: 13:09, ready: 13:11... not as fast as Amazon Linux, but a good start
<gchristensen>
probably moving to a systemd init would get us closer
alp_ has quit [Ping timeout: 264 seconds]
alp_ has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-dev
<ajs124>
is there any documentation/policy on how to properly remove a package from nixpkgs? e.g. if and when a throw should be added to aliases.nix
<supersandro2000>
generally when it was in for a bit of time and people might actually use it
<supersandro2000>
if you added it last week to master and now rename or remove it, it should be fine
<samueldr>
ajs124: do you hate your users?
<samueldr>
ajs124: if so just remove the attribute and don't speak about it :)
<samueldr>
ajs124: otherwise add a throw stating quickly why it was removed and maybe a path forward
<samueldr>
e.g. another tool _actually_ replaces it
<ajs124>
samueldr: the software basically cannot have worked since 2017
<samueldr>
if you know that our packaging of it is broken for long, then doing it without a throw is good, IF you state the why clearly enough in the commit message
<ajs124>
it's not that out package is broken, it still builds fine. it's just that the software can't work, because… ok, so the specific case here is skype call recorder. it talked to the old native skype linux client. that client cannot connect to the skype network anymore and hasn't been able to for a long time. so you can still install the software, it just doesn't do anything.
<samueldr>
haha, then acceptable too I figure
<ajs124>
so the policy is "use your best judgement"? ^^
<samueldr>
it is, but really, think about the children^W users first
<samueldr>
breaking a config without a message is terrible, for things that are expected to be in use some
<ajs124>
yeah. I guess I'll add one, just in case
<samueldr>
though in your specific case, yes, you're back to using judgement :)
<cole-h>
If you add a throw, please, please, please put the attr in the message
<ajs124>
the other reason I'm asking is, because aliases seems to not have any kind of deprecation policy
<samueldr>
it really can go either way
<samueldr>
that is true, and not great either
<samueldr>
but not terrible still
orivej has joined #nixos-dev
alp_ has quit [Ping timeout: 240 seconds]
alp_ has joined #nixos-dev
teto1 has quit [Quit: WeeChat 2.9]
alp_ has quit [Ping timeout: 264 seconds]
<gchristensen>
samueldr: I was also surprised that parted was outputting 1049kb and considered the partitions aligned
<samueldr>
:/
ris has joined #nixos-dev
<gchristensen>
samueldr: I don't want to merge that until you're happy about it
<gchristensen>
b/c I'm not going to pretend I'm competent there
<samueldr>
I mean, if parted says it's 1049KB, maybe add [sic] after it :)
<samueldr>
even using `1049kB` exactly as parted says
<cole-h>
Or even "(yes, 1049K)"
<samueldr>
sic: used in brackets after a copied or quoted word that appears odd or erroneous to show that the word is quoted exactly as it stands in the original
<gchristensen>
it sounds like you're comfortable with the value, and not feeling like we should look in to that weirdness further?
<samueldr>
I really assumed you typo'd 1048
<samueldr>
9 and 8 are so close together
<gchristensen>
yeah I know, but since I didn't -- should we look closer at what is happening?
<samueldr>
let me try
<gchristensen>
to be honest I'm surprised we're not looking at 4k blocks or something here
<samueldr>
we know it is 2048 sectors; parted is just being weird imo
<gchristensen>
yeah
<gchristensen>
I pushed an updated set of commits
<supersandro2000>
I wrote a quick and dirty function around nix-build which hightlights if a package build has no python tests, but pytest was run anyway
<supersandro2000>
theoretically you can highlight anything with that
<supersandro2000>
hopefully someone finds this useful
<gchristensen>
neat!
<supersandro2000>
and if Mic thinks this is a great idea I would like to integrate that into nixpkgs-review
<gchristensen>
samueldr: mind issuing a second review?
alp_ has joined #nixos-dev
<gchristensen>
these will be some nice PRs to merge and backport. I like being able to boot machines in a nice amount of time
<samueldr>
I'm surprised no one noticed before
<gchristensen>
the MBR issue: someone else did mention it :) and the resize issue: probably not a lot of people spinning up machines with 5T root disks
<samueldr>
still, I would assume it took some host minutes on smaller drives too?
<samueldr>
some hot minutes*
<gchristensen>
yeah
<gchristensen>
but 12min for 5000GB... 100g worth of slowness is maybe just "thats weird... where's the coffee?" time
<gchristensen>
the thing that actually made me look in to it was resize2fs took 9 hours
<eyJhb>
I.. I really want to place the damn -unstable in a way that makes sense. And there is no standard on this...
<eyJhb>
I am a sad panda atm.
<samueldr>
gchristensen: hours?
<samueldr>
eyJhb: I *really* think that it should be neither in version or pname, though, which is a conundrum!
<gchristensen>
samueldr: yes
<samueldr>
hmmmm
<samueldr>
some kind of variant suffix?
<samueldr>
meta.variant = "unstable"; or even for e.g. chrome meta.variant = "beta" and meta.variant = "dev"
<eyJhb>
For now, I will put it into version, as -unstable :| Who wants to create a RFC for this?! :p
<samueldr>
eyJhb: version as unstable-xx-yy-zz you mean?
<gchristensen>
does the version number need to be last in the string for nix-env to consider it an upgarde?
<samueldr>
yes
<eyJhb>
samueldr: as "yyyy-mm-dd-unstable"
<eyJhb>
Fuck
<eyJhb>
THen I guess the other way around!
* samueldr
opens the manual to double-check
<eyJhb>
I just wanted to give you guys among-sus :(
<samueldr>
>> If a package is not a release but a commit from a repository, then the version part of the name must be the date of that (fetched) commit. The date must be in "YYYY-MM-DD" format. Also append "unstable" to the name - e.g., "pkgname-unstable-2014-09-23".
<samueldr>
the main gist of it is: unstable has to be between the "useful pname" and the "useful version"
<eyJhb>
samueldr: so it goes into the name? among-sus-unstable ?
<worldofpeace>
lol, this is the most debated section of the manual ever
<supersandro2000>
can't we fail a build if the unstable is at the wrong end?
<samueldr>
according the what is written currently in the manual
<eyJhb>
I was about to ping you worldofpeace , help
<worldofpeace>
I can find the thread about it
<samueldr>
but yes, as I said previously, I believe already it should be in neither
<gchristensen>
clever: I don't suppose you're 'round?
<worldofpeace>
I'd recommend that we should try to make x and x better by requesting to upstream, but if it's really minor it can be handled outside of adding the package. only if it's a really big problem for adding a new package to nixpkgs, meaning it's not a great port, I'd hold up the thread
<gchristensen>
eyJhb: lol.
<etu>
eyJhb: One could... have a fetchFromSrHt that is just a wrapper for fetchgit until it's fixed
<eyJhb>
True
<eyJhb>
*sigh* when will I have time, just to play with Nix all the time
<eyJhb>
Hell, a lot of our fetch do not support submodules
<drakonis>
is there a nickel irc channel yet?
<gchristensen>
nickel is just an experimental tweag thing, isn't it?
<drakonis>
currently i suppose
<worldofpeace>
eyJhb: merged
<worldofpeace>
opening issues, but I have to make an account
<eyJhb>
Did you change your display name or something worldofpeace ? And thanks! :D
<drakonis>
maybe a bit too soon to want it?
<worldofpeace>
eyJhb: did I?
<eyJhb>
WORLDofPEACE
<eyJhb>
Thought it was all caps/lowercase
<worldofpeace>
oh, since a while ago I now do it stylized
<worldofpeace>
because I keep cute and stylish
<eyJhb>
Also.. Is it just me, or does it seem weird that 3 out of 4 services matches the same sha256, but the fourth does not?
<gchristensen>
this very well might be a "duh" but it surprised me a bit. I wonder if there is a way to safen this up, or something
<gchristensen>
it also included files not committed or staged in any way
<clever>
i think all of the installer iso's also do that
<roberth>
gchristensen: I don't think we can prevent people from putting creds in scripts, but we can write our scripts to load secrets from dotfiles for example
<roberth>
flakes approach of only adding staged-ish files prevent this either
<gchristensen>
yeao
<roberth>
don't prevent I mean XD
<supersandro2000>
If I am reviewing PRs quickly after they are being created I often get strange build errors which I can never reproduce
<supersandro2000>
Do I need to turn down some TTLs?