The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

«‹›1023 »

CaptainSarcastic: Jul 6, 2013

I haven't done it in a while, but I've done persistent installs to USB sticks just by doing a normal installation, not having a swap partition, and trimming down the packages installed. Not super speedy, but once the system was up and running and things were in memory it was generally fine, as I recall.

I mean, on older hardware or stuff without a lot of RAM this would be worse, but otherwise is there a problem with the approach?

# ? May 30, 2020 23:24

Adbot: ADBOT LOVES YOU

# ? Apr 16, 2024 07:21

VictualSquid: Feb 29, 2012; Gently enveloping the target with indiscriminate love.

D. Ebdrup posted:

I'm not familiar with NomadBSD, but I imagine anything that qualifies as a persistent image is by its nature bound to run from a USB stick, which is never going to be fast because UFS is probably not the fastest filesystem ever invented.
To paraphrase McKusick who made FFS in BSD in the early 80s and still makes UFS in FreeBSD to this day: if you throw away peoples data once, they don't tend to trust you again.

I think either FuryBSD, GhostBSD, or both(?) use geom_uzip to create a disk-like structure from a zipped file which is mapped into memory with tmpfs? I don't see how you can write that to disk without having to recompress it first, though - and that kinda defeats the point, no?

I feel like writing the ramfs to the stick at shutdown is a reasonable compromise for people like me who are already taking the data loss risk inherent to using the cheapest stick possible.

# ? May 30, 2020 23:28

VictualSquid: Feb 29, 2012; Gently enveloping the target with indiscriminate love.

CaptainSarcastic posted:

I haven't done it in a while, but I've done persistent installs to USB sticks just by doing a normal installation, not having a swap partition, and trimming down the packages installed. Not super speedy, but once the system was up and running and things were in memory it was generally fine, as I recall.

I mean, on older hardware or stuff without a lot of RAM this would be worse, but otherwise is there a problem with the approach?

Nah, I was just researching if there were better/more specialized approaches. And automated ways to run from ramdisk, which at least one of the distros advertised.

# ? May 30, 2020 23:30

ToxicFrog: Apr 26, 2008

VictualSquid posted:

So I went to check out the current state of portable linux:

Most of the distros (slax, MX) expect you to install to usb by running a shellscript that "autodetects" if it should install the bootloader to the usb-stick or your actual harddrive's MBR.
Knoppix hasn't updated their website since the last time I was there. Back when internet was so slow that you tended to order CDs by mail.
And they were exceedingly unclear on if those are persistent installs or if the changes are wiped at reboot.
The only reasonably well documented portabel distro I found was the one, tails.

A lot of distros now have portable usage "built in". E.g. here's how you make a portable openSUSE install:
- download the iso
- dd the iso to a USB stick
- the first time you boot it it'll automatically partition and format the rest of the USB stick for the portable OS
That's it.

If you want something specifically optimized for portability you might want to check out Puppy Linux, but there's less need to special-purpose distros like that these days.

# ? May 30, 2020 23:52

mystes: May 31, 2006

I set up gpu passthrough and it's a little janky right now because it turned the video card that was in my linux computer can't handle anything about 1920x1080 so I had to temporarily allocate the better video card to the host, which means that I can't get looking glass to run at a high enough resolution right now, but it seems like it will work well enough that I'll go with this approach and get a new graphics card.

It was pretty annoying to get everything set up, though, and there are some oddities like for some reason xbox controllers apparently don't seem to like to work via usb redirection, and the usb controllers on my motherboard are all in IOMMU groups with tons of other random stuff so I can't assign them to the VM, but I guess I can just buy a $15 pcie usb card so I don't have to use usb redirection.

# ? May 31, 2020 03:26

Double Punctuation: Dec 30, 2009; Ships were made for sinking;
Whiskey made for drinking;
If we were made of cellophane
We'd all get stinking drunk much faster!

ToxicFrog posted:

A lot of distros now have portable usage "built in". E.g. here's how you make a portable openSUSE install:
- download the iso
- dd the iso to a USB stick
- the first time you boot it it'll automatically partition and format the rest of the USB stick for the portable OS
That's it.

If you want something specifically optimized for portability you might want to check out Puppy Linux, but there's less need to special-purpose distros like that these days.

This is assuming your UEFI is smart enough to boot a UDF image from a USB drive. Doing this is not guaranteed to work on every system.

# ? May 31, 2020 04:43

Mr Shiny Pants: Nov 12, 2012

mystes posted:

I set up gpu passthrough and it's a little janky right now because it turned the video card that was in my linux computer can't handle anything about 1920x1080 so I had to temporarily allocate the better video card to the host, which means that I can't get looking glass to run at a high enough resolution right now, but it seems like it will work well enough that I'll go with this approach and get a new graphics card.

