• 0 Posts
  • 33 Comments
Joined 2 years ago
Cake day: June 22nd, 2024
  • Gyroplast@pawb.socialtolinuxmemes@lemmy.world•whatever, it worksEnglish
    201·
    5 months ago

    Not what it implicitly advertises, unfortunately. It lists all files (ls) recursively in all subdirectories (-R), one per line with details (-l), sorted by time, newest first (-t). Only the first 10 files are shown (| head).

    The problem is that the files are sorted by time per directory, and ls recursively descents into subdirectories in that order. It’s not a “Depth First Search”, if you’re so inclined. Effectively, this shows the newest 10 files/dirs in the current directory before diving down, and if you have less files/dirs than that in your search base directory, you probably don’t need this hack to begin with.

    In good tradition, here’s something that actually works as likely intended. find recursively lists (only) all regular files (-type f) starting in the current directory (.) and runs the ls command (-exec) to show details (-l) of each file passed as arguments ({} +), including a specific, sortable time format (--time-style). The resulting comprehensive list of all files is then sorted in reverse (-r) order, using the sixth whitespace-separated column of each line/file as the key (-k6), which just so happens to be the “sortable time format”. Lastly, only the 10 most recent files are shown (| head), as before:

    find . -type f -exec ls -l --time-style=+"%Y-%m-%dT%T" {} + | sort -r -k6 | head

    Running this is a great way to start your day! It’ll give you ample time to brew some coffee or tea, slip into your most comfortable programmer socks, and finish lunch by the time it scanned your 18.3 TB of furry smut to show you what you “touched” last.

    It’ll likely be irrelevant cache files, though, if you run it from your $HOME. Excluding directories is left as an exercise for the reader.

  • Gyroplast@pawb.socialtolinuxmemes@lemmy.world•Personally I'm grateful to not need 3rd party packagesEnglish
    5·
    9 months ago

    TL;DR: Don’t think of the AUR as a package source, but as of an only mildly moderated, but ultimately free and open, sharing platform for PKGBUILDs, primarily useful for (self-)packagers, not necessarily non-technical end users.

    Before the AUR, you had people individually hosting their PKGBUILDs anywhere, sometimes on GitHub or the BBS (yeah, it’s been a while), sometimes along with a repository URL you could add to your pacman.conf to install packages right away, and it was glorious. I didn’t have to write a working PKGBUILD myself from scratch, and I could decide if I trusted that particular packager to not screw me sideways with a pre-built package. An officialized “Trusted User” (TU) role emerged from this idea, which has recently been renamed to Package Maintainer (PM). This is fundamentally still how the AUR works, it just became much bigger, and easier to search for particular software. Packagers gift to you their idea of how software should be packaged, for you to expand upon, take inspiration from, or learn, or use as-is if you determine it to be good for your purpose.

    The AUR is ultimately a great resource for packagers, and still useful for users, but “true end users” get the extra repository, and community, kind of, before that, and should try to avoid the AUR if they can, or at least be prepared to put in effort to establish trust, or get help.

    A handful of Package Maintainers are manually adopting and subsequently vetting for sufficiently popular packages to move them from the AUR to the official extra repository, which is deemed safe to use as-is, on a best-effort basis. Obviously, this is a bottleneck, as it is not feasible for the few volunteering PMs to adopt and maintain 10k+ AUR packages and be held to any quality standard. That’s why “you are on your own” with the AUR.

    On the positive side, there’s a voting system to determine package popularity. AUR packagers have a public list of maintained packages, and a comprehensive git commit history. Establishing trust is still crucial, and I feel hard pressed to name a reasonably popular/useful package that isn’t already in extra or has been maintained in the AUR for a long time.

    The biggest risk, IMHO, for malware getting slipped into a package is orphaning a popular package, and having it adopted by a malevolent user. This is something I personally look out for. If the maintainer changed, I make sure to check the commit history to see what they did. Most of the time it’s genuine fixes, but if anything is changed without a damn good and obvious reason, hit up the AUR mods and ask for help. This is how malware is spotted. Also, typically only the version is bumped in a PKGBUILD on an update, which is a change I feel safe waving through, too. If the download URI changes, or patches are added, I do look at them to determine the reason, and if that isn’t explained well enough to understand, that’s a red flag. Better ask someone before running this.

    source: personal involvement in Arch since 2002

  • Gyroplast@pawb.socialtoArch Linux@lemmy.ml•New Motherboard with pre-existing Linux Install can't be found?English
    5·
    10 months ago

    You can fix this, and this certainly isn’t “basic”.

    I figure you didn’t see your Linux option, because your EFI boot variables (boot order and boot loader locations) are stored “on the mainboard”, and you didn’t manage to reset those on the new board according to your current layout. Windows still boots, as it installs its bootloader in a generic location intended for removable devices, instead of properly registering itself with EFI boot variables. Because of course they do.

    To fix this, I’d recommend a deep breath first, and then set BIOS to UEFI boot only, no CSM/legacy at all for now, no even as fallback. If you’re lucky, you can boot into your Linux system from the BIOS boot menu right now, and skip the archiso boot and chroot shenanigans. Have a look. Otherwise boot into the archiso as you did before.

    Identify your EFI system partition(s) (ESP) Run sfdisk -l /dev/nvme0n1 and sfdisk -l /dev/nvme1n1, note the “EFI System” type partitions. Ideally, there’s only one at nvme1n1p3. Multiple ESPs would be trickier, but let’s assume your singular ESP is nvme1n1p3. Have a look at the ESP, to understand its layout and confirm this is really what you’re looking for: mkdir /esp, mount /dev/nvme1n1p3 /esp, find /esp. You should find the Windows bootloader at EFI/Boot/bootx64.efi and EFI/Microsoft/Boot/bootmgfw.efi.

    You might also find your grub bootloader in a subdirectory like EFI/arch/grubx64.efi. Find all of your instances with find /esp -iname grubx64.efi, and note the paths. If you find multiple grubx64.efi, I’d recommend to pick only the newest file, unless you know for a fact which one is supposed to be the one you want to use. A ls -l <file> gives you the date of the file to check. If you don’t have any grub bootloader installed, yet, that’s fine, too.

    Create a boot entry with grub in a chrooted system If you can arch-chroot into your Linux system, make sure your ESP is mounted in your chroot as well, let’s say at /esp again, and your /boot directory must be mounted, too, otherwise grub-install will fail. Then grub-install --efi-directory=/esp should do its magic just fine. Use efibootmgr to display/edit the EFI boot variables, and check if the entries in there look correct. The ESP will be referenced by UUID, and the list will look pretty busy, but you should recognize the EFI paths, and your arch entry should be the BootCurrent value. Make sure you’ve got a /boot/grub/grub.cfg in place, otherwise grub won’t do you much good! Create one with grub-mkconfig -o /boot/grub/grub.cfg from within your chroot, after editing /etc/default/grub if you need to add any kernel arguments for your system. Usually you do not, so fire away.

    If chrooting doesn’t work for you, btrfs can be a little tricky, you should be able to install grub with the ESP and boot partition mounted alone in the archiso. nvme0n1p1 looks like your boot partition, so it’d go down like this:

    mkdir /esp /linuxboot
