How does that differ though? When I do #!/bin/env sh it’ll just find the same symlink going to bash (or whatever on the target system)
1 Like
Good question. I guess if you are doing tests to see what shell is being used, it is more transparent. Today has been a Monday of Mondays so I may just be creating all sorts of hate and discontent
1 Like
Expletive deleted, that hurt just reading it.
1 Like
Except different Unix systems have env in different paths (/usr/bin vs /bin vs /etc), which takes you right back to the same problem of needing to change your shebang when copying scripts to different systems.
3 Likes
Fair. Please disregard my comment. I had nothing constructive to add after all. This systems administrator stuff is really hard today.
some help if i may…
on booting kali from the grub.
i get a black screen with a cursor, then 3 lines of text flash up just before the log in lock screen appears.
something about a missing firmware.
im guessing these pre-boot events get logged?.
but i have no idea where to look or what filename to look for.
so, suggestions please. 
…
which log am i looking for, and if there isnt one, how would i go about creating one.
Have you tried the generic syslog?
This is almost certainly part of a kernel driver which means you should do dmesg - or, on a more modern Linux like Kali, journalctl -k. Might need to be root/sudo. Then you should be able to grep for “firmware”, or pipe to less and then do a standard search (type /while in less).
3 Likes
7.262861] iwlwifi 0000:06:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[ 7.262928] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 7.263004] iwlwifi 0000:06:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
found it with dmseg, THANK YOU!..
sorted. turns out the firmware its asking for isnt a real file iwlwifi.exe.
so the recommended action i found was make a config file.
put it in modprob.d so the message gets suppressed at boot.
@wertigon thanks for the pointer
1 Like
Hey,
I have an (old, returning?) issue with my Ryzen CPU (7600X) getting stuck at low clocks - around 500Mhz.
I’m on Kernel 6.0.12 (-arch1-1).
The CPU is in C3, P13 and stays there, unless I manually intervene (i.e. using cpupower frequency-set).
This is pretty annoying, and I really don’t know anything about how Linux handles this and what could cause it to go wrong.
cpupower frequency-info reports that amd-pstate is the driver (which I think is correct), for idle-info it’s acpi_idle.
It’s not an overheating issue.
Before I yell bug!, does someone have an idea what’s going on?
I have not messed with it yet but the default scheduler is not very good and AMD is transitioning to a use the new kernel schedule with the 6.1.x kernel release. Check out phoronix and and try to use that new scheduler instead.
Finally solved my docker in nspawn issue by setting the following in my nspawn file:
privateUsers=0:65536
PrivateUsersOwnership=chown
1 Like
I ran into an odd issue that seems pretty, well, stupid for lack of a better word. I have a dual-boot Linux & Windows system. I took the Windows drive offline in the BIOS, and booted it up thinking I could go straight into Linux.
Nope. In Linux I get dumped to a maintenance/emergency prompt. I had trouble finding any relevant log entries, but the fix was pretty clear. Since I had the Windows drive set to automount, I figured it was an /etc/fstab problem. Sure enough, commenting out the Windows drive in /etc/fstab allowed the system to boot.
Problem solved, or at least addressed. Now the question I have is why the bleep does taking a Windows drive offline cause Linux to take a dirtnap? There are no critical system files on the drive because, well, it’s an NTFS Windows volume. Any thoughts or comments?
What prompt was that? Busybox? I’d have thought Linux would be running before /etc/fstab gets read.
Like so:
1 Like
Hmm, it may have something to do with the bootflags in /etc/fstab. I had specified something similar to the following to mount the drive in the file:
UUID=[partition-id] /run/media/[username]/WinGames ntfs uid=1000,gid=1000 1 1
I think the 1 flag on the end may have something to do with it; normally it means “fsck this drive first.” Still, I’d think fsck would’ve just moved on after it couldn’t find the drive.
1 Like
1 1 at the end should almost certainly have been 0 0.
/etc/fstab is (was originally) intended for permanently available/connected storage. The storage device is expected to be there from the get-go. It not being there is, therefore, a boot failure. The OS not allowing you to proceed until you have fixed the boot error is an entirely sane and reasonable thing to do. It has no idea at this stage what the device contains, whether or not it has critical files, and whether attempting to proceed with the boot would render your entire system FUBAR. Thus, instead of YOLOing it, you are put in manual control and get to make the decision.
Use the noauto option to not automatically mount the partition at boot time. Then create a simple bash script that you can use to mount it manually when you want/need to.
There’s also a nofail option that lets you suppress (ignore) mount failure errors. Think carefully before you use this.
PS: Why use the BIOS/UEFI to take the Windows drive offline? Why don’t you just not mount it (or unmount it post-boot) and then let it go to sleep?
To add to this - why even have it in the fstab in the first place? Ubuntu, for instance, lists the Windows drive in the file browser and if I doubleclick it, it automounts and spins up.
@level1 @wertigon I took the drive offline in the BIOS because I was attempting to resolve a Windows boot/partition issue. See here: Stupid Windows installer behavior - #12 by imrazor
Taking the drive offline in the BIOS (not UEFI) was a lot easier then disassembling the case and extracting the drive.
Under normal circumstances, I prefer that this drive be automounted due to the presence of a Steam library and the ability to access the files on it when not in Windows is very convenient.
A long, long time ago I learned to add drives to /etc/fstab by copying the other lines in the file, then altering them with the new drive data. Usually those other lines ended in “1 1”, so I blindly copied them. Now I’ve learned the hard way what they do, and won’t repeat that particular mistake.
In this case you should have a third drive for Steam games then 
But sure, I understand why, still automounting foreign drives is nowadays playing with fire - would be better to set up a systemd startup service that mounts the foreign drive. Just some food for thought for the next time 
1 Like
Not to be a smartaleck, but why? I’ve never had a problem with an automounted NTFS drive getting corrupted or other issues…well aside from yesterday’s issue. I seem to recall that ‘fast boot’ in Windows will get a drive marked as dirty and unwriteable, but I’m not aware of other issues. And this system is incapable of fast boot anyway (BIOS, natch.) Typically only games or office programs will touch this drive from Linux.
1 Like