It was pretty annoying to get everything set up, though, and there are some oddities like for some reason xbox controllers apparently don't seem to like to work via usb redirection, and the usb controllers on my motherboard are all in IOMMU groups with tons of other random stuff so I can't assign them to the VM, but I guess I can just buy a $15 pcie usb card so I don't have to use usb redirection.

On my ThreadRipper I just passed through the whole USB controller, including other stuff needed because it is in the same IOMMU group. Some hostbridge and other stuff, you can just pass it through with VFIO.

# ? May 31, 2020 07:34

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

I tried VFIO, got it to work after more than a little troubleshooting and blind "e ctrl-x" grub editing, and realized it was much clunkier than I thought.

What I thought it was: I can use Linux normally, but when I start a VM image I can temporarily give it control of the GPU and its attached monitor, same as any USB device. So I can use Linux all the time, including for most gaming, and fire up a Windows VM only when I want to play a game that won't run on Lutris or a Windows-only application. If I have a secondary screen and GPU, I can keep using Linux on them while Windows is running on the main.

What it apparently is: the main GPU is permanently assigned to the VFIO driver and can ONLY be used from the VM. You can't use the GPU from Linux at all, all your gaming must be via VM. You can't use your main screen outside a VM, not even for booting up, unless you change its input to the secondary GPU (manually or with a hardware HDMI switch). The secondary screen should actually work as intended, although I don't have room for a second screen right now so I couldn't test it.

Have I got this right this time?

# ? May 31, 2020 10:05

BlankSystemDaemon: Mar 13, 2009

VictualSquid posted:

I feel like writing the ramfs to the stick at shutdown is a reasonable compromise for people like me who are already taking the data loss risk inherent to using the cheapest stick possible.

NanoBSD is a system image builder for embedded applications, and it's where geom_uzip was first used. As a result, geom_uzip either uses zlib(3) or lzma(3) via mkuzip(8) to heavily compress images so they take up the least amount of space - it can easily fit the kernel plus wpa_supplicant on a 64MB CF card for an access point, for example.

What you want for a persistent live image is an addition of geom_uzip where it at the very least supports lz4 or or better yet zstd, because these are much faster compression algorithms and the latter is especially suited since it can automatically compress at the highest ratio achievable when writing to a disk - both of these already exist in FreeBSD, so it's just a matter of adding them to geom_uzip. What you also need though, and unfortunately this is more complex, is in-line VM compression so that once time comes to shut down the system, you aren't going to be waiting for the compression to happen before you can write things to disk.

You can't do the thing that Linux does for these kinds of things, because FreeBSD has a unified buffer cache which means every type of buffering, including filesystem, is part of one cache - this is a huge win in terms of controlling the VM, paging, VM laundry, and all sorts of other neat things FreeBSDs VM does as well as preventing the wrong things being OOM'd.
I'm told that people go to great lengths on Linux to avoid OOMs, to the point of Facebook and Google implementing a userspace OOM daemon - something that normally belongs in the kernel - because the Linux OOM mechanisms are completely unreliable and things will just start going wrong as soon as the system starts swapping.

ZFS, interestingly enough, can already do these things. It just won't work with geom_uzip, as far as I can figure out.

BlankSystemDaemon fucked around with this message at 10:43 on May 31, 2020

# ? May 31, 2020 10:25

Computer viking: May 30, 2011; Now with less breakage.

Without knowing too much about the details here, it seems like doing realtime compression on writes is much easier with a copy on write - file system? If you know that every block you write will go into newly found free space instead of having to fit where the old one did, it becomes much easier to handle how compressed blocks have almost arbitrary sizes.

ZFS is a bad fit in other ways - it's not exactly written to be conscious of every single MB of disk or RAM overhead - but it does make inline compression fairly easy. I can't really imagine how you'd bodge it into UFS (or ext4) without a whole new layer of indirection between the FS's view of disk blocks and the actual blocks; almost like the wear levelling magic in an SSD but on the geom side.

# ? May 31, 2020 12:21

Mr Shiny Pants: Nov 12, 2012

NihilCredo posted:

I tried VFIO, got it to work after more than a little troubleshooting and blind "e ctrl-x" grub editing, and realized it was much clunkier than I thought.

What I thought it was: I can use Linux normally, but when I start a VM image I can temporarily give it control of the GPU and its attached monitor, same as any USB device. So I can use Linux all the time, including for most gaming, and fire up a Windows VM only when I want to play a game that won't run on Lutris or a Windows-only application. If I have a secondary screen and GPU, I can keep using Linux on them while Windows is running on the main.

What it apparently is: the main GPU is permanently assigned to the VFIO driver and can ONLY be used from the VM. You can't use the GPU from Linux at all, all your gaming must be via VM. You can't use your main screen outside a VM, not even for booting up, unless you change its input to the secondary GPU (manually or with a hardware HDMI switch). The secondary screen should actually work as intended, although I don't have room for a second screen right now so I couldn't test it.

