The small linux problem thread

Are you running as root?

You shouldn’t ever run your browser as root, but if you are, you need the --no-sandbox flag.

Nope. If I run it from cli it gives a longer warning about user namespaces being disabled.

welp.

That’s odd.

1 Like

Ah, it appears to be a feature of the “hardened” kernel in Arch. Booted into normal linux and it doesn’t happen. I’ll go ahead and re-enable the namespace thing and if more stuff gets in my way, maybe switch back to normal kernel.

Based on my Googling, this appears to happen in stock Debian also.

I guess I read your post and the error message wrong. Still seems suspect to me but I am running vanilla Arch and Debian SID, so I am running normal defaults.

1 Like

Oh sorry, I said I installed Brave when I should have said I ran brave. The warning about the sandbox flag actually appears in the browser when it opens in the hardened kernel. I think it’s worded badly. I never typed the --no-sandbox.

Ah. yeah that makes a lot more sense to me.

1 Like

Just tried it and same thing unfortunately :expressionless:

1 Like

I’ve added a password to grub in Arch, but I only want it to protect against editing grub options, not selecting and booting into menu items. I’d like to achieve this in /etc/default/grub or in a custom config file in /etc/grub.d (prefer not to edit package-provided conf in grub.d).

I already set my user/password in a custom conf /etc/grub.d/01_users, and I can achieve the desired result by doing this in that same file, but it is a very hacky solution:

echo 'menuentry_id_option="--unrestricted ${menuentry_id_option}"'
echo 'export menuentry_id_option'

menuentry_id_option is for something else, but I can shim --unrestricted into it to make that a default flag for menu entries. AFAIK, I can only set kernel parameters in /etc/default/grub and not menuentry flags.

Is there a better way to do this that I’ve overlooked?

I’m working in AwesomeWM and I’m having some scaling issues. It appears that there are 3 separate scaling levels in effect.

  1. The Awesome top panel and menus are very tiny. What you’d expect for 8 or even 6pt.

  2. Browsers are fine. They’re what I’d expect.

  3. Alacritty and the cursor are huge. Alacritty is set to 13.5pt font and it looks like 24pt.

I know that Alacritty uses /etc/fonts config, and I suspect that Awesome is using Xorg settings, but issuing xrandr --dpi commands doesn’t make any difference.

I think if the AwesomeWM elements were doubled in size and Alacritty/Cursor were halved, everything would match.

Did you test this variable?

I know it is solution for i3wm but sometimes theses workarounds work in other WM’s too. And from my experience a lot of dwm stuff applies in Awesome as well.

2 Likes

Is there any way to tell Grub2’s grub-install where it should look for /boot? It’s trying to load it from the wrong location (my / filesystem,which is separate from /boot, and then not even from the raid device either) and I can’t for the life of me figure out how to configure in the braindead thing where it should go looking for its boot configuration.

The reason why I’m fairly confident it’s just looking in the wrong location is because I get dumped into a grub > prompt, which indicates Grub can’t find its config file, and that typing configfile (md/0)/boot/grub/grub.conf loads Grub’s menu fine (and then proceeds to boot the system perfectly fine as well)

If nothing else I’m going to guess Grub’s nomenclature is such that I just can’t find what I’m looking for because it’s not called what I expect it to be.

I tried setting GRUB_ROOT_UUID in /etc/default/grub but that appears to not do anything (though honestly I figured that would be related to the kernel’s root= option rather than Grub itself, but who knows…)

One thing that might be relevant is that I was migrating stuff (will do writeup when/if I can get this working) so the raid array is currently in degraded state:

Personalities : [raid1]
md125 : active (auto-read-only) raid1 sdb5[1]
      994944 blocks super 1.2 [2/1] [_U]

md126 : active raid1 sdb3[1]
      311191488 blocks super 1.2 [2/1] [_U]
      bitmap: 3/3 pages [12KB], 65536KB chunk

md127 : active raid1 sdb2[1]
      247936 blocks super 1.2 [2/1] [_U]

unused devices: <none>

Still, that might mess with the auto-detect scripts, but I figure I should still just be able to tell it where to look…

Can you use grub-mkconfig -o /boot/grub/grub.cfg Instead?

What distro is it?

You shouldnt need to set root in default/grub

2 Likes

Oh boy, thanks a lot! I was so busy digging into details (you really don’t want to know which rabbit holes I’ve been down the past two days :wink: ) that I hadn’t even considered the configuration file name could have been wrong! I’m going to go hang my head in shame now :frowning:

Going to assume it was me who messed up and just assumed they wouldn’t have changed the config file name (this machine used to boot with legacy grub)…

Ugh, I really hate bootloaders, they’re finicky and none of them produce decent errors :frowning:

EDIT: oh yes, and it’s a rather old Gentoo install :wink:

1 Like

These days grub-install has a –boot-directory option. With UEFI on Ubuntu I can hack it by editing /boot/efi/EFI/ubuntu/grub.cfg (but in April 2018 that didn’t work).

Afraid that might not have helped, as this is a good old BIOS booting box :wink:
Similar things are possible with BIOS, but they require building a custom core.img and that really seemed a bit “out there” for what used to be an extremely common, and often recommended, use-case…

As for why BIOS, well I think Grub 0.9 possibly didn’t support EFI, or the machine I initially installed it on didn’t, it’s been a while…

# head -n1 /var/log/emerge.log
1283424997: Started emerge on: Sep 02, 2010 10:56:37

10 years, apparently. The underlying hardware has changed, but the install has just moved with it, and there wasn’t really any reason to mess with things that weren’t broken…

1 Like

Oh yeah, I’ve been there. Spent forever working through bootloader config just a week and a half ago.

Wow, 10 year-old Gentoo install. Don’t see that often…

Cursor fixed! Ty


Alacritty fixed!

1 Like

So I mentioned that I was unable to use vmware-player a while ago, and I still seem to be having the same issue.
I thought it was maybe some updates that were still pending, but it doesn’t seem to be the case. vmware-player opens, but upon powering on the VM, it just shows that the VM isn’t powered on for a split-second (no shit?), and then just closes. I don’t know what I’m doing wrong here tbh…

are you launching vmware-player from the console? any output? Might it have any error logs at all?

Can it run VM’s of non-windows systems?