<energizer>
i have this problem: at boot, the screen is visible only if it's plugged in over DVI and not HDMI. After boot, I can plug in HDMI and it works. But that means I have to keep a DVI monitor around just to plug it in at boot and unplug it afterwards.
<energizer>
(i need to see the screen to know if i typed the boot password correctly)
madjar has quit [Quit: Connection closed for inactivity]
<__monty__>
Formerly ring?
cole-h_ is now known as cole-h
<infinisil>
__monty__: Indeed
<__monty__>
Ok, cool.
julm has joined #nixos-chat
spudly has joined #nixos-chat
infinisil-t has quit [Quit: infinisil-t]
__Sander__ has quit [Quit: Konversation terminated!]
spudly has quit [Ping timeout: 264 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
adamt has quit [Quit: Connection closed for inactivity]
xd1le has quit [Remote host closed the connection]
xd1le has joined #nixos-chat
<ldlework>
SSHFS protip, when it freezes up and things start to hang; kill ssh, not sshfs and you'll be able to fusermount -u it
<__monty__>
ldlework: And this is faster?
<ldlework>
Hmm, not sure what you mean faster. But my problem has been that I was killing sshfs, and this would randomly allow me to fusermount -u or not (with device busy errors)
<ldlework>
Killing SSH has proven 100% reliable to allow fusermount -u after with no device busy errors
spudly has joined #nixos-chat
cole-h has quit [Ping timeout: 264 seconds]
tokudan has quit [Remote host closed the connection]
__monty__ has quit [Quit: leaving]
tokudan has joined #nixos-chat
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-chat
<colemickens>
Does anyone have a one-liner available for booting an AWS aarch64 instance? The last time I tried booting the latest AMI I flatly wasn't able to SSH.
<samueldr>
hmm, anyone would know a trick to tie the hardware status of something to a systemd service status?
<samueldr>
or maybe not a systemd service, but something that has similar ergonomics
<infinisil>
samueldr: How about a *.target unit
<samueldr>
I don't know, I'll read on them
<infinisil>
Those are just on/off switches afaik
<infinisil>
Not tied to any program
<infinisil>
So you can switch that on/off when the hardware changes, and tie a service to the *.target with some PartOf or so
<samueldr>
"when the hardware changes" is probably what I don't know
<samueldr>
"ugh", I've never really groked udev and it seems to be one of the most cargo-culted bit in Linux these days
<samueldr>
and it's so hard to debug
<samueldr>
but what would udev do here?
<infinisil>
`udevadm monitor` shows you events
<infinisil>
And it can do all kinds of things based on these events
<infinisil>
Which is described with udev rules
<samueldr>
sure
<infinisil>
udevadm also has some other useful commands
<samueldr>
though every time I've had to debug udev rules it's been so hard to actually know if what I'm writing is even used
<infinisil>
You could for example [de]activate a systemd unit when some device connects
<samueldr>
hmm, though my main issue here is that I want to make it ergonomic for the user to enable or disable the modem
<samueldr>
it's not like the user will plug it or unplug it
<samueldr>
it's part of the hardware already
<infinisil>
Hm I see
<samueldr>
(playing around with udevadm and the stuff at the same time I write here)
<samueldr>
as a *consequence* of powering it on through sysfs there are devices that show up
<infinisil>
I mean if it's just controlling the hardware, then wouldn't a systemd service that just enables it when starting, and disables it when stopping again, work?
<infinisil>
So like just an ExecStart and ExecStop
<samueldr>
I think my main hangup is that the service could be desynced from the hardware's actual state
<samueldr>
the modem could be powered off from outside of the service
<infinisil>
I see
<samueldr>
but the service would still be "up", no?
<infinisil>
Yeah
<samueldr>
(see, I'm also unsure of what I actually want!)
<infinisil>
samueldr: How about this: A .target unit for indicating the state, which is controlled with: A .service for starting it manually, a .service for stopping it manually, and an udev rule that mirrors any changes to the .target
<samueldr>
I guess that'll depend on if udev can see the powered state change, or if the hardware paths it gives are reliable indications for the state
<samueldr>
but that's possibly good
<samueldr>
oh, but that's two services... kind of not great
<samueldr>
does it need to be a systemd service? I guess it's better if you want to interact with other systemd-aware things
<samueldr>
(that's more of a rubber ducking question)
<infinisil>
Yeah, doesn't have to be, but maybe better if it is
<samueldr>
I guess the question really is "can we have programmatic status?" on a service
<samueldr>
which looks like it's no, that's for targets
<infinisil>
Yea
<samueldr>
is there a thing we can interact with to "ask for" a target status?
<infinisil>
systemctl is-<TAB>
<samueldr>
e.g. systemctl disable some.target # would somehow bubble up to calling whatever is desired
<infinisil>
Oh
<infinisil>
Ah you can use all the Wants,Requires,PartOf,etc.
<infinisil>
Maybe BindsTo is the right thing here
<infinisil>
Oh yeah then you won't need two services for manual calling
<infinisil>
And can just use the target itself
<infinisil>
Although, then you can't distinguish between udev enabling the target and the user doing it manually
<infinisil>
So e.g. udev enables it with a rule, which then triggers the service to enable it, which hopefully doesn't trigger udev again, or else you have an infinite loop
<samueldr>
the good thing here is the kernel driver isn't bad; echo 1 > to ask to power on, echo 0 > to ask to power down
<samueldr>
>> And can just use the target itself
<samueldr>
the target can have start and stop commands?
<infinisil>
samueldr: No, but it can have a BindsTo=some.service, which then has start/stop commands
<samueldr>
right, I was confused by "then you won't need two services for manual calling", but I guess it's because that can be handled by one service
<infinisil>
(not sure if BindsTo is right, but something like that)
<infinisil>
Hm yeah
<infinisil>
Also, there's RefuseManualStart=, RefuseManualStop= which may be useful
<samueldr>
though here the service would be the interface the user would genrally use to trigger powering on/off
<samueldr>
so I don't think I want to refuse :)
<samueldr>
the main problem I had in mind was that the modem could be powered off through other means, so it would be odd to see the service's status saying it's running while it's not
<samueldr>
but reading BindsTo, if I can make a target that follows the actual state of the modem everything should be fine