Have I got this right this time?

What works is to get VFIO to claim the card and after booting use a script to detach or attach a driver. I have two GTX cards and can use one in a VM and also bind the NVidia driver afterwards to use the Cuda cores for rendering in Blender on Linux.

It takes a bit of work, but it does work. You just need X or something else not to claim the card first.

Something like this:

code:

#!/bin/sh
#vfio-pci.ids=10de:1b80,10de:10f0

stop()
{

    echo "Unbinding GPU from VFIO-PCI"
    echo -n 0000:08:00.0 > /sys/bus/pci/drivers/vfio-pci/unbind || echo "Failed to unbind gpu from vfio-pci"
    echo -n 0000:08:00.1 > /sys/bus/pci/drivers/vfio-pci/unbind || echo "Failed to unbind gpu-audio from vfio-pci"
    echo -n 10de 1b80 > /sys/bus/pci/drivers/vfio-pci/remove_id
    echo -n 10de 10f0 > /sys/bus/pci/drivers/vfio-pci/remove_id
    echo "Rescanning PCI bus"
    echo -n 1  > /sys/bus/pci/rescan
    echo "Unloading vfio-pci kernel module"
    modprobe -r vfio-pci
    echo -n 0000:08:00.0 > /sys/bus/pci/drivers/nvidia/bind || echo "Failed to bind nvidia gpu"
    echo -n 0000:08:00.1 > /sys/bus/pci/drivers/snd_hda_intel/bind || echo "Failed to bind nvidia hdmi audi"
}


start()
{
    echo "Binding GPU to VFIO-PCI"
    echo -n "0000:08:00.0" > /sys/bus/pci/drivers/nvidia/unbind || echo "Failed to unbind gpu from nvidia"
    echo -n "0000:08:00.1" > /sys/bus/pci/drivers/snd_hda_intel/unbind || echo "Failed to unbind hdmi audio in gpu"
    modprobe vfio-pci
    echo "Loaded vfio-pci kernel module"
    echo -n "10de 1b80" > /sys/bus/pci/drivers/vfio-pci/new_id
    echo -n "10de 10f0" > /sys/bus/pci/drivers/vfio-pci/new_id
}

echo  

case $1 in
    start|stop) "$1" ;;
esac

Mind you, I do have some problems on kernel 5.4, they seem to have changed some things regarding VFIO. I just boot 5.3.

Mr Shiny Pants fucked around with this message at 12:27 on May 31, 2020

# ? May 31, 2020 12:22

mystes: May 31, 2006

Mr Shiny Pants posted:

On my ThreadRipper I just passed through the whole USB controller, including other stuff needed because it is in the same IOMMU group. Some hostbridge and other stuff, you can just pass it through with VFIO.

My motherboard has two usb controllers but it doesn't seem doable:

code:

IOMMU Group 12 03:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset USB 3.1 xHCI Controller [1022:43bb] (rev 02)
IOMMU Group 12 03:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset SATA Controller [1022:43b7] (rev 02)
IOMMU Group 12 03:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:43b2] (rev 02)
IOMMU Group 12 04:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 04:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 04:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 04:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 04:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 04:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 09:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02)
IOMMU Group 12 0a:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 11)

IOMMU Group 7 00:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B [1022:1454]
IOMMU Group 7 11:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Zeppelin/Raven/Raven2 PCIe Dummy Function [1022:145a]
IOMMU Group 7 11:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Platform Security Processor [1022:1456]
IOMMU Group 7 11:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) USB 3.0 Host Controller [1022:145c]

I actually tried passing through all of Group 7 including the Platform Security Processor but that crashed the computer.

# ? May 31, 2020 12:25

Mr Shiny Pants: Nov 12, 2012

mystes posted:

My motherboard has two usb controllers but it doesn't seem doable:

code:

IOMMU Group 12 03:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset USB 3.1 xHCI Controller [1022:43bb] (rev 02)
IOMMU Group 12 03:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset SATA Controller [1022:43b7] (rev 02)
IOMMU Group 12 03:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:43b2] (rev 02)
IOMMU Group 12 04:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 04:01.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 04:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 04:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 04:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 04:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port [1022:43b4] (rev 02)
IOMMU Group 12 09:00.0 SATA controller [0106]: ASMedia Technology Inc. ASM1062 Serial ATA Controller [1b21:0612] (rev 02)
IOMMU Group 12 0a:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 11)

IOMMU Group 7 00:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B [1022:1454]
IOMMU Group 7 11:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Zeppelin/Raven/Raven2 PCIe Dummy Function [1022:145a]
IOMMU Group 7 11:00.2 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Platform Security Processor [1022:1456]
IOMMU Group 7 11:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) USB 3.0 Host Controller [1022:145c]

I actually tried passing through all of Group 7 including the Platform Security Processor but that crashed the computer.