mount /dev/nvme1n1p3 /esp
mount /dev/nvme0n1p1 /linuxboot
grub-install --efi-directory=/esp --boot-directory=/linuxboot

    You can pacman -S grub if grub-install isn’t available on archiso, yet. Make sure you’ve got a /linuxboot/grub/grub.cfg in place here as well. Unfortunately you cannot use grub-mkconfig effectively without the chroot, but if you are at this point, and you’re dropped into the grub rescue shell, you can try a minimal, lovingly handcrafted grub.cfg: You need to obtain the UUIDs of your ESP, boot and root partition for the menuentries, and replace the placeholders with your values. You can get those values with lsblk -oNAME,UUID /dev/nvme1n1p3 /dev/nvme0n1p1 /dev/nvme0n1p2, in this order (ESP, BOOTPART, ROOTPART UUID). I assume your root subvolume is named root, and your kernel is named vmlinuz-linux on the boot partition, with a vmlinuz-linux.img initfs. You should adapt these filenames in the grub.cfg if they are different, of course, but I think this is a pretty good guess. :)

    insmod part_gpt
insmod part_msdos
set default="0"
if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi
export menuentry_id_option
function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}
terminal_input console
terminal_output console
set timeout=5
menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod ext2
        search --no-floppy --fs-uuid --set=root <BOOTPART UUID>
        echo    'Loading Linux linux ...'
        linux   /vmlinuz-linux root=UUID=<ROOTPART UUID> rw  rootflags=subvol=root
        echo    'Loading initial ramdisk ...'
        initrd  /initramfs-linux.img
}
if [ "$grub_platform" = "efi" ]; then
  insmod bli
fi
if [ "$grub_platform" = "efi" ]; then
menuentry 'Windows Boot Manager --class windows --class os $menuentry_id_option 'osprober-efi' {
        insmod part_gpt
        insmod fat
        search --no-floppy --fs-uuid --set=root <ESP UUID>
        chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
fi

    Let’s see how this goes.