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
@oO.o honestly i don’t care i just want to get this thing figured
1 Like
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.
Are you running as root?
You shouldn’t ever run your browser as root, but if you are, you need the --no-sandbox flag.