I seem to have the same stuff passed through, I am not at home but I'll check when I get back. It should work, at least it does on my X399. Try updating firmware? I had some difficulties with IOMMU groups not being populated as they should on my board at first.

Did you create some VFIO config for the PCIe IDs? In my modules directory I have a USB file that says to load the VFIO driver for these IDs. Looking at those groups you should only need the stuff beginning with 11.

Mr Shiny Pants fucked around with this message at 12:35 on May 31, 2020

# ? May 31, 2020 12:30

mystes: May 31, 2006

Mr Shiny Pants posted:

I seem to have the same stuff passed through, I am not at home but I'll check when I get back. It should work, at least it does on my X399. Try updating firmware? I had some difficulties with IOMMU groups not being populated as they should on my board at first.

Did you create some VFIO config for the PCIe IDs? In my modules directory I have a USB file that says to load the VFIO driver for these IDs. Looking at those groups you should only need the stuff beginning with 11.

Upgrading the EFI firmware fixed the IOMMU group issues. Unfortunately apparently the newer version of the firmware for my motherboard also breaks all passthrough and it can't be downgraded. Looks like I can look forward to compiling my own kernel and using a sketchy workaround patch forever!

The other option is to try applying a newer firmware (no idea if it actually fixes it) that they say not to use on older CPUs and risk bricking my system, lol.

mystes fucked around with this message at 13:51 on May 31, 2020

# ? May 31, 2020 13:47

Mr Shiny Pants: Nov 12, 2012

mystes posted:

Upgrading the EFI firmware fixed the IOMMU group issues. Unfortunately apparently the newer version of the firmware for my motherboard also breaks all passthrough and it can't be downgraded. Looks like I can look forward to compiling my own kernel and using a sketchy workaround patch forever!

The other option is to try applying a newer firmware (no idea if it actually fixes it) that they say not to use on older CPUs and risk bricking my system, lol.

Bummer, I was lucky that Asrock seems to take the whole IOMMU stuff seriously on its ThreadRipper boards. At first I also had to compile a custom kernel.

# ? May 31, 2020 16:18

mystes: May 31, 2006

Mr Shiny Pants posted:

Bummer, I was lucky that Asrock seems to take the whole IOMMU stuff seriously on its ThreadRipper boards. At first I also had to compile a custom kernel.

This is also Asrock (although probably fewer people are doing this stuff on older ryzen motherboards with older ryzen cpus) and it apparently is effectively the same as the bug that earlier threadripper firmwares had. It seems like it may be AMD's fault because the software they were providing to oems got worse for older ryzen chips after a certain point, but Asrock not allowing firmware downgrades is also stupid. Probably the later AMD software fixed this specific bug with older cpu's but Asrock isn't recommending using the newest firmwares for older cpus and it might not be bootable so I don't think I can test it safely.

Apparently I might be able to downgrade if i use some obscure ami firmware updater utility that's hard to find, but for now I guess I'll just try the kernel patch because if it works it would be nice to be able to assign the second usb controller to the vm.

Edit: The kernel patch works fine, and it wasn't too much a pain to apply, plus now I can pass one of the usb controllers through, so actually it was probably worth upgrading and applying the patch if it saved me having to buy an pci-e card.

mystes fucked around with this message at 17:49 on May 31, 2020

# ? May 31, 2020 17:19

Mr Shiny Pants: Nov 12, 2012

mystes posted:

This is also Asrock (although probably fewer people are doing this stuff on older ryzen motherboards with older ryzen cpus) and it apparently is effectively the same as the bug that earlier threadripper firmwares had. It seems like it may be AMD's fault because the software they were providing to oems got worse for older ryzen chips after a certain point, but Asrock not allowing firmware downgrades is also stupid. Probably the later AMD software fixed this specific bug with older cpu's but Asrock isn't recommending using the newest firmwares for older cpus and it might not be bootable so I don't think I can test it safely.

Apparently I might be able to downgrade if i use some obscure ami firmware updater utility that's hard to find, but for now I guess I'll just try the kernel patch because if it works it would be nice to be able to assign the second usb controller to the vm.

Edit: The kernel patch works fine, and it wasn't too much a pain to apply, plus now I can pass one of the usb controllers through, so actually it was probably worth upgrading and applying the patch if it saved me having to buy an pci-e card.

The problem I had was a PCIe bus reset error. That went away after kernel 4.2 though.

# ? May 31, 2020 18:12

BlankSystemDaemon: Mar 13, 2009

Computer viking posted:

Without knowing too much about the details here, it seems like doing realtime compression on writes is much easier with a copy on write - file system? If you know that every block you write will go into newly found free space instead of having to fit where the old one did, it becomes much easier to handle how compressed blocks have almost arbitrary sizes.

ZFS is a bad fit in other ways - it's not exactly written to be conscious of every single MB of disk or RAM overhead - but it does make inline compression fairly easy. I can't really imagine how you'd bodge it into UFS (or ext4) without a whole new layer of indirection between the FS's view of disk blocks and the actual blocks; almost like the wear levelling magic in an SSD but on the geom side.

It's absolutely much easier with CoW filesystems, to the point that ZFS on FreeBSD has been doing in-line compression with lz4 around early 2013 with revision 246586 and in revision 251478 the L2ARC got automatically compressed, meaning you easily get 2x more ARC as it's quite easy to maintain a 2x ratio with lz4 - and it still manages to be faster than most spinning rust.

It just can't be combined with geom_uzip because that's meant to be a read-only disk-image that's supposed to be read into memory and have configuration stored on a separate (mirrored) partition.

# ? May 31, 2020 18:38

Computer viking: May 30, 2011; Now with less breakage.

Yeah, I switched to LZ4 as soon as it seemed stable, it works nicely with the data we store at work.

What I was thinking about is an approach almost like gjournal, where you have an FS-neutral layer that does CoW block compression, has a redirect table for virtual/physical mapping, relies on TRIM to free blocks, and needs a touch of support from the file system to give a somewhat true estimate of free space. I can't imagine something like that would be entirely great for performance, but for live media storage ... maybe?

Not that I'll ever get around to learn enough about writing geom modules to implement it, I have a long enough "I should do that but probably won't" list as is.

Are there any lightweight, minimal-feature CoW file systems around with a reasonable license?

Edit: Hmm. The qcow2 file format that qemu uses for its disk images is, as the name implies, CoW. It's also sparse, and supports transparent compression (and encryption). Mounting one of those read/write as a raw device and putting a file system on it would be cute, especially if it actually shrinks on TRIMs.

Edit2: Ah, it's only possible to compress (and encrypt) at rest; further data will be written uncompressed (but can be compressed next time you unmount). Bit less impressive.

Computer viking fucked around with this message at 19:48 on May 31, 2020

# ? May 31, 2020 19:37

BlankSystemDaemon: Mar 13, 2009

Computer viking posted:

Yeah, I switched to LZ4 as soon as it seemed stable, it works nicely with the data we store at work.

What I was thinking about is an approach almost like gjournal, where you have an FS-neutral layer that does CoW block compression, has a redirect table for virtual/physical mapping, relies on TRIM to free blocks, and needs a touch of support from the file system to give a somewhat true estimate of free space. I can't imagine something like that would be entirely great for performance, but for live media storage ... maybe?

Not that I'll ever get around to learn enough about writing geom modules to implement it, I have a long enough "I should do that but probably won't" list as is.

Are there any lightweight, minimal-feature CoW file systems around with a reasonable license?

Edit: Hmm. The qcow2 file format that qemu uses for its disk images is, as the name implies, CoW. It's also sparse, and supports transparent compression (and encryption). Mounting one of those read/write as a raw device and putting a file system on it would be cute, especially if it actually shrinks on TRIMs.

Edit2: Ah, it's only possible to compress (and encrypt) at rest; further data will be written uncompressed (but can be compressed next time you unmount). Bit less impressive.

If you want CoW at minimum you also want atomic operations, and at that point you might as well take quiescence as well because otherwise you run into problems. And since trees are such a fantastic way to store data, why not use those?
Soon you've reinvented ZFS without even trying.

# ? May 31, 2020 19:54

mystes: May 31, 2006

Mr Shiny Pants posted:

The problem I had was a PCIe bus reset error. That went away after kernel 4.2 though.

The problem I had was similar to this threadripper problem apparently related to power states: https://www.reddit.com/r/Amd/comments/7gp1z7/threadripper_kvm_gpu_passthru_testers_needed/

I'm not sure if it's the same as your problem or not, but it sounded like people were saying it had been fixed in newer version of AGESA.

# ? May 31, 2020 21:01

ToxicFrog: Apr 26, 2008

Double Punctuation posted:

This is assuming your UEFI is smart enough to boot a UDF image from a USB drive. Doing this is not guaranteed to work on every system.

No? It uses isohybrid mode which makes it both a valid bootable CD and MBR-bootable hard drive. Recent ones can also boot in UEFI mode.

# ? May 31, 2020 21:19

Computer viking: May 30, 2011; Now with less breakage.

D. Ebdrup posted:

If you want CoW at minimum you also want atomic operations, and at that point you might as well take quiescence as well because otherwise you run into problems. And since trees are such a fantastic way to store data, why not use those?
Soon you've reinvented ZFS without even trying.

You're not wrong, but it still seems like there's room for a much lighter "simple" file system that just happens to do CoW instead of in-place writes?

There's also HAMMER2, I guess; they seem to aim for a low memory footprint while still supporting compression (and checksumming). I don't know their disk space overhead, though - and DFly is sort of an odd project in the first place.

# ? Jun 1, 2020 09:28

Mr Shiny Pants: Nov 12, 2012

mystes posted:

The problem I had was similar to this threadripper problem apparently related to power states: https://www.reddit.com/r/Amd/comments/7gp1z7/threadripper_kvm_gpu_passthru_testers_needed/

I'm not sure if it's the same as your problem or not, but it sounded like people were saying it had been fixed in newer version of AGESA.

Yeah that is the one.

# ? Jun 1, 2020 09:35

The Merkinman: Apr 22, 2007; I sell only quality merkins. What is a merkin you ask? Why, it's a wig for your genitals!

I've noticed a bug, but I don't know if the problem is Firefox, Slack, Ubuntu or what....

I have Firefox as my default browser on Ubuntu 20.04. When I open a link in the Linux native version of Slack, it opens up in Firefox... but...the launcher on the side treats it as another open window of Slack. Also, if I then use said launcher to open Firefox, it acts as though another window in Slack is being opened.

# ? Jun 2, 2020 15:45

RFC2324: Jun 7, 2012; http 418

The Merkinman posted:

I've noticed a bug, but I don't know if the problem is Firefox, Slack, Ubuntu or what....

I have Firefox as my default browser on Ubuntu 20.04. When I open a link in the Linux native version of Slack, it opens up in Firefox... but...the launcher on the side treats it as another open window of Slack. Also, if I then use said launcher to open Firefox, it acts as though another window in Slack is being opened.

child processes can be funny

# ? Jun 2, 2020 15:52

acetcx: Jul 21, 2011

I've been running Fedora 32 on my desktop PC for a month now and it's been working well. Last night it asked me to install updates when I shut it down so I did (I normally do).

Today when I turned it on it froze during boot while showing the BIOS logo and the Fedora logo. It wouldn't respond to keyboard input so I couldn't see what was happening. I waited 5 minutes and did a hard reset. After turning it on again this time I hit ESC while it was booting to see what was happening but it booted up successfuly except that it gave me a warning, something about the nvidia kernel module missing and using nouveau instead. The desktop was pretty stuttery so I assume something is wrong with the graphics driver. I rebooted again but got the same warning about the nvidia kernel module.

Anyway, I rebooted again and this time selected the previous kernel version when the prompt came up. It always shows the last 3 versions, in this case 5.6.15 (the one that's broken), 5.6.14 (the one I picked), 5.6.13, and a recovery option.

5.6.14 is working fine, no warnings and the desktop is smooth. Should I be worried about this or is this likely to be fixed in the next update?

# ? Jun 3, 2020 18:18

Volguus: Mar 3, 2009

acetcx posted:

I've been running Fedora 32 on my desktop PC for a month now and it's been working well. Last night it asked me to install updates when I shut it down so I did (I normally do).

Today when I turned it on it froze during boot while showing the BIOS logo and the Fedora logo. It wouldn't respond to keyboard input so I couldn't see what was happening. I waited 5 minutes and did a hard reset. After turning it on again this time I hit ESC while it was booting to see what was happening but it booted up successfuly except that it gave me a warning, something about the nvidia kernel module missing and using nouveau instead. The desktop was pretty stuttery so I assume something is wrong with the graphics driver. I rebooted again but got the same warning about the nvidia kernel module.

Anyway, I rebooted again and this time selected the previous kernel version when the prompt came up. It always shows the last 3 versions, in this case 5.6.15 (the one that's broken), 5.6.14 (the one I picked), 5.6.13, and a recovery option.

5.6.14 is working fine, no warnings and the desktop is smooth. Should I be worried about this or is this likely to be fixed in the next update?

What happened was that you booted into a kernel that did not have the nvidia drivers compiled for it. No, it won't get fixed in a next update.
How did you install the nvidia drivers? The easy way is to get them from rpmfusion or negativo17 repositories. To get your drivers compiled whenever you boot into a kernel that doesn't have them, do not forget to install the akmod package as well (dkms works too but in the past it used to be finicky and not compile the thing all the time). Then, you won't (usually) have this problem anymore.

# ? Jun 3, 2020 18:34

acetcx: Jul 21, 2011

Volguus posted:

What happened was that you booted into a kernel that did not have the nvidia drivers compiled for it. No, it won't get fixed in a next update.
How did you install the nvidia drivers? The easy way is to get them from rpmfusion or negativo17 repositories. To get your drivers compiled whenever you boot into a kernel that doesn't have them, do not forget to install the akmod package as well (dkms works too but in the past it used to be finicky and not compile the thing all the time). Then, you won't (usually) have this problem anymore.

I believe the drivers were installed by the rpmfusion free and nonfree repositories. I'm pretty sure it "just worked" after I added the rpmfusion repositories when I first installed Fedora. I know I definitely didn't do any sort of manual driver install. I'll investigate akmod when I get home later tonight. Thank you.

# ? Jun 3, 2020 19:20

mystes: May 31, 2006

acetcx posted:

I've been running Fedora 32 on my desktop PC for a month now and it's been working well. Last night it asked me to install updates when I shut it down so I did (I normally do).

Today when I turned it on it froze during boot while showing the BIOS logo and the Fedora logo. It wouldn't respond to keyboard input so I couldn't see what was happening. I waited 5 minutes and did a hard reset. After turning it on again this time I hit ESC while it was booting to see what was happening but it booted up successfuly except that it gave me a warning, something about the nvidia kernel module missing and using nouveau instead. The desktop was pretty stuttery so I assume something is wrong with the graphics driver. I rebooted again but got the same warning about the nvidia kernel module.

Anyway, I rebooted again and this time selected the previous kernel version when the prompt came up. It always shows the last 3 versions, in this case 5.6.15 (the one that's broken), 5.6.14 (the one I picked), 5.6.13, and a recovery option.

5.6.14 is working fine, no warnings and the desktop is smooth. Should I be worried about this or is this likely to be fixed in the next update?

I've had really bad luck with nouveau in the past so I usually keep it blacklisted if the computer is going to have an nvidia card in it, to ensure that nouveau doesn't crash my computer before I can install the proprietary drivers.

# ? Jun 3, 2020 19:44

Volguus: Mar 3, 2009

acetcx posted:

I believe the drivers were installed by the rpmfusion free and nonfree repositories. I'm pretty sure it "just worked" after I added the rpmfusion repositories when I first installed Fedora. I know I definitely didn't do any sort of manual driver install. I'll investigate akmod when I get home later tonight. Thank you.

When you installed them they compiled the driver for your running kernel (if they had to). That's perfectly fine. But to get them to automatically compile whenever a new kernel gets release you need an additional package, the akmod version.

# ? Jun 4, 2020 00:46

acetcx: Jul 21, 2011

Volguus posted:

When you installed them they compiled the driver for your running kernel (if they had to). That's perfectly fine. But to get them to automatically compile whenever a new kernel gets release you need an additional package, the akmod version.

OK, so I finally got a chance to work on this. I double checked my software repositories in the Software app and somehow "RPM Fusion for Fedora 32 - Nonfree - NVIDIA Driver" and also "RPM Fusion for Fedora 32 - Nonfree - Steam" were both disabled. I reenabled both and checked for updates and also ran sudo dnf update and sudo dnf upgrade but they didn't install anything. I rebooted and it still can't find the nvidia driver.

I apparently have akmod installed:

pre:

$ sudo dnf install akmods akmod-nvidia
Last metadata expiration check: 0:14:18 ago on Wed 03 Jun 2020 10:58:24 PM EDT.
Package akmods-0.5.6-25.fc32.noarch is already installed.
Package akmod-nvidia-3:440.82-1.fc32.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

and when I run sudo akmods it says:

pre:

$ sudo akmods
Checking kmods exist for 5.6.15-300.fc32.x86_64            [  OK  ]

I saw something on the rpmfusion website about waiting a few minutes for akmod to build the driver but I don't see anything relevant using up CPU time in top and when I run the suggested command it says:

pre:

$ modinfo -F version nvidia
modinfo: ERROR: Module nvidia not found.

I'm not really sure what to try next.

EDIT: This may be relevant?

pre:

$ ls /var/cache/akmods/nvidia/
440.82-1-for-5.6.10-300.fc32.x86_64.log  kmod-nvidia-5.6.10-300.fc32.x86_64-440.82-1.fc32.x86_64.rpm
440.82-1-for-5.6.11-300.fc32.x86_64.log  kmod-nvidia-5.6.11-300.fc32.x86_64-440.82-1.fc32.x86_64.rpm
440.82-1-for-5.6.12-300.fc32.x86_64.log  kmod-nvidia-5.6.12-300.fc32.x86_64-440.82-1.fc32.x86_64.rpm
440.82-1-for-5.6.13-300.fc32.x86_64.log  kmod-nvidia-5.6.13-300.fc32.x86_64-440.82-1.fc32.x86_64.rpm
440.82-1-for-5.6.14-300.fc32.x86_64.log  kmod-nvidia-5.6.14-300.fc32.x86_64-440.82-1.fc32.x86_64.rpm
440.82-1-for-5.6.6-300.fc32.x86_64.log   kmod-nvidia-5.6.6-300.fc32.x86_64-440.82-1.fc32.x86_64.rpm
440.82-1-for-5.6.7-300.fc32.x86_64.log   kmod-nvidia-5.6.7-300.fc32.x86_64-440.82-1.fc32.x86_64.rpm
440.82-1-for-5.6.8-300.fc32.x86_64.log   kmod-nvidia-5.6.8-300.fc32.x86_64-440.82-1.fc32.x86_64.rpm

OK I peeped at one of those log files and found the command they used to build the module and ran it myself:

pre:

$ /sbin/akmodsbuild --kernels 5.6.15-300.fc32.x86_64 /usr/src/akmods/nvidia-kmod.latest
* Rebuilding /usr/src/akmods/nvidia-kmod.latest for kernel(s) 5.6.15-300.fc32.x86_64: prep build install clean; Successfull; Saved kmod-nvidia-5.6.15-300.fc32.x86_64-440.82-1.fc32.x86_64.rpm in /home/<redacted>/

I'm not sure where to put it now, I'll keep working on this.

EDIT 2: Success!

I ran the generated rpm and it said it was already installed so I uninstalled it. I then ran sudo akmods --force and after it rebuilt the driver I restarted. It loaded the driver properly.

I'm assuming this was all because I did that hard reset and it was actually doing something when I interrupted it?

acetcx fucked around with this message at 04:54 on Jun 4, 2020

# ? Jun 4, 2020 04:17

Antigravitas: Dec 8, 2019; Die Rettung fuer die Landwirte:

I'd just like to say I'm so loving tired of the dkms Nvidia garbage. I luckily don't own any Nvidia crap so it doesn't haunt me at home, but at work we have a bunch of people who require CUDA or just order Nvidia because they are dumb, and it constantly leads to similar issues where I have to ssh in and poke this rickety house of cards to work again.

We never, ever have issues with Intel or AMD, it's always Nvidia with their out-of-tree poo poo.

# ? Jun 4, 2020 08:04

Sheep: Jul 24, 2003

For those not aware, Spacewalk was officially abandoned by the developers on Sunday. Godspeed everyone who is having to transition to Foreman/Katello. Definitely putting that one off as long as humanly possible on my end.

# ? Jun 4, 2020 13:27

xzzy: Mar 5, 2009

Sheep posted:

For those not aware, Spacewalk was officially abandoned by the developers on Sunday. Godspeed everyone who is having to transition to Foreman/Katello. Definitely putting that one off as long as humanly possible on my end.

There's still cobbler. :v:

I wrote my own redhat provisioning tools eons ago and nothing has managed to replace it. Everything is just frustrating enough that it doesn't survive the eval so my home grown code manages to live on.

Someday I want fit Razer into the workflow, its inventorying features are extremely cool but the project has been wallowing in a tech demo stage for years.

# ? Jun 4, 2020 13:55

Kassad: Nov 12, 2005; It's about time.

acetcx posted:

I'm assuming this was all because I did that hard reset and it was actually doing something when I interrupted it?

It was probably rebuilding the kernel module, so when you did the hard reset it left the kernel module in a broken state.

# ? Jun 4, 2020 14:12

RFC2324: Jun 7, 2012; http 418

Kassad posted:

It was probably rebuilding the kernel module, so when you did the hard reset it left the kernel module in a broken state.

based on my experience with the nvidia module, it re-compiles when you reinstall(I always did the manual way til I started using OpenSUSE, which has it as part of the standard repos)

If you don't let it recompile, or the recompile fails in one of the many ways nvidia didn't account for, it looks like it succeeded and installs a broken module, causing the exact symptoms described.

I don't think anything in linux actually does boot time recompile/reconfiguration? Nothing I have really noticed, anyway

# ? Jun 4, 2020 15:45

acetcx: Jul 21, 2011

Antigravitas posted:

I'd just like to say I'm so loving tired of the dkms Nvidia garbage. I luckily don't own any Nvidia crap so it doesn't haunt me at home, but at work we have a bunch of people who require CUDA or just order Nvidia because they are dumb, and it constantly leads to similar issues where I have to ssh in and poke this rickety house of cards to work again.

We never, ever have issues with Intel or AMD, it's always Nvidia with their out-of-tree poo poo.

Yeah I bought this computer when I was still running Windows. Next time I'm definitely getting an AMD card.

# ? Jun 4, 2020 16:08

mystes: May 31, 2006

DKMS is a million times better than having to manually compile modules for new kernel versions, but the nvidia drivers are annoying, though. It's too bad intel isn't competitive in the higher end gpu space because intel is a great experience on linux.

mystes fucked around with this message at 16:15 on Jun 4, 2020

# ? Jun 4, 2020 16:13

Adbot: ADBOT LOVES YOU

# ? Apr 16, 2024 07:21

Antigravitas: Dec 8, 2019; Die Rettung fuer die Landwirte:

RFC2324 posted:

I don't think anything in linux actually does boot time recompile/reconfiguration? Nothing I have really noticed, anyway

Fedora schedules some updates to run on boot, though dkms recompilation shouldn't be one of them. It's mostly used for OS upgrades to the next major release.

# ? Jun 4, 2020 18:28

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Linux Questions Thread: a bunch of pitfalls, but technically it's possible

«‹›1023 »