<{^_^}>
nix#2356 (by cumber, 38 weeks ago, open): nix-shell in second #! line only accepts double quotes for package expressions
<qyliss^work>
gets me every time
init_6 has quit []
dhess has joined #nixos-dev
<dhess>
I have some questinos about how NixOS EC2 images are created, is this the place to ask? Or should I ask this in #nixos?
<gchristensen>
this is fine
<dhess>
hi gchristensen :)
orivej has joined #nixos-dev
<gchristensen>
hey :)
<dhess>
ok so I'm trying to build my own AMIs. I basically just cribbed the config.system.build.amazonImage bit from nixos/maintainers/scripts/ec2/amazon-image.nix
<dhess>
and I can produce a .vhd file
<dhess>
just minor changes from the NixOS image at this point, mostly just a user for me with my ssh key and a password
<dhess>
couple of config defaults.
<dhess>
anyway I tried to use packer to upload the vhd to EC2, since that looks like it'll handle all the various phases
<dhess>
I basically skip the packer build phase so it just makes a copy of the vhd, doesn't modify it in any way
<dhess>
and then use the post-processors phase to upload the vhd
<dhess>
it gets to S3 just fine. When the vmimport phase starts, it fails with this status message: "StatusMessage": "ClientError: Unable to find an etc directory with fstab.",
<dhess>
now I thought the vhd file was a working NixOS image so it should have /etc/fstab etc. No?
<gchristensen>
I would think so
<dhess>
the NixOS create-amis.sh script uses the old ec2-* AWS SDK, or rather it looks like it uses a mix of aws-cli and ec2-*
<dhess>
any idea why?
<gchristensen>
hmm I wonder if those commansd did something magic
<dhess>
I've used a hacked-up version of that script before but I'm trying to make something that's a bit more automatable
<dhess>
gchristensen: yeah it appears there are some subtle differences in how EC2's official VM import process works and the way that ec2-* SDK works
<dhess>
I used to have some notes on this back when I uploaded my own AMI last summer, but I can't find them now
<gchristensen>
I lost some hours to madness trying to "clean up" that script
<dhess>
yeah no doubt
<dhess>
iohk has a simplified version of it, but it's not clear to me that it works anymore. They appear to have removed support for building AMIs from their iohk-ops tool
<gchristensen>
hmm
<dhess>
so as far as I can tell, nothing in their iohk-ops tree actually uses it anymore.
<gchristensen>
(relatedly, I used to want to teach nixops how to make AMIs)
<dhess>
do they have an irc channel somewhere?
<dhess>
oh please do
<dhess>
oh "used to"
<dhess>
yeah hehehe
<gchristensen>
dhess: (I mean, I Still do, but I no longer have delusions of it being on my to-do list :))
<dhess>
hehe
<gchristensen>
tbh let's ping clever and he can probabl yhelp
<dhess>
huh weird. I finally got guestmount to work and it says there's no OS on the vhd image
<gchristensen>
O.o
<dhess>
well it's wrong. that was the inspector saying that
<dhess>
I just mounted it
<dhess>
ok so /etc/fstab is a symlink to /etc/static/fstab which is a symlink to /nix/store/....fstab
<dhess>
so there is an fstab, but it's a series of symlinks. I guess that's confusing EC2's vmimport?
<gchristensen>
:/
<dhess>
I wonder if maybe the old ec2-* SDK doesn't use vmimport and it doesn't have this problem
<gchristensen>
I suspect that might be true
<dhess>
sigh
<dhess>
This is why we don't use proprietary tools, isn't it? :)
<gchristensen>
I was just thinking how close minded are they thinking you need an fstab at all :)
<dhess>
hehehe
<dhess>
I wonder if there's a way to tell vmimport just to skip all the checks and just assume that the image works
<gchristensen>
doens't the old stuff just directly make a ebs vol?
<dhess>
yes it does!
<dhess>
ok so I created the stock NixOS EC2 image. Its fstab has the exact same store hash as my image's.
<dhess>
so there doesn't appear to be any issue with the way I'm creating the image
<dhess>
this just looks like something that's not compatible with vmimport
<gchristensen>
nice
<gchristensen>
do you mind doing osme research?
<dhess>
I'll try to use packer to import the stock image just to be sure. But I expect it to fail the same way.
<gchristensen>
for example, trying it where /etc/fstab is a one-hop symlin?
<dhess>
I don't mind at all, I would love to make this work
<gchristensen>
one of NixOS's users pays AWS a lot of money, we might be able to have them run it up the chain
<dhess>
even better could we just copy /nix/store/...fstab to /etc/fstab?
<gchristensen>
that would be a good test
<dhess>
it's only temporary until the next rebuild after all
<gchristensen>
:P
<dhess>
so is there any easy way to do that when the image is created?
<gchristensen>
ehhh not sure
<dhess>
or I guess I could just make a copy of the image and modify it using guestfs
<dhess>
right?
<gchristensen>
for this type of experimenting, personally, I would just hand-jam it
<dhess>
"hand-jam" that's a new one to me :)
<dhess>
ok let me see
<gchristensen>
ah hehe I picked that up at Tumblr I guess
pie_ has quit [Remote host closed the connection]
<Shados>
finagle it :)
<gchristensen>
ok, back in about 15min
pie_ has joined #nixos-dev
<dhess>
ok I hacked /etc/fstab in the vhd image so that it's a real file now
<dhess>
I'll try uploading this again
<dhess>
oh my, I *think* it made it past the point where it broke last time
<gchristensen>
nice
<dhess>
the snapshot status is "complete" and now it's "updating"
<gchristensen>
what change did you make?
orivej has quit [Ping timeout: 245 seconds]
<dhess>
only to make /etc/fstab a real file
<dhess>
soooooo sloooooooowwwwwwww
<dhess>
it seems stuck at 41% "progress" but it hasn't died yet :)
<dhess>
ugh, still stuck at 41%. Can't help thinking something is broken.
drakonis1 has joined #nixos-dev
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 248 seconds]
kgz has quit [Quit: WeeChat 2.3]
kragniz has joined #nixos-dev
kragniz is now known as kgz
<dhess>
clever: around?
orivej has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.4]
JosW has joined #nixos-dev
JosW has quit [Client Quit]
drakonis_ has joined #nixos-dev
drakonis has quit [Ping timeout: 246 seconds]
drakonis_ has quit [Ping timeout: 252 seconds]
<dhess>
ugh, do the ec2-* utilities not work with IAM roles?
<dhess>
oh looks like you need to specify the STS token explicitly in that case
<dhess>
so that Packer image import is still stuck on 41% and has been for about 4 hours. Looks like that's a dead end for now.
MichaelRaskin has joined #nixos-dev
<MichaelRaskin>
Another week, another iteration of marking package-specific user notes in Nixpkgs as a separate thing from package development notes
<Synthetica>
grahamc: Would it possible to add a crosscompile job in ofborg/hydra? In my brief time using cross-compiled software, there seem to be a lot of broken packages that fly under the radar because they aren't systematically checked (or should I open an issue about that?)
<gchristensen>
Synthetica: in what direction would cross compilation be wanted?
<gchristensen>
like, what target system?
<Synthetica>
gchristensen: in my case, pkgsCross.raspberryPi, but I think if one crosscompile "leg" works, you can at least be fairly certain the rest would also be okay
<gchristensen>
interesting
<gchristensen>
how does it typically fail? at build time, or at evaluation time?
<Synthetica>
Mostly at build time, for example when things that should be in `nativeBuildInputs` are in `buildInputs`
<samueldr>
aarch64 to x86_64, for sanity checks might uncover a bunch of issues too I suppose
* gchristensen
wishes he could take a month off and work on secret projects
<Synthetica>
gchristensen: Don't we all
<samueldr>
though, other than added load, adding a more encompassing jobset to hydra might be a good first step; no CI on ofborg builds, but at least failures could be identified I guess?
<samueldr>
(thinking out loud mainly)
<gchristensen>
yeah, I think a strategic decision on _what_ we build is in order
<gchristensen>
what is the highest value host/target platform to pick
<MichaelRaskin>
Hm, maybe this deserves an RFC. Or an edit suggestion to an RFC currently under discussion…
<gchristensen>
I think yes
<gchristensen>
it is extremely related to the supported platform RFC
* Synthetica
looks up that RFC
<samueldr>
egoistically speaking, there is always a background noise with armv6 and armv7 going on due to them being relatively popular cheap platforms; it would help with regards to bootstrapping them
<samueldr>
I'm willing to bet a good chunk of builds not targetting the same CPU families are for arm 32 bit
<samueldr>
(though I'm sure alternative libc and other compilers are big targets too)
<MichaelRaskin>
Other compilers maybe not
<samueldr>
well, I meant "what's popular to use in the cross-compiler infra"
<gchristensen>
for the record though I'm too tired from waking up very early, and meeting whiplash to make decisions today
<MichaelRaskin>
32-bit ARM, in addition to cheap platforms, also has midrange phones
<MichaelRaskin>
I am not sure builds for different compilers or different libc behave quite like cross-build
<gchristensen>
last night I half implemented r13y's reporting code to be a nix config file's diff-hook program ... tobo: finish
<samueldr>
MichaelRaskin: which is why I was egoistically speaking :), mobile-nixos would benefit greatly in a greater ease of use for those "now useless" phones
<MichaelRaskin>
Hey what do you mean now useless, the only problem with my Huawei Y6 (~100€ at the time of purchase) is that its battery life is only almost acceptable, and buying another one didn't help much
<MichaelRaskin>
I mean, the phones have completely stagnated five years ago anyway.
<gchristensen>
so did desktops ...
<gchristensen>
samueldr: I feel the mobile-nixos project does change the equation a bit
<samueldr>
MichaelRaskin: those quotes around "now useless" were se heavy the fibers sagged under their weight :)
<samueldr>
MichaelRaskin: because the "now useless" part is mostly (imo) about how software support isn't there from OEMs, but they are still wholly useful and working!
<samueldr>
and your Y6 should be aarch64 from what I can see
<MichaelRaskin>
Next you will tell me software support from OEM is useful
<samueldr>
in an ideal world it would
<MichaelRaskin>
samueldr: you understand nothing in Y6's!
<samueldr>
(though some OEMs do ship 32 bits android userlands/kernels on 64 bits cpus... thinking about motorola here)
<MichaelRaskin>
There is at least Y6, Y6 II, and Y6 2016 (I think)
<samueldr>
yeah, just saw when you said "understand nothing"
<MichaelRaskin>
Y6 2016 obviously is marketed as Y6 nowadays
<samueldr>
makes it easy to find information /s
<MichaelRaskin>
I have an old Y6
<MichaelRaskin>
Well, it was back from the days when unlocking Huawei bootloader was just waiting a couple of days for their laggy site to send an emai;
<samueldr>
oof yeah, snapdragon 210, Cortex-A7; that needs some 32 bit :)
<samueldr>
right, huawei sits in the corner of shame; with North American LGs, and some other OEMs
<MichaelRaskin>
I think that corner of shame currently contains approximately all the vendors? I guess the largest ones _not_ in the corner of shame are Asus and Xiaomi?
<samueldr>
Google still ship unlockable; I'm not entirely sure what's up with Samsung
<samueldr>
Xiaomi does have that 15 days wait period though
<samueldr>
Asus will void your warranty by pinging with the mothership
<samueldr>
(though it legally cannot void warranties in most regions)
<MichaelRaskin>
Exactly
<samueldr>
though, unlocking with Asus also removes you from the pool for updates
<samueldr>
you will need to download and update manually
<samueldr>
which... might not be a bad thing
<MichaelRaskin>
Exactly
* samueldr
had to type faster than you
<samueldr>
IIRC motorola is mostly fine, at least with the hands-me-down I just had it went swminingly
<MichaelRaskin>
In the ideal world support from OEM _is_ useless because mainline drivers sort of work well enough
<MichaelRaskin>
Motorola is just Lenovo now, right?
<samueldr>
not sure if they'Re "just" lenovo, at one point they were still independent for smarphones things
<samueldr>
though, I would put a big warning mark on any OEM requiring server interactions, so that leaves... only Google :/
<samueldr>
(unsure about Samsung)
<samueldr>
because, eh, what happens if/when the server either just bugs out, or they remove support for older devices, or the business folds?
<MichaelRaskin>
Well, as what I care about is Lineage from day <30, and I believe Asus to keep the course for the next 60 days more than I believe Google not to change something on 24h notice…
<MichaelRaskin>
Bootloader unlock is one-time thing
<samueldr>
yeah, though in a _project_ like mobile-nixos, targetting those that can still be unlocked in an unknown future is better
<samueldr>
but you're right, once unlocked it becomes a non-issue for that user
<samueldr>
and yeah, I also hold a great opinion of Asus for that; they also are relatively timely with source release
<gchristensen>
does mobile nixos have a channel yetL
<gchristensen>
?
<samueldr>
nope
<MichaelRaskin>
If Asus folds you can as well give up on computing
<samueldr>
(though I see how we're intruding on mostly off-topic in -dev :))
<gchristensen>
that was not a prod
<samueldr>
though Asus could decide to close off their smartphone brand, including removing those unlock servers :/
<gchristensen>
that was an opportunity for you to pitch a channel for future involvement :P I'm sure I'm not the only one excited to mainline NixOS in to their
<gchristensen>
phones
<samueldr>
right now I want to peruse the existing channels, mostly because e.g. aarch64 things are #nixos-aarch64 relevant, and others should be relatively relevant to nixos development; going away in a channel with only a few individuals wouldn't be as useful *at this moment* :)
<gchristensen>
+1
<samueldr>
MichaelRaskin: I gather you handle the lineageos porting yourself to what you buy? if so, neat
<MichaelRaskin>
Nope, I just research what has acceptable unofficial ports
<MichaelRaskin>
I am no good at debugging drivers for undocumented peripherals
<MichaelRaskin>
Well, having a small quiet channel early is sometimes useful
<MichaelRaskin>
I wonder how much of NixOS can function on a system with only root account
<MichaelRaskin>
I also wonder what is the easiest non-systemd-bound container system to run NixOS containers
<MichaelRaskin>
(These are related questions — the real question is whether it is feasible to run single-machine NixOS tests inside Nix builds in containers)
<gchristensen>
interesting
<MichaelRaskin>
It looks like lxc wants to do a lot of things at once. runC?
<gchristensen>
I don't suppose we can't trick systemd to run in a build
<MichaelRaskin>
Well, we can unshare and make it PID1 inside and we don't need root for that (using NixOS kernel with user namespaces)
v0|d has joined #nixos-dev
pxc has joined #nixos-dev
callahad has quit [Quit: Ping timeout (120 seconds)]
callahad has joined #nixos-dev
Synthetica has quit [Quit: Connection closed for inactivity]
drakonis has quit [Ping timeout: 255 seconds]
justanotheruser has joined #nixos-dev
drakonis has joined #nixos-dev
drakonis_ has joined #nixos-dev
<worldofpeace>
:( somehow I'm not a "Great contributor" on discourse. what gives 😅