[arch-general] Fail2Ban is not adding iptables rules
Hi, I have this script for iptables for my archlinux desktop: https://pastebin.com/SafhsKFt And when received external request access SSH error, fail2ban add rule but the rule not working. I think it has to do with the iptables script, but the fail2ban blocking rules add fine but don't ban. That could be happening?
Re: [arch-general] Makepkg: Incremental builds
Am 02.11.20 um 19:39 schrieb LuKaRo: How can I make use of incremental builds using makepkg? Try https://wiki.archlinux.org/index.php/ccache
Re: [arch-general] Makepkg: Incremental builds
On 11/2/20 1:39 PM, LuKaRo wrote: > Hi everyone, > > I'm currently building ungoogled-chromium from AUR, which is running for > 6 hrs now on my 6-core i7-9750H laptop and almost done. However, I'm > thinking about what happens when the next version will be released. From > my understanding, when running git pull to fetch the latest version from > AUR and afterwards makepkg -sri, the old binaries will be deleted prior > to starting the build, which will probably require to build everything > from scratch. Am I right? > > However, I'm sure that only parts of the source change between versions. > Therefore, only parts of the binary files would need to be built again, > which would dramatically decrease build time. Correct? How can I make > use of incremental builds using makepkg? I'm aware of the -e switch, but > that would skip the prepare function, which might be required as e.g. > new patch files from AUR would need to be applied. makepkg --noextract will continue a build you have interrupted using CTRL+C, it does not perform "incremental" builds for the next version of the software. > Furthermore, the timestamps of the source files all seem to be set to > the archival date. This would probably also require a full build, even > if only parts of the source changed. Correct? If yes, is there a way to > fix that? The source extraction naturally overwrites every single file in the current source archive, and updates timestamps in the process. Otherwise, how would you get the new source code? ;) Using bsdtar to unpack a tarball doesn't exactly know which files should be skipped due to not changing... > Having to spend 6-7 hrs of build time on each new release would make > frequent updating impractical. You have two options: - use ccache to cache compiler results, for unchanged source files and unchanged recursive includes you often won't need to recompile and ccache's gcc wrapper will instead output the file from the cache for significant speedup - use git+https:// based sources, since git *can* (and does) figure out which files need to be modified on disk in order to be updated to the desired revision. makepkg -sri for git-based source code does indeed play quite nicely with incremental builds -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Makepkg: Incremental builds
On Mon, Nov 2, 2020, 12:40 PM LuKaRo wrote: > Hi everyone, > > I'm currently building ungoogled-chromium from AUR, which is running for > 6 hrs now on my 6-core i7-9750H laptop and almost done. However, I'm > thinking about what happens when the next version will be released. From > my understanding, when running git pull to fetch the latest version from > AUR and afterwards makepkg -sri, the old binaries will be deleted prior > to starting the build, which will probably require to build everything > from scratch. Am I right? > However, I'm sure that only parts of the source change between versions. > Therefore, only parts of the binary files would need to be built again, > which would dramatically decrease build time. Correct? How can I make > use of incremental builds using makepkg? I'm aware of the -e switch, but > that would skip the prepare function, which might be required as e.g. > new patch files from AUR would need to be applied. > > Furthermore, the timestamps of the source files all seem to be set to > the archival date. This would probably also require a full build, even > if only parts of the source changed. Correct? If yes, is there a way to > fix that? Having to spend 6-7 hrs of build time on each new release would make > frequent updating impractical. There are binary packages available on the ungoogled-chromium-archlinux GitHub page[1], however, downloading binaries from untrusted sources is usually frowned upon. [1]: https://github.com/ungoogled-software/ungoogled-chromium-archlinux -- Yash Thanks in advance! LuKaRo
[arch-general] Makepkg: Incremental builds
Hi everyone, I'm currently building ungoogled-chromium from AUR, which is running for 6 hrs now on my 6-core i7-9750H laptop and almost done. However, I'm thinking about what happens when the next version will be released. From my understanding, when running git pull to fetch the latest version from AUR and afterwards makepkg -sri, the old binaries will be deleted prior to starting the build, which will probably require to build everything from scratch. Am I right? However, I'm sure that only parts of the source change between versions. Therefore, only parts of the binary files would need to be built again, which would dramatically decrease build time. Correct? How can I make use of incremental builds using makepkg? I'm aware of the -e switch, but that would skip the prepare function, which might be required as e.g. new patch files from AUR would need to be applied. Furthermore, the timestamps of the source files all seem to be set to the archival date. This would probably also require a full build, even if only parts of the source changed. Correct? If yes, is there a way to fix that? Having to spend 6-7 hrs of build time on each new release would make frequent updating impractical. Thanks in advance! LuKaRo signature.asc Description: OpenPGP digital signature
Re: [arch-general] USB flash installation medium in BIOS machines
> There are only my 2 installed hard drives plus a "USB HDD: ..." option. > I am very positive that this laptop is legacy BIOS only and that it is > somehow wrongly identified as UEFI? It can't be "wrongly identified as UEFI". If the laptop didn't support UEFI, then you wouldn't even see the systemd-boot menu, because there wouldn't be anything to *load* systemd-boot, or support it running. systemd-boot is designed to exclusively run in the UEFI environment, and it just can not work at all in a BIOS environment. >>> I see the boot menu (which looks like systemd-boot menu) with only options >>> for UEFI boot and EFI shell option. -- damjan
Re: [arch-general] USB flash installation medium in BIOS machines
El lun., 2 nov. 2020 a las 10:57, Juergen Werner via arch-general
() escribió:
> I tried 2 different USB drives and different USB ports. Am I missing
> something?
Hi jotz. I tell you a method to have a Live USB that boots directly
from ISO and that can have several ISOs.
Let's assume that your USB is /dev/sdX
1. Partition It:
sudo fdisk /dev/sdX
One DOS partition, press o to new table, n to new partition a enter to
end to pick full disk. Set the partition type with t command to c (W95
FAT32 (LBA)) and use a to activate partition.
2. Format as FAT:
sudo mkfs.fat -F32 -n MULTIBOOT /dev/sdX1
3. Mount it in /usb (or in any site that you like, in my sample I'm using /usb).
sudo mkdir /usb
sudo mount /dev/sdX1 /usb
4. Make a boot dir in USB
sudo mkdir /usb/boot
5. Install GRUB for BIOS and UEFI (First line is for BIOS and second
one for UEFI)
sudo grub-install --target=i386-pc --recheck --boot-directory=/usb/boot /dev/sdX
sudo grub-install --target x86_64-efi --removable
--boot-directory=/usb/boot --efi-directory=/usb
6. Edit grub menu file (/usb/boot/grub/grub.cfg) writ this into it:
insmod all_video
set gfxpayload=keep
submenu "Arch Linux --->" {
set isover="2020.11.01"
set isoarch="x86_64"
set isofile="/iso/archlinux-${isover}-${isoarch}.iso"
loopback loop ${isofile}
menuentry "Arch Linux ${isover} ${isoarch}" {
echo "Using ${isofile}..."
probe -u ${root} --set=rootuuid
linux (loop)/arch/boot/${isoarch}/vmlinuz-linux
img_dev=/dev/disk/by-uuid/${rootuuid} img_loop=${isofile}
initrd (loop)/arch/boot/intel-ucode.img
(loop)/arch/boot/amd-ucode.img
(loop)/arch/boot/${isoarch}/initramfs-linux.img
}
menuentry "Run Memtest86+ (RAM test)" {
echo "Using ${isofile}..."
linux16 (loop)/arch/boot/memtest
}
}
7. Create a /usb/iso directory and copy archlinux-2020.11.01-x86_64.iso into it.
8. Sync and umount
sync
umount /usb
Reboot and enjoy. If you want more entries for the grub menu or have
other ISOs in your USB you can see my article about it[1] (it's in
Spanish but Google translate makes miracles).
Greetings.
[1]: https://blog.ogarcia.me/crear-un-usb-multiboot/
--
Óscar García Amor | ogarcia at moire.org | http://ogarcia.me
Re: [arch-general] USB flash installation medium in BIOS machines
On 02.11.20 15:17, Łukasz Michalski wrote: There should be two separate entries in boot menu for booting in UEFI mode and Legacy BIOS mode. What choices do you have if you open boot device menu? There are only my 2 installed hard drives plus a "USB HDD: ..." option. I am very positive that this laptop is legacy BIOS only and that it is somehow wrongly identified as UEFI? I forgot to mention, that once I confirm one of the UEFI boot options in the systemd-boot menu, the screen goes black, the fan speed increases and then stays constant. Nothing happens afterwards and no reaction on (multiple) ctrl-alt-del. Only a long press of the power button releases it from its pain.
Re: [arch-general] USB flash installation medium in BIOS machines
On 02/11/2020 12.23, Juergen Werner via arch-general wrote: > I just double checked and I don't see any mentioning of UEFI or CSM in > the BIOS settings. I always used legacy BIOS instructions and setup > before and it always worked on this machine (Acer Travelmate TM8473T). > > But I can imagine, that this BIOS is somewhat tainted with EFI, because > at that time it was just getting introduced to the general public. There should be two separate entries in boot menu for booting in UEFI mode and Legacy BIOS mode. What choices do you have if you open boot device menu? Regards, Łukasz
Re: [arch-general] USB flash installation medium in BIOS machines
On 02.11.20 11:22, David Runge wrote: It seems that your hardware does support UEFI, otherwise systemd-boot would not be started. You can check in your BIOS/Firmware. Many older models have both BIOS and UEFI capabilities and usually you can select which should be used. I just double checked and I don't see any mentioning of UEFI or CSM in the BIOS settings. I always used legacy BIOS instructions and setup before and it always worked on this machine (Acer Travelmate TM8473T). But I can imagine, that this BIOS is somewhat tainted with EFI, because at that time it was just getting introduced to the general public. I found a Linux Mint forum entry where they describe a similar problem with a relatively recent installation medium on this laptop. [1] Syslinux will only be used if the hardware does not provide UEFI. Can I force it somehow? Like by manipulating the image on the flash drive? [1] https://forums.linuxmint.com/viewtopic.php?t=302868
Re: [arch-general] USB flash installation medium in BIOS machines
On 2020-11-02 10:57:02 (+0100), Juergen Werner via arch-general wrote: > I started working on my old Laptop again, which is a pre-EFI model and > needed a live USB medium to do some repartitioning. I copied the > current installation ISO to a USB flash. When I try to boot with it, I > see the boot menu (which looks like systemd-boot menu) with only > options for UEFI boot and EFI shell option. It seems that your hardware does support UEFI, otherwise systemd-boot would not be started. You can check in your BIOS/Firmware. Many older models have both BIOS and UEFI capabilities and usually you can select which should be used. Syslinux will only be used if the hardware does not provide UEFI. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-general] USB flash installation medium in BIOS machines
Hi, I started working on my old Laptop again, which is a pre-EFI model and needed a live USB medium to do some repartitioning. I copied the current installation ISO to a USB flash. When I try to boot with it, I see the boot menu (which looks like systemd-boot menu) with only options for UEFI boot and EFI shell option. In the wiki it is mentioned, that BIOS boots are available throug syslinux: Tip: The installation image uses systemd-boot for booting in UEFI mode and syslinux for booting in BIOS mode. [...] I tried 2 different USB drives and different USB ports. Am I missing something? Cheers, jotz
