• 5 Posts
  • 834 Comments
Joined 3 years ago
cake
Cake day: July 4th, 2023

help-circle
  • Afaik, those by-* paths are symlinks created by udev during boot (before switching to the real root fs) The kernel creates the actual device files directly in /dev. My guess is that Windows left an NTFS volume in an unmountable state or something and udev got stuck processing this disk before processing rules for your boot disk. This probably requires you to have a fstab entry for mounting your windows disk, but I’m not sure.

    When you boot into a live distro again (I know you’re done, but maybe someone else has this problem) check if the disk has a block device file directly in /dev. Maybe check the other disk, see if you can mount it or remove references to it in fstab or unplug the device entirely.


  • Totally unrelated, but I just want to say that my 14 TB sas drive (exos?) was brought back to life in a 12 TB configuration after failure by using openseachest to deactivate one side of one of the platters (the failing one, it was the only one with errors) after I told it to start it took 4 days to reformat, most of that time reporting no progress, but finally finished and now it works great!



  • The easy thing is to just format them ext4 and use them as extra data storage.

    Edit 2: don’t delete the efi partition!!! Move that just like your system partition. Unless you want to learn how to rebuild it :) unless you’re using Windows boot manager you can remove the Microsoft folder from the efi partition as well

    The good news is your system partition is small so you can delete the first two partitions. Make a small boot partition if you want, make a new system partition second ( bigger than your current one), copy the existing system partition into the new one (without deleting the old one), boot into the new system partition, test that it works, then expand the fs to fill the partition. Then you can move your home partition if you want or just make your system partition huge to fill the space up to your existing home partition, then delete the last partitions an grow your home partition to fill the disk

    Edit: once you know the new system partition works you delete the old one.





  • I’m a btrfs noob, so I’m skipping any tools that may fix the disk, try those first.

    If the media isn’t dying, try a file carving tool like photorec. Idk if testdisk supports btrfs but it’s worth a try, it’s my go-to for undelete and finding lost partitions.

    Edit: missed most of your post. First you need to check the kernel logs using the dmesg command. Look for errors that may explain why the disk doesn’t show up, especially if it lists scsi or sata in the message.

    Edit again: you may want to check the disk’s self reported heath using “smart” data. Many bios menus show this info, and there are programs to get it on Linux. If there are too many read or write errors, you need to decide how important the data is. Professional recovery can probably get all of your data if you stop using the drive now and send it in. DIY recovery using a file carving tool would work best if you have another disk to make an image of the failing one with. ddrescue would be the tool for the job to create the image. If you don’t have another disk large enough, and the files aren’t super important, you can run file carving on the failing disk directly, but the more you use it the greater chance the disk will corrupt more data.










  • The best part of vba is you can record a Macro then edit it. I think you should start by adding a button that shows a message box when you press it, then record a Macro and throw some message boxes in it to see what values are used. Beware, office 365 has some other thing besides vba that I’m not familiar with, you may be better off learning that.




  • If you’re writing a program, definitely multiple threads or processes that each scan a chunk of the file, which basically means seek to the start of the chunk, read lines into the scan code until you hit the end of the chunk. For jsonl each chunk will need an alignment step to not break the jsonl.

    For command line trickery, maybe the file could be chunked up by running multiple dd instances with an offset parameter piped into grep. This has many synchronization issues and all the outputs should be captured separately then combined afterwards. I can’t think of a good way to align this method to line edges but maybe you can put some fancy regular expression magic into the grep step to ignore malformed json at the beginning and end and overlap the chunks?

    Grep is fast already, maybe test the simple approach and see how long it takes.