I’m just this guy, you know?

  • 14 Posts
  • 276 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle








  • If you’d bought a 2TB you could just dd image the windows disk to the new drive. If you can convince Windows to downsize its partition and then use a partition editor on a USB liveboot to identify the drive sectors you could maybe still image the windows disk. Big “if.”

    As to the second question, use block IDs-- the filesystem’s UUID. Grub is lazy and assumes a single root (the first found) partition so if you want a particular boot entry to use a specific root slice, you’ll need to ensure each OS entry in grub uses the right UUID for its kernel root parameter. Loading the right root gets you the rigjt /etc/fstab to mount that root’s expected partitions

    Honestly you’d be better off running your stuff in VMs. Dual-boot is a nightmare.












  • No worries, the other poster was just wasn’t being helpful. And/or doesn’t understand statistics & databases, but I don’t care to speculate on that or to waste more of my time on them.

    The setting above maxes out at 24h in stock builds, but can be extended beyond that if you are willing to recompile the FTL database with different parameters to allow for a deeper look back window for your query log. Even at that point, a second database setting farther down that page sets the max age of all query logs to 1y, so at best you’d get a running tally of up to a year. This would probably at the expense of performance for dashboard page loads since the number is probably computed at page load. The live DB call is intended for relatively short windows vs database lifetime.

    If you want an all-time count, you’ll have to track it off box because FTL doesn’t provide an all-time metric, or deep enough data persistence. I was just offering up a methodology that could be an interesting and beneficial project for others with similar needs.

    Hey, this was fun. See you around.