This is my Config as per Wendells Tut (4-nmve, one lvm)
The error states:
failed to connect to lvmetad
volume group not found
can you show what the pvs
pvdisplay
and journalctl error messages?
Yes, what is the best method to pull the info? In the livecd or initramfs?
I have a similar issue (only after rebooting though). Look what the levels are in alsamixer. The issue I have is that the āHeadphoneā channel there is reset to 0 everytime I boot. Maybe youāre having the same issue (see here).
Also:
There is no standard, it depends on the specific audio chip used.
Luckily VyOS is adding monthly snapshots soon that are semi-tested to be stable, also you can build the LTS image yourself and itās incredibly easy to do via a Docker image meant specifically for building VyOS https://docs.vyos.io/en/latest/contributing/build-vyos.html
1 Like
Oh thatās awesome, thanks. I donāt mind a little risk but nightlies, no way.
Anyone know how to load a LUKS key-file into systemd-boot? Iāve done it with grub before but want to try the systemd method.
User@Computer:~$ sudo pvdisplay
ā Physical volume ā
PV Name /dev/md0
VG Name Aorus_vg
PV Size 1.86 TiB / not usable 2.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 487816
Free PE 434056
Allocated PE 53760
PV UUID ----- LONG UUID -------
User@Computer:~$ sudo vgdisplay
ā Volume group ā
VG Name Aorus_vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 7
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 3
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 1.86 TiB
PE Size 4.00 MiB
Total PE 487816
Alloc PE / Size 53760 / 210.00 GiB
Free PE / Size 434056 / <1.66 TiB
VG UUID ----- LONG UUID -------
i donāt know enough to retrieve the journalctl error messages
1 Like
@LPoettering
dumb joke, sorry
journalctl -p 3 -xb
That will show errors. Be careful about posting all of it here in case thereās something sensitive in there.
Also, the joke was about journalctl being opaque and kind of terrible, not about you being unfamiliar with it.
1 Like
Trying to wrap my head around systemd-boot in a mixed mdadm/luks/lvm system. I saw āsystemd-boot can decrypt luksv2ā and thought, āgreat, thatās better than grubā but I think I misunderstood.
What I think now is that systemd-boot can decrypt luksv2 but it basically needs everything that would normally be in /boot (initramfs, vmlinuz, etc) to be in the esp. You can specify that it use /boot for this outside of the esp, but /boot cannot be encrypted in that case. So it seems like encryption-wise, youāre still better off with grub and luksv1 /boot.
Is that correct? Does anyone here use systemd-boot with encryption?
Ah yeah, here it is.
I guess secureboot prevents tampering with the boot image which is really what you want when you encrypt /boot. initramfs isnāt full of secrets, you just donāt want it to be altered. So I think I will go that route, as I as excited to not use grubā¦
Arch actually recommends just mounting the esp as /boot
- mount ESP to
/boot. This is the preferred method when directly booting an EFISTUB kernel from UEFI or booting it via a boot manager like systemd-boot.
But I can also designate boot separately from the esp with bootctl so I think Iāll try that.
Anyone ever notice yes always exiting code 141?
$ yes | read -s foo
$ echo ${pipestatus[@]}
141 0
$ echo $foo
y
$ yes | true
$ echo ${pipestatus[@]}
141 0
$ yes | false
$ echo ${pipestatus[@]}
141 1
Note that each one involves a pipe.
Notice from kill -l that SIGPIPE is signal 13. And note that 128 + 13 is 141.
Any exit code higher than 127 is a signal exit instead of a normal exit.
2 Likes
That makes sense, but Iām surprised thatās how yes works. Using it guarantees a pipefail unless Iām missing something.
This is my shim for it:
... || [ "${pipestatus[2]}" = '0' ]
I have a one-shot systemd service that I want to run (and complete) before any login prompt appears. I assumed that one would achieve this with Wantedby=getty.target but getty.target indicates the successful start of the getty service which will start regardless of other getty.target dependencies. The next target down the critical-chain is network.target, but that seems like a hacky way to delay the login prompt (although it is working as Iād like).
Here is the unit file using network.target.
[Unit]
Description=First Boot Configuration
After=sysinit.target
[Service]
Type=oneshot
ExecStart=/usr/local/bin/first-boot
TimeoutSec=600
[Install]
WantedBy=network.target
I guess I could use the actual getty service, but it may not always be on tty1, so Iām not sure that can be done reliably. Also, Iād like to prevent ssh login as well, which of course, using network.target does accomplish, so maybe it is the way to go.
I guess Iām wondering if thereās a ābest practiceā here that Iām unaware of, or a different approach in the unit file.
This has probably been explored a bunch of times already but does anyone have a hot tip to get HD playback working for Netflix on Linux? Iām using Vivaldi, which identifies as Chrome (i.e. no Vivaldi in the user agent - and yes Netflix still appears to use that).
Iām getting a maximum of 540p out of itā¦ I know 1080p is not officially supported on Linux, but 720p is and Iām not even getting that and Iām wondering what Iām doing wrong. Itās not the throughput (Netflix debug overlay shows anywhere between 40mbit and 80mbit).
Widevine is available as per the guide here:
I know there was the Netflix-1080p extension once but that isnāt maintained and doesnāt work anymore. Switching user agent manually in the developer tools yields a variety of error messages. But honestly thatās not even what Iām after, Iād just like to get the supported resolution 
edit: actually thereās a couple forks, but even the most up to date ones donāt work for me.
1 Like
@mihawk90 Can you try it on Firefox? Just to see if itās isolated to Vivaldi?
I also have a browser question.
I installed Brave and it says:
You are using an unsupported command-line flag: --no-sandbox. Stability and security will suffer.
After some digging, the solution appears to be:
sudo sysctl kernel.unprivileged_userns_clone=1
But that apparently that:
opens up severe vulnerabilities in the Linux kernel
But on the other hand:
such a setting doesnāt even exist in the mainline Linux kernel
and
if a user can
sudoto root (as would be required to turn this off), they can already do everything that this would let them do.
Soā¦ I definitely want to use Brave. Which one of these things is less bad (no sandbox or unprivileged user namespace)? I am leaning toward setting the kernel parameter.
I am sure that you can turn off the no sandbox feature with a command line argument. Why would you not want to sandbox your browser? FireFox and Chrome sandbox by default.
I think the issue is it cannot sandbox without that kernel setting, so you have to choose one or the other.