From ruben at mrbrklyn.com Sun Aug 3 06:45:08 2025 From: ruben at mrbrklyn.com (Ruben Safir) Date: Sun, 3 Aug 2025 00:45:08 -0400 Subject: [artix-general] [ruben@mrbrklyn.com: [Hangout - NYLXS] Printer Purchases..] Message-ID: <20250803044508.GA18011@www2.mrbrklyn.com> ----- Forwarded message from Ruben Safir ----- Date: Sun, 3 Aug 2025 00:42:51 -0400 From: Ruben Safir To: hangout at mrbrklyn.com, docs at mrbrklyn.com Subject: [Hangout - NYLXS] Printer Purchases.. User-Agent: Mutt/1.5.21 (2010-09-15) I've had an excellent HP m551DN network and Duplex postfix color laserjet printer. It really died and needed servicing but servicing seemed to cost more money than replacement, assuming I could even get a call to the office. So I replaced it with a refurbished model from B&H Photo - the replacment being an m554DN. It sat for a couple of months, still boxed, in my office floor because it is just too heavy for me to recycle the old printer and set up the new one. I am really feeling old at this point. Unfortunately. the new refurnished one is not working. It has an error with the fuser 50.4F00 which implies some electrical problem. The paper tray is not lifting either. It cost me over $400 and at this point it seems worthless. I need a replacement printer, and you would think after almost 10 years that the technology might advance, but it doesn't seem to have. I need a color laser printer (just to print) and network ready (not wifi - and not depenent on cellphoes - I don't even OWN a cellphone). And I am struggling with a reasonable alternative. And these new HPs a locked into the cartilages. So I am very frustrated with the situation. They are twisting my arm so badly to force shit on my that I don't want that my arm is coming off at the shoulder. I am fielding suggestions. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 _______________________________________________ Hangout mailing list Hangout at nylxs.com http://lists.mrbrklyn.com/mailman/listinfo/hangout ----- End forwarded message ----- -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 From somenxavier at posteo.net Sun Aug 3 13:04:57 2025 From: somenxavier at posteo.net (Xavier B.) Date: Sun, 03 Aug 2025 11:04:57 +0000 Subject: [artix-general] [ruben@mrbrklyn.com: [Hangout - NYLXS] Printer Purchases..] In-Reply-To: <20250803044508.GA18011@www2.mrbrklyn.com> References: <20250803044508.GA18011@www2.mrbrklyn.com> Message-ID: <20250803130456.993e421cb6acfa36bca895d9@posteo.net> Hi, Ruben. Brother has good options. I have a HL3150cdw one and it works. I recommend you to search in your local retailer web page and check if " linux" is good. - linuxprinting.org - and the wiki of archlinux are some points to start if you want to search some info. Regards, Xavier On Sun, 3 Aug 2025 00:45:08 -0400 Ruben Safir ha escrit: > ----- Forwarded message from Ruben Safir ----- > > Date: Sun, 3 Aug 2025 00:42:51 -0400 > From: Ruben Safir > To: hangout at mrbrklyn.com, docs at mrbrklyn.com > Subject: [Hangout - NYLXS] Printer Purchases.. > User-Agent: Mutt/1.5.21 (2010-09-15) > > I've had an excellent HP m551DN network and Duplex postfix color > laserjet printer. It really died and needed servicing but servicing > seemed to cost more money than replacement, assuming I could even get a > call to the office. > > So I replaced it with a refurbished model from B&H Photo - the > replacment being an m554DN. It sat for a couple of months, still boxed, > in my office floor because it is just too heavy for me to recycle the > old printer and set up the new one. I am really feeling old at this > point. > > Unfortunately. the new refurnished one is not working. It has an error > with the fuser 50.4F00 which implies some electrical problem. The paper > tray is not lifting either. It cost me over $400 and at this point it > seems worthless. > > I need a replacement printer, and you would think after almost 10 years > that the technology might advance, but it doesn't seem to have. I need > a color laser printer (just to print) and network ready (not wifi - and > not depenent on cellphoes - I don't even OWN a cellphone). And I am > struggling with a reasonable alternative. And these new HPs a locked > into the cartilages. So I am very frustrated with the situation. They > are twisting my arm so badly to force shit on my that I don't want that > my arm is coming off at the shoulder. > > I am fielding suggestions. > -- > So many immigrant groups have swept through our town > that Brooklyn, like Atlantis, reaches mythological > proportions in the mind of the world - RI Safir 1998 > http://www.mrbrklyn.com > > DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 > http://www.nylxs.com - Leadership Development in Free Software > http://www2.mrbrklyn.com/resources - Unpublished Archive > http://www.coinhangout.com - coins! > http://www.brooklyn-living.com > > Being so tracked is for FARM ANIMALS and extermination camps, > but incompatible with living as a free human being. -RI Safir 2013 > > _______________________________________________ > Hangout mailing list > Hangout at nylxs.com > http://lists.mrbrklyn.com/mailman/listinfo/hangout > > ----- End forwarded message ----- > > -- > So many immigrant groups have swept through our town > that Brooklyn, like Atlantis, reaches mythological > proportions in the mind of the world - RI Safir 1998 > http://www.mrbrklyn.com > > DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 > http://www.nylxs.com - Leadership Development in Free Software > http://www2.mrbrklyn.com/resources - Unpublished Archive > http://www.coinhangout.com - coins! > http://www.brooklyn-living.com > > Being so tracked is for FARM ANIMALS and extermination camps, > but incompatible with living as a free human being. -RI Safir 2013 > > -- > artix-general mailing list > artix-general at artixlinux.org > https://lists.artixlinux.org/listinfo/artix-general From nous at artixlinux.org Tue Aug 5 22:58:21 2025 From: nous at artixlinux.org (Christos Nouskas) Date: Tue, 5 Aug 2025 23:58:21 +0300 Subject: [artix-general] [ruben@mrbrklyn.com: [Hangout - NYLXS] Printer Purchases..] In-Reply-To: <20250803130456.993e421cb6acfa36bca895d9@posteo.net> References: <20250803044508.GA18011@www2.mrbrklyn.com> <20250803130456.993e421cb6acfa36bca895d9@posteo.net> Message-ID: <20250805235821.6d82976e@artixlinux.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > On Sun, 3 Aug 2025 00:45:08 -0400 > Ruben Safir ha escrit: > > I need a replacement printer On Sun, 03 Aug 2025 11:04:57 +0000 "Xavier B." wrote: > Brother has good options. +1 for Brother, perhaps the last manufacturer that used to allow cheap 3rd-party supplies (I get 6K-page toner for <8? and 12K-page drums for even less), emphasis on 'used to'. So, if you can get your hands on a used machine (most people won't sell them, but you may get lucky if some company foolishly replaces them), get one and don't ever update its firmware. Hell, it's even possible to downgrade a bad firmware should you wish to. Last year we got a brand-new MFC-L2800DW at work and aftermarket toner worked right out of the box. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEmK5uMq4KTRJurKyMYCPDvuqwjEoFAmiScG0ACgkQYCPDvuqw jEqWlwf/aVxvDJPa4v7iDr5UO3ESIhJGwZLq9UumMf33BCwR15JYwGduA2kDIkvt xuYX5vEeoSYxj+u7q+kPIl4oUdmkvdvU6pJiO6UE+eDA6xDKypv1gLpNkEpiGZQ3 +Eukat7GvdV+tzknE3mmu1wzXeu5NEY6iR2hrpQURA5XPHG22QD0uwHQU7lOApzN 8JdRfECE0FREcKZ5nNJ/zqLAfoAM+OQ4hah7o+zBmQqV+3S63DSnzg3ksjQejN1m S7SJBox9/F03iQpVp1Vm79/+mN3vO0eTxfOIqxBRJydQK9vG+duUPrQvES8zlVoS yzNMx29zE40+vYpUZI+PsGZmHjQIlg== =dFkm -----END PGP SIGNATURE----- From waterbearer54 at gmx.com Mon Aug 18 18:46:11 2025 From: waterbearer54 at gmx.com (aguador) Date: Mon, 18 Aug 2025 18:46:11 +0200 Subject: [artix-general] Kernel 6.16.1 Message-ID: Just updated and noticed that the 6.16.1 kernel uses 67M more than the 6.15.9 kernel, a 40% increase. What has changed to cause such a huge jump? Roy From je-vv at e.email Mon Aug 18 19:17:07 2025 From: je-vv at e.email (Javier) Date: Mon, 18 Aug 2025 11:17:07 -0600 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: References: Message-ID: On 2025-08-18 10:46 AM, aguador wrote: > Just updated and noticed that the 6.16.1 kernel uses 67M more than the > 6.15.9 kernel, a 40% increase. What has changed to cause such a huge > jump? Wow, I didn't notice, but my /boot directory got filled to 97% when it used to be around 50%: > % df -h /boot/ > Filesystem Size Used Avail Use% Mounted on > /dev/nvme0n1p2 290M 262M 8.9M 97% /boot But not just the kernel, the backup initrd is huge: > % du -hs /boot/* > 14M /boot/grub > 902K /boot/grub-common > 201M /boot/initramfs-linux-fallback.img > 18M /boot/initramfs-linux.img > 13M /boot/intel-ucode.img > du: cannot read directory '/boot/lost+found': Permission denied > 12K /boot/lost+found > 154K /boot/memtest86+ > 16M /boot/vmlinuz-linux 201M, oh wow. Maybe I need to change something on how the initrd gets compressed. I don't recall how big the kernel compressed image was, but it's true that /boot as a whole grew up considerably. My UEFI stuff is in a different partition, in case anyone wonders about not being included in /boot... Greetings ! -- Javier From somenxavier at posteo.net Mon Aug 18 19:48:55 2025 From: somenxavier at posteo.net (Xavier B.) Date: Mon, 18 Aug 2025 17:48:55 +0000 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: References: Message-ID: <20250818194854.5dc1b9ea75ce6c30ce459df8@posteo.net> Interesting repoort, Javier. I'm interested so much how was the cause. Xavier On Mon, 18 Aug 2025 11:17:07 -0600 Javier ha escrit: > But not just the kernel, the backup initrd is huge: From swiley at swiley.net Mon Aug 18 19:53:18 2025 From: swiley at swiley.net (Stephen Wiley) Date: Mon, 18 Aug 2025 13:53:18 -0400 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: References: Message-ID: Personally I've switched to keeping /boot/ on the root partition since modern grub can read ext4 anyway and I don't use FDE on most of my machines. I suppose if you do (especially on small EMMC devices like PDAs where you kind of need to) this could be a real problem. --Stephen On Mon, Aug 18, 2025 at 11:17:07AM -0600, Javier wrote: > On 2025-08-18 10:46 AM, aguador wrote: > > Just updated and noticed that the 6.16.1 kernel uses 67M more than the > > 6.15.9 kernel, a 40% increase. What has changed to cause such a huge > > jump? > Wow, I didn't notice, but my /boot directory got filled to 97% when it used to be around 50%: > > > % df -h /boot/ > > Filesystem Size Used Avail Use% Mounted on > > /dev/nvme0n1p2 290M 262M 8.9M 97% /boot > > But not just the kernel, the backup initrd is huge: > > > % du -hs /boot/* > > 14M /boot/grub > > 902K /boot/grub-common > > 201M /boot/initramfs-linux-fallback.img > > 18M /boot/initramfs-linux.img > > 13M /boot/intel-ucode.img > > du: cannot read directory '/boot/lost+found': Permission denied > > 12K /boot/lost+found > > 154K /boot/memtest86+ > > 16M /boot/vmlinuz-linux > > 201M, oh wow. Maybe I need to change something on how the initrd gets compressed. I don't recall how big the kernel compressed image was, but it's true that /boot as a whole grew up considerably. > > My UEFI stuff is in a different partition, in case anyone wonders about not being included in /boot... > > Greetings ! > > -- > Javier > -- > artix-general mailing list > artix-general at artixlinux.org > https://lists.artixlinux.org/listinfo/artix-general From artist at artixlinux.org Mon Aug 18 20:13:47 2025 From: artist at artixlinux.org (artist) Date: Mon, 18 Aug 2025 20:13:47 +0200 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: References: Message-ID: To preserve space you might also have a look at switching from mkinitcpio too booster. From a test box: % ls -lh /boot/*.img -rw-r--r-- 1 root root? 24M Aug? 8 14:34 /boot/booster-linux-fallback.img -rw-r--r-- 1 root root? 25M Jul 27 17:13 /boot/booster-linux-lts-fallback.img -rw-r--r-- 1 root root 4.8M Jul 27 17:13 /boot/booster-linux-lts.img -rw-r--r-- 1 root root 6.0M Aug? 8 14:34 /boot/booster-linux.img -rw------- 1 root root? 48M Aug? 8 14:34 /boot/initramfs-linux-fallback.img -rw------- 1 root root? 49M Aug? 8 14:34 /boot/initramfs-linux-lts-fallback.img -rw------- 1 root root? 16M Aug? 8 14:33 /boot/initramfs-linux-lts.img -rw------- 1 root root? 16M Aug? 8 14:34 /boot/initramfs-linux.img artist -rw------- 1 root root? 16M Aug? 8 14:34 /boot/initramfs-linux.img On 8/18/25 19:53, Stephen Wiley wrote: > Personally I've switched to keeping /boot/ on the root partition since > modern grub can read ext4 anyway and I don't use FDE on most of my > machines. I suppose if you do (especially on small EMMC devices like > PDAs where you kind of need to) this could be a real problem. > > --Stephen > > On Mon, Aug 18, 2025 at 11:17:07AM -0600, Javier wrote: >> On 2025-08-18 10:46 AM, aguador wrote: >>> Just updated and noticed that the 6.16.1 kernel uses 67M more than the >>> 6.15.9 kernel, a 40% increase. What has changed to cause such a huge >>> jump? >> Wow, I didn't notice, but my /boot directory got filled to 97% when it used to be around 50%: >> >>> % df -h /boot/ >>> Filesystem Size Used Avail Use% Mounted on >>> /dev/nvme0n1p2 290M 262M 8.9M 97% /boot >> But not just the kernel, the backup initrd is huge: >> >>> % du -hs /boot/* >>> 14M /boot/grub >>> 902K /boot/grub-common >>> 201M /boot/initramfs-linux-fallback.img >>> 18M /boot/initramfs-linux.img >>> 13M /boot/intel-ucode.img >>> du: cannot read directory '/boot/lost+found': Permission denied >>> 12K /boot/lost+found >>> 154K /boot/memtest86+ >>> 16M /boot/vmlinuz-linux >> 201M, oh wow. Maybe I need to change something on how the initrd gets compressed. I don't recall how big the kernel compressed image was, but it's true that /boot as a whole grew up considerably. >> >> My UEFI stuff is in a different partition, in case anyone wonders about not being included in /boot... >> >> Greetings ! >> >> -- >> Javier >> -- >> artix-general mailing list >> artix-general at artixlinux.org >> https://lists.artixlinux.org/listinfo/artix-general From je-vv at e.email Mon Aug 18 20:29:07 2025 From: je-vv at e.email (Javier) Date: Mon, 18 Aug 2025 12:29:07 -0600 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: References: Message-ID: <85221e37-f3bd-4202-8cd5-c5ffc4204494@e.email> On 2025-08-18 00:13 PM, artist wrote: > To preserve space you might also have a look at switching from mkinitcpio too booster. > From a test box: > % ls -lh /boot/*.img > -rw-r--r-- 1 root root? 24M Aug? 8 14:34 /boot/booster-linux-fallback.img > -rw-r--r-- 1 root root? 25M Jul 27 17:13 /boot/booster-linux-lts-fallback.img > -rw-r--r-- 1 root root 4.8M Jul 27 17:13 /boot/booster-linux-lts.img > -rw-r--r-- 1 root root 6.0M Aug? 8 14:34 /boot/booster-linux.img > -rw------- 1 root root? 48M Aug? 8 14:34 /boot/initramfs-linux-fallback.img > -rw------- 1 root root? 49M Aug? 8 14:34 /boot/initramfs-linux-lts-fallback.img > -rw------- 1 root root? 16M Aug? 8 14:33 /boot/initramfs-linux-lts.img > -rw------- 1 root root? 16M Aug? 8 14:34 /boot/initramfs-linux.img > > artist Thanks @artist, btw, by changing: > #COMPRESSION_OPTIONS=() to: > COMPRESSION_OPTIONS=(--long --ultra -22) and by changing: > #MODULES_DECOMPRESS="no" to: > MODULES_DECOMPRESS="yes" doesn't really gain much, but at least gets me out of the 90+% usage: > % df -h /boot/ > Filesystem Size Used Avail Use% Mounted on > /dev/nvme0n1p2 290M 216M 55M 80% /boot And now: > % du -hs /boot/* > 14M /boot/grub > 902K /boot/grub-common > 159M /boot/initramfs-linux-fallback.img > 14M /boot/initramfs-linux.img > 13M /boot/intel-ucode.img > du: cannot read directory '/boot/lost+found': Permission denied > 12K /boot/lost+found > 154K /boot/memtest86+ > 16M /boot/vmlinuz-linux The initrd backup is still big... So perhaps time to look for booster or dracut, whatever gives smaller images, :) I see the linux image at a reasonable size, 16M Roy, not sure why you mentioned 67M, perhaps you're using something different than the "linux" package? > % uname -a > Linux m1 6.16.1-artix1-1 #1 SMP PREEMPT_DYNAMIC Fri, 15 Aug 2025 23:14:52 +0000 x86_64 GNU/Linux Thanks a lot @artis ! -- Javier From artist at artixlinux.org Mon Aug 18 20:56:32 2025 From: artist at artixlinux.org (artist) Date: Mon, 18 Aug 2025 20:56:32 +0200 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: <85221e37-f3bd-4202-8cd5-c5ffc4204494@e.email> References: <85221e37-f3bd-4202-8cd5-c5ffc4204494@e.email> Message-ID: <4a79828f-bc96-4515-8b26-cee9b52ea4e0@artixlinux.org> Another advantage of booster is that it is a lot faster. artist On 8/18/25 20:29, Javier wrote: > On 2025-08-18 00:13 PM, artist wrote: >> To preserve space you might also have a look at switching from >> mkinitcpio too booster. >> ?From a test box: >> % ls -lh /boot/*.img >> -rw-r--r-- 1 root root? 24M Aug? 8 14:34 >> /boot/booster-linux-fallback.img >> -rw-r--r-- 1 root root? 25M Jul 27 17:13 >> /boot/booster-linux-lts-fallback.img >> -rw-r--r-- 1 root root 4.8M Jul 27 17:13 /boot/booster-linux-lts.img >> -rw-r--r-- 1 root root 6.0M Aug? 8 14:34 /boot/booster-linux.img >> -rw------- 1 root root? 48M Aug? 8 14:34 >> /boot/initramfs-linux-fallback.img >> -rw------- 1 root root? 49M Aug? 8 14:34 >> /boot/initramfs-linux-lts-fallback.img >> -rw------- 1 root root? 16M Aug? 8 14:33 /boot/initramfs-linux-lts.img >> -rw------- 1 root root? 16M Aug? 8 14:34 /boot/initramfs-linux.img >> >> artist > > Thanks @artist, btw, by changing: > >> #COMPRESSION_OPTIONS=() > > to: > >> COMPRESSION_OPTIONS=(--long --ultra -22) > > and by changing: > >> #MODULES_DECOMPRESS="no" > > to: > >> MODULES_DECOMPRESS="yes" > > doesn't really gain much, but at least gets me out of the 90+% usage: > >> % df -h /boot/ >> Filesystem????? Size? Used Avail Use% Mounted on >> /dev/nvme0n1p2? 290M? 216M?? 55M? 80% /boot > > And now: > >> % du -hs /boot/* >> 14M???? /boot/grub >> 902K??? /boot/grub-common >> 159M??? /boot/initramfs-linux-fallback.img >> 14M???? /boot/initramfs-linux.img >> 13M???? /boot/intel-ucode.img >> du: cannot read directory '/boot/lost+found': Permission denied >> 12K???? /boot/lost+found >> 154K??? /boot/memtest86+ >> 16M???? /boot/vmlinuz-linux > > The initrd backup is still big...? So perhaps time to look for booster > or dracut, whatever gives smaller images, :)? I see the linux image at > a reasonable size, 16M Roy, not sure why you mentioned 67M, perhaps > you're using something different than the "linux" package? > >> % uname -a >> Linux m1 6.16.1-artix1-1 #1 SMP PREEMPT_DYNAMIC Fri, 15 Aug 2025 >> 23:14:52 +0000 x86_64 GNU/Linux > > > Thanks a lot @artis ! > > From waterbearer54 at gmx.com Mon Aug 18 21:24:14 2025 From: waterbearer54 at gmx.com (aguador) Date: Mon, 18 Aug 2025 21:24:14 +0200 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: <85221e37-f3bd-4202-8cd5-c5ffc4204494@e.email> References: <85221e37-f3bd-4202-8cd5-c5ffc4204494@e.email> Message-ID: <254ced7c65521bca04d3bdecf3e49be08ebf0da8.camel@gmx.com> El lun, 18-08-2025 a las 12:29 -0600, Javier escribi?: > On 2025-08-18 00:13 PM, artist wrote: > > To preserve space you might also have a look at switching from > > mkinitcpio too booster. > > ?From a test box: > > % ls -lh /boot/*.img > > -rw-r--r-- 1 root root? 24M Aug? 8 14:34 /boot/booster-linux- > > fallback.img > > -rw-r--r-- 1 root root? 25M Jul 27 17:13 /boot/booster-linux-lts- > > fallback.img > > -rw-r--r-- 1 root root 4.8M Jul 27 17:13 /boot/booster-linux- > > lts.img > > -rw-r--r-- 1 root root 6.0M Aug? 8 14:34 /boot/booster-linux.img > > -rw------- 1 root root? 48M Aug? 8 14:34 /boot/initramfs-linux- > > fallback.img > > -rw------- 1 root root? 49M Aug? 8 14:34 /boot/initramfs-linux-lts- > > fallback.img > > -rw------- 1 root root? 16M Aug? 8 14:33 /boot/initramfs-linux- > > lts.img > > -rw------- 1 root root? 16M Aug? 8 14:34 /boot/initramfs-linux.img > > > > artist > > Thanks @artist, btw, by changing: > > > #COMPRESSION_OPTIONS=() > > to: > > > COMPRESSION_OPTIONS=(--long --ultra -22) > > and by changing: > > > #MODULES_DECOMPRESS="no" > > to: > > > MODULES_DECOMPRESS="yes" > > doesn't really gain much, but at least gets me out of the 90+% usage: > > > % df -h /boot/ > > Filesystem????? Size? Used Avail Use% Mounted on > > /dev/nvme0n1p2? 290M? 216M?? 55M? 80% /boot > > And now: > > > % du -hs /boot/* > > 14M???? /boot/grub > > 902K??? /boot/grub-common > > 159M??? /boot/initramfs-linux-fallback.img > > 14M???? /boot/initramfs-linux.img > > 13M???? /boot/intel-ucode.img > > du: cannot read directory '/boot/lost+found': Permission denied > > 12K???? /boot/lost+found > > 154K??? /boot/memtest86+ > > 16M???? /boot/vmlinuz-linux > > The initrd backup is still big...? So perhaps time to look for > booster or dracut, whatever gives smaller images, :)? I see the linux > image at a reasonable size, 16M Roy, not sure why you mentioned 67M, > perhaps you're using something different than the "linux" package? That was the overall increase in size in my boot directory, with everyhing, including fallback. BTW, I had already seen a large increase on another OS I have on another machine that does use dracut. > > > % uname -a > > Linux m1 6.16.1-artix1-1 #1 SMP PREEMPT_DYNAMIC Fri, 15 Aug 2025 > > 23:14:52 +0000 x86_64 GNU/Linux > > > Thanks a lot @artis ! > > > -- > Javier From je-vv at e.email Tue Aug 19 01:42:55 2025 From: je-vv at e.email (Javier) Date: Mon, 18 Aug 2025 17:42:55 -0600 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: <4a79828f-bc96-4515-8b26-cee9b52ea4e0@artixlinux.org> References: <85221e37-f3bd-4202-8cd5-c5ffc4204494@e.email> <4a79828f-bc96-4515-8b26-cee9b52ea4e0@artixlinux.org> Message-ID: <531381cd-95bf-40db-aba9-00eae13c0111@e.email> On 2025-08-18 00:56 PM, artist wrote: > Another advantage of booster is that it is a lot faster. > > artist > > On 8/18/25 20:29, Javier wrote: >> On 2025-08-18 00:13 PM, artist wrote: >>> To preserve space you might also have a look at switching from mkinitcpio too booster. >>> ?From a test box: >>> % ls -lh /boot/*.img >>> -rw-r--r-- 1 root root? 24M Aug? 8 14:34 /boot/booster-linux-fallback.img >>> -rw-r--r-- 1 root root? 25M Jul 27 17:13 /boot/booster-linux-lts-fallback.img >>> -rw-r--r-- 1 root root 4.8M Jul 27 17:13 /boot/booster-linux-lts.img >>> -rw-r--r-- 1 root root 6.0M Aug? 8 14:34 /boot/booster-linux.img >>> -rw------- 1 root root? 48M Aug? 8 14:34 /boot/initramfs-linux-fallback.img >>> -rw------- 1 root root? 49M Aug? 8 14:34 /boot/initramfs-linux-lts-fallback.img >>> -rw------- 1 root root? 16M Aug? 8 14:33 /boot/initramfs-linux-lts.img >>> -rw------- 1 root root? 16M Aug? 8 14:34 /boot/initramfs-linux.img >>> >>> artist Hi @artist ! How did you get booster fallback images? See: > /usr/lib/booster/regenerate_images doesn't generate one for you, and the pacman hook script doesn't either: > /usr/share/libalpm/scripts/booster-install Wondering how you got that one. The man page shows at most a busybox flag, but it's to allow some emergency shell... -- Javier From je-vv at e.email Tue Aug 19 07:10:04 2025 From: je-vv at e.email (Javier) Date: Mon, 18 Aug 2025 23:10:04 -0600 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: <4a79828f-bc96-4515-8b26-cee9b52ea4e0@artixlinux.org> References: <85221e37-f3bd-4202-8cd5-c5ffc4204494@e.email> <4a79828f-bc96-4515-8b26-cee9b52ea4e0@artixlinux.org> Message-ID: <613d3027-bb1e-4142-b096-213c730c7e84@e.email> On 2025-08-18 00:56 PM, artist wrote: > Another advantage of booster is that it is a lot faster. > > artist > > On 8/18/25 20:29, Javier wrote: >> On 2025-08-18 00:13 PM, artist wrote: >>> To preserve space you might also have a look at switching from mkinitcpio too booster. >>> ?From a test box: >>> % ls -lh /boot/*.img >>> -rw-r--r-- 1 root root? 24M Aug? 8 14:34 /boot/booster-linux-fallback.img >>> -rw-r--r-- 1 root root? 25M Jul 27 17:13 /boot/booster-linux-lts-fallback.img >>> -rw-r--r-- 1 root root 4.8M Jul 27 17:13 /boot/booster-linux-lts.img >>> -rw-r--r-- 1 root root 6.0M Aug? 8 14:34 /boot/booster-linux.img >>> -rw------- 1 root root? 48M Aug? 8 14:34 /boot/initramfs-linux-fallback.img >>> -rw------- 1 root root? 49M Aug? 8 14:34 /boot/initramfs-linux-lts-fallback.img >>> -rw------- 1 root root? 16M Aug? 8 14:33 /boot/initramfs-linux-lts.img >>> -rw------- 1 root root? 16M Aug? 8 14:34 /boot/initramfs-linux.img >>> >>> artist >> >> Thanks @artist, btw, by changing: >> >>> #COMPRESSION_OPTIONS=() >> >> to: >> >>> COMPRESSION_OPTIONS=(--long --ultra -22) >> >> and by changing: >> >>> #MODULES_DECOMPRESS="no" >> >> to: >> >>> MODULES_DECOMPRESS="yes" >> >> doesn't really gain much, but at least gets me out of the 90+% usage: >> >>> % df -h /boot/ >>> Filesystem????? Size? Used Avail Use% Mounted on >>> /dev/nvme0n1p2? 290M? 216M?? 55M? 80% /boot >> >> And now: >> >>> % du -hs /boot/* >>> 14M???? /boot/grub >>> 902K??? /boot/grub-common >>> 159M??? /boot/initramfs-linux-fallback.img >>> 14M???? /boot/initramfs-linux.img >>> 13M???? /boot/intel-ucode.img >>> du: cannot read directory '/boot/lost+found': Permission denied >>> 12K???? /boot/lost+found >>> 154K??? /boot/memtest86+ >>> 16M???? /boot/vmlinuz-linux >> >> The initrd backup is still big...? So perhaps time to look for booster or dracut, whatever gives smaller images, :)? I see the linux image at a reasonable size, 16M Roy, not sure why you mentioned 67M, perhaps you're using something different than the "linux" package? >> >>> % uname -a >>> Linux m1 6.16.1-artix1-1 #1 SMP PREEMPT_DYNAMIC Fri, 15 Aug 2025 23:14:52 +0000 x86_64 GNU/Linux >> >> >> Thanks a lot @artis ! Besides my prior fallback question (no idea how you got it with booster) I can report that it's impressively smaller, and it generates in no time: > % ls -l /boot/*.img > -rw-r--r-- 1 root root 6.2M Aug 18 21:02 /boot/booster-linux.img > -rw------- 1 root root 159M Aug 18 19:02 /boot/initramfs-linux-fallback.img > -rw------- 1 root root 14M Aug 18 18:59 /boot/initramfs-linux.img > -rw-r--r-- 1 root root 13M Aug 12 15:24 /boot/intel-ucode.img I'm a bit hesitant given the lack of fallback. Actually mkinicpio is bad given the fallback. Without it (it can be removed from the mkinitcpio presets) the default image more then doubles the booster one (14M vs. 6.2M) but it's still reasonable, the current fallback size is not. Unfortunately grub-mkconfig pushes the default mkinitcpio preset image as the item not requiring a sub-menu (I guess that can be changed on /etc/grub.d/10_linux). For now I can just copy the one created under the submenu out of it... Now I found a problem, as I'm using a "la-latin1" keyboard I need the booster "vconsole" flag set to true to make my life a bit easier given special chars, however I can't include that flag since if I do when loading the image I just get a note to hit "enter" to reboot, :( I guess I'm hitting this: https://github.com/anatol/booster/issues/234 (vconsole: true blocks booting w/ booster exit status 71) I use terminus on console/tty (I used it on terminal emulator before until finding ttf-iosevkaterm-nerd)... Not that I couldn't live without vconsole, but it's sort of handy to refer to the keyboard on its own layout, :) But I'm happy to see the size decrease, and also how fast it is... -- Javier From artist at artixlinux.org Tue Aug 19 10:34:22 2025 From: artist at artixlinux.org (artist) Date: Tue, 19 Aug 2025 10:34:22 +0200 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: <613d3027-bb1e-4142-b096-213c730c7e84@e.email> References: <85221e37-f3bd-4202-8cd5-c5ffc4204494@e.email> <4a79828f-bc96-4515-8b26-cee9b52ea4e0@artixlinux.org> <613d3027-bb1e-4142-b096-213c730c7e84@e.email> Message-ID: <4ab44b90-495c-44ac-b973-1eaf8a3b081d@artixlinux.org> For the fallback I use command: booster build --universal --force /boot/booster-linux-fallback.img I haven't checked the docs on this but it seems to work similar when I used it. artist On 8/19/25 07:10, Javier wrote: > On 2025-08-18 00:56 PM, artist wrote: >> Another advantage of booster is that it is a lot faster. >> >> artist >> >> On 8/18/25 20:29, Javier wrote: >>> On 2025-08-18 00:13 PM, artist wrote: >>>> To preserve space you might also have a look at switching from >>>> mkinitcpio too booster. >>>> ?From a test box: >>>> % ls -lh /boot/*.img >>>> -rw-r--r-- 1 root root? 24M Aug? 8 14:34 >>>> /boot/booster-linux-fallback.img >>>> -rw-r--r-- 1 root root? 25M Jul 27 17:13 >>>> /boot/booster-linux-lts-fallback.img >>>> -rw-r--r-- 1 root root 4.8M Jul 27 17:13 /boot/booster-linux-lts.img >>>> -rw-r--r-- 1 root root 6.0M Aug? 8 14:34 /boot/booster-linux.img >>>> -rw------- 1 root root? 48M Aug? 8 14:34 >>>> /boot/initramfs-linux-fallback.img >>>> -rw------- 1 root root? 49M Aug? 8 14:34 >>>> /boot/initramfs-linux-lts-fallback.img >>>> -rw------- 1 root root? 16M Aug? 8 14:33 /boot/initramfs-linux-lts.img >>>> -rw------- 1 root root? 16M Aug? 8 14:34 /boot/initramfs-linux.img >>>> >>>> artist >>> >>> Thanks @artist, btw, by changing: >>> >>>> #COMPRESSION_OPTIONS=() >>> >>> to: >>> >>>> COMPRESSION_OPTIONS=(--long --ultra -22) >>> >>> and by changing: >>> >>>> #MODULES_DECOMPRESS="no" >>> >>> to: >>> >>>> MODULES_DECOMPRESS="yes" >>> >>> doesn't really gain much, but at least gets me out of the 90+% usage: >>> >>>> % df -h /boot/ >>>> Filesystem????? Size? Used Avail Use% Mounted on >>>> /dev/nvme0n1p2? 290M? 216M?? 55M? 80% /boot >>> >>> And now: >>> >>>> % du -hs /boot/* >>>> 14M???? /boot/grub >>>> 902K??? /boot/grub-common >>>> 159M??? /boot/initramfs-linux-fallback.img >>>> 14M???? /boot/initramfs-linux.img >>>> 13M???? /boot/intel-ucode.img >>>> du: cannot read directory '/boot/lost+found': Permission denied >>>> 12K???? /boot/lost+found >>>> 154K??? /boot/memtest86+ >>>> 16M???? /boot/vmlinuz-linux >>> >>> The initrd backup is still big...? So perhaps time to look for >>> booster or dracut, whatever gives smaller images, :)? I see the >>> linux image at a reasonable size, 16M Roy, not sure why you >>> mentioned 67M, perhaps you're using something different than the >>> "linux" package? >>> >>>> % uname -a >>>> Linux m1 6.16.1-artix1-1 #1 SMP PREEMPT_DYNAMIC Fri, 15 Aug 2025 >>>> 23:14:52 +0000 x86_64 GNU/Linux >>> >>> >>> Thanks a lot @artis ! > > Besides my prior fallback question (no idea how you got it with > booster) I can report that it's impressively smaller, and it generates > in no time: > >> % ls -l /boot/*.img >> -rw-r--r-- 1 root root 6.2M Aug 18 21:02 /boot/booster-linux.img >> -rw------- 1 root root 159M Aug 18 19:02 >> /boot/initramfs-linux-fallback.img >> -rw------- 1 root root? 14M Aug 18 18:59 /boot/initramfs-linux.img >> -rw-r--r-- 1 root root? 13M Aug 12 15:24 /boot/intel-ucode.img > > I'm a bit hesitant given the lack of fallback.? Actually mkinicpio is > bad given the fallback.? Without it (it can be removed from the > mkinitcpio presets) the default image more then doubles the booster > one (14M vs. 6.2M) but it's still reasonable, the current fallback > size is not. > > Unfortunately grub-mkconfig pushes the default mkinitcpio preset image > as the item not requiring a sub-menu (I guess that can be changed on > /etc/grub.d/10_linux).? For now I can just copy the one created under > the submenu out of it... > > Now I found a problem, as I'm using a "la-latin1" keyboard I need the > booster "vconsole" flag set to true to make my life a bit easier given > special chars, however I can't include that flag since if I do when > loading the image I just get a note to hit "enter" to reboot, :(? I > guess I'm hitting this: > > https://github.com/anatol/booster/issues/234 (vconsole: true blocks > booting w/ booster exit status 71) > > I use terminus on console/tty (I used it on terminal emulator before > until finding ttf-iosevkaterm-nerd)...? Not that I couldn't live > without vconsole, but it's sort of handy to refer to the keyboard on > its own layout, :) > > But I'm happy to see the size decrease, and also how fast it is... > From je-vv at e.email Wed Aug 20 12:15:42 2025 From: je-vv at e.email (Javier) Date: Wed, 20 Aug 2025 04:15:42 -0600 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: <4ab44b90-495c-44ac-b973-1eaf8a3b081d@artixlinux.org> References: <85221e37-f3bd-4202-8cd5-c5ffc4204494@e.email> <4a79828f-bc96-4515-8b26-cee9b52ea4e0@artixlinux.org> <613d3027-bb1e-4142-b096-213c730c7e84@e.email> <4ab44b90-495c-44ac-b973-1eaf8a3b081d@artixlinux.org> Message-ID: <8ce0f015-79a6-43bc-b60b-101d3f5e87d4@e.email> On 2025-08-19 02:34 AM, artist wrote: > For the fallback I use command: > > booster build --universal --force /boot/booster-linux-fallback.img > > I haven't checked the docs on this but it seems to work similar when I used it. > > artist Thanks for sharing @artis ! And sorry for late answer. tl;dr: The man page sort confirms your use, there a few not so nice things which don't prevent its usage, see the end for them. And 37M with "universal" looks good compared to ~150M: > % ls -l /boot/booster-linux*.img > -rw-r--r-- 1 root root 37M Aug 20 03:20 /boot/booster-linux-fallback.img > -rw-r--r-- 1 root root 6.2M Aug 20 03:20 /boot/booster-linux.img What "--universal" adds, according to the booster man page, is: > --universal Add wide range of modules/tools to allow this image boot at different machines. It can as well be set in the config file, but that's not what one wants: > universal is a boolean flag that tells booster to generate a universal image. By default booster generates a host-specific image that includes kernel modules used at the current host. For example if the host does not have a TPM2 chip then tpm modules are ignored. Universal image includes many kernel modules and tools that might be needed at a broad range of hardware configurations. Not sure if similar in nature to the fallback mkinitcpio generated images, but for sure more than when not applying "--universal". As for fallback if looking at "linux.preset" one realizes that for the fallback image generation the "-S autodetect" flag is the only thing added, which according to the mkinitcpio man page: > -S, --skiphooks hooks > Skip hooks when generating the image. Multiple hooks should be comma-separated. This option can be specified multiple times. means removing the "autodetect" hook. This hook is what allows the default image to be way shorter than the fallback one, since: > % mkinitcpio -H autodetect > ==> Help for hook 'autodetect': > This hook shrinks your initramfs to a smaller size by autodetecting the needed > modules. Be sure to verify included modules are correct and none are missing. > This hook must be run before other subsystem hooks in order to take advantage > of auto-detection. Any hooks placed before 'autodetect' will be installed in > full. As mentioned before, although the default mkinitcpio image is a bit more than twice as much the default booster image, it has a reasonable size of 14M, nothing particularly concerning. So that's pretty much OK. What got really big is the fallback mkinitcpio image. And as "mkinitcpio" hadn't change recently that I'm aware of, but linux (the kernel) has, it might be now artix is building more modules than before, or that linux added a bunch of new stuff that artix decided to build as modules, and now mkinitcpio is finding those bunch of modules. Or it might be a bunch of pre existent modules on prior versions of linux were renamed (I believe this is not possible given linux policies to not change anything if it's not broken or without a good reason). The thing is that if not trying to auto detect the needing modules, mkinitcpio is most probably adding a bunch of unneeded stuff which most probably it was not adding before. But all in all, although removing the "autodetect" hook on mkinitcpio might not be 1:1 equivalent to adding the flag "universal" to booster, since booster seems to be more effective on filtering out not needed stuff, and even with the "universal" flag there seems to be some reasoning on which might be the modules required on different machines for the specific linux version, and not just selecting every module found. So I'm convinced with booster. The sad thing is that I believe booster by being written in go can support only x86 and arm (which to be honest covers what artix does, but it doesn't seem to be hope in the horizon for risc-v. Now the not so nice things: - Missing a pacman hook and the helper to generate the booster fallback image when in need. The option is to whether modify the current scripts (which will get overwritten on booster upgrades), or creating new separate scripts while not available. It'd be nice if artix would include it in both scripts, "regenerate_images" and "booster-install" and with the same command as the non fallback one. I'm inclined to modify them both, and have and old copy of both to copare them in case of changes. - Not nicely integrated with "grub-mkconfig". See: https://github.com/anatol/booster/issues/29. The best work around, though still not perfect, is https://github.com/anatol/booster/issues/29#issuecomment-1148497160, which consists on modifying "/etc/grub.d/10_linux" to properly identify booster images as "initrd_real" ones, but that is not enough, pretty close. I had to also remove the booster particular entry detection at bottom so that the booster image doesn't get duplicated, and instead a detection entry for the booster fallback image and add it as a "fallback" entry. With all that grub-mkconfig works wonders, at least as I'd expect it. It'd be nice if artix would add "booster-${version}.img" "booster-${alt_version}.img" into that array, which is what I did, although most probably they'll get overwritten as well. It would be even nicer if that would be adopted upstream, but I don't even know if upstream is arch, grub, or what else... See PS for a snapshot of the final grub.cfg I got... So far all these changes might get overwritten upon upgrade. I do have copies on "mine" sub-dirs though. - Non default keyboard layers are impacted by not being able to use the vconsole flag as I already mentioned, see https://github.com/anatol/booster/issues/234. For this there's no work around unfortunately, but one can live with it if having whether a numpad or if one knows what the en-us mapping layout is even though the keyboard one is different. - Booster is a world package, so not treated exactly the same as mkinitcpio which is a system package. The good thing is that although a system package mkinitcpio can be removed, but I'm not sure if there's a difference in upgrades urgency or things like that given the difference. - Written in Go, which I find uncommon for system software such as this. I just have to deal with it, :) - I prefer GPL license and even more if GPL+ or AGPL+, dracut-ng has a GPL-2 one which although not GPL3 at least I'd prefer it to MIT which is not bad but not GPL, but ohh well, dracut is not as simple and probably to get it to the nice small footprint of booster several modules configurations would be needed I guess, and it won't ever match the booster speed on generation I'd guess, and its main advantage is being written in C. I'm sticking with booster any ways. Once again @artis, many thanks ! -- Javier PS: My final gub.cfg after my changes on grub.d/10_linux... > ### BEGIN /etc/grub.d/10_linux ### > menuentry 'Artix Local GNU + Linux' --class artix --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-6767f8c9-a707-4ec2-ab2b-13d6532c9a03' { > load_video > insmod gzio > insmod part_gpt > insmod ext2 > search --no-floppy --fs-uuid --set=root f0e4d553-eb92-4fa6-bf02-cc183fdeb586 > echo 'Loading Linux linux ...' > linux /vmlinuz-linux root=UUID=6767f8c9-a707-4ec2-ab2b-13d6532c9a03 rw rootwait rootfstype=ext4 rootflags=commit=60,discard cryptdevice=UUID=cbfdfff2-af60-46b1-b29b-df0e5667c108:root:allow-discards,no-read-workqueue,no-write-workqueue rd.luks.options=discard,no-read-workqueue,no-write-workqueue rd.luks.name=cbfdfff2-af60-46b1-b29b-df0e5667c108=root nouveau.config=NvGspRm=1 resume=UUID=6767f8c9-a707-4ec2-ab2b-13d6532c9a03 resume_offset=4161536 iommu=pt intel_iommu=on loglevel=3 quiet > echo 'Loading initial ramdisk ...' > initrd /intel-ucode.img /booster-linux.img > } > submenu 'Advanced options for Artix Local GNU + Linux' $menuentry_id_option 'gnulinux-advanced-6767f8c9-a707-4ec2-ab2b-13d6532c9a03' { > menuentry 'Artix Local GNU + Linux, with Linux linux' --class artix --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-6767f8c9-a707-4ec2-ab2b-13d6532c9a03' { > load_video > insmod gzio > insmod part_gpt > insmod ext2 > search --no-floppy --fs-uuid --set=root f0e4d553-eb92-4fa6-bf02-cc183fdeb586 > echo 'Loading Linux linux ...' > linux /vmlinuz-linux root=UUID=6767f8c9-a707-4ec2-ab2b-13d6532c9a03 rw rootwait rootfstype=ext4 rootflags=commit=60,discard cryptdevice=UUID=cbfdfff2-af60-46b1-b29b-df0e5667c108:root:allow-discards,no-read-workqueue,no-write-workqueue rd.luks.options=discard,no-read-workqueue,no-write-workqueue rd.luks.name=cbfdfff2-af60-46b1-b29b-df0e5667c108=root nouveau.config=NvGspRm=1 resume=UUID=6767f8c9-a707-4ec2-ab2b-13d6532c9a03 resume_offset=4161536 iommu=pt intel_iommu=on loglevel=3 quiet > echo 'Loading initial ramdisk ...' > initrd /intel-ucode.img /booster-linux.img > } > menuentry 'Artix Local GNU + Linux, with Linux linux (fallback initramfs)' --class artix --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-fallback-6767f8c9-a707-4ec2-ab2b-13d6532c9a03' { > load_video > insmod gzio > insmod part_gpt > insmod ext2 > search --no-floppy --fs-uuid --set=root f0e4d553-eb92-4fa6-bf02-cc183fdeb586 > echo 'Loading Linux linux ...' > linux /vmlinuz-linux root=UUID=6767f8c9-a707-4ec2-ab2b-13d6532c9a03 rw rootwait rootfstype=ext4 rootflags=commit=60,discard cryptdevice=UUID=cbfdfff2-af60-46b1-b29b-df0e5667c108:root:allow-discards,no-read-workqueue,no-write-workqueue rd.luks.options=discard,no-read-workqueue,no-write-workqueue rd.luks.name=cbfdfff2-af60-46b1-b29b-df0e5667c108=root nouveau.config=NvGspRm=1 resume=UUID=6767f8c9-a707-4ec2-ab2b-13d6532c9a03 resume_offset=4161536 iommu=pt intel_iommu=on loglevel=3 quiet > echo 'Loading initial ramdisk ...' > initrd /intel-ucode.img /booster-linux-fallback.img > } > menuentry 'Artix Local GNU + Linux, with Linux linux (recovery mode)' --class artix --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-recovery-6767f8c9-a707-4ec2-ab2b-13d6532c9a03' { > load_video > insmod gzio > insmod part_gpt > insmod ext2 > search --no-floppy --fs-uuid --set=root f0e4d553-eb92-4fa6-bf02-cc183fdeb586 > echo 'Loading Linux linux ...' > linux /vmlinuz-linux root=UUID=6767f8c9-a707-4ec2-ab2b-13d6532c9a03 rw single rootwait rootfstype=ext4 rootflags=commit=60,discard cryptdevice=UUID=cbfdfff2-af60-46b1-b29b-df0e5667c108:root:allow-discards,no-read-workqueue,no-write-workqueue rd.luks.options=discard,no-read-workqueue,no-write-workqueue rd.luks.name=cbfdfff2-af60-46b1-b29b-df0e5667c108=root nouveau.config=NvGspRm=1 > echo 'Loading initial ramdisk ...' > initrd /intel-ucode.img /booster-linux-fallback.img > } > } > > ### END /etc/grub.d/10_linux ### From je-vv at e.email Wed Aug 20 12:51:18 2025 From: je-vv at e.email (Javier) Date: Wed, 20 Aug 2025 04:51:18 -0600 Subject: [artix-general] Kernel 6.16.1 In-Reply-To: <8ce0f015-79a6-43bc-b60b-101d3f5e87d4@e.email> References: <85221e37-f3bd-4202-8cd5-c5ffc4204494@e.email> <4a79828f-bc96-4515-8b26-cee9b52ea4e0@artixlinux.org> <613d3027-bb1e-4142-b096-213c730c7e84@e.email> <4ab44b90-495c-44ac-b973-1eaf8a3b081d@artixlinux.org> <8ce0f015-79a6-43bc-b60b-101d3f5e87d4@e.email> Message-ID: On 2025-08-20 04:15 AM, Javier wrote: > On 2025-08-19 02:34 AM, artist wrote: >> For the fallback I use command: >> >> booster build --universal --force /boot/booster-linux-fallback.img >> >> I haven't checked the docs on this but it seems to work similar when I used it. >> >> artist Ups, minor fix: only adding "booster-${version}.img" to the "initrd_real" images to get detected, not the "booster-${alt_version}.img" on the grub-mkconfig WA below... > > Thanks for sharing @artis !? And sorry for late answer. > > tl;dr:? The man page sort confirms your use, there a few not so nice things which don't prevent its usage, see the end for them.? And 37M with "universal" looks good compared to ~150M: > >> % ls -l /boot/booster-linux*.img >> -rw-r--r-- 1 root root? 37M Aug 20 03:20 /boot/booster-linux-fallback.img >> -rw-r--r-- 1 root root 6.2M Aug 20 03:20 /boot/booster-linux.img > > What "--universal" adds, according to the booster man page, is: > >> --universal Add wide range of modules/tools to allow this image boot at different machines. > > It can as well be set in the config file, but that's not what one wants: > >> universal? is? a? boolean flag that tells booster to generate a universal image. By default booster generates a host-specific image that includes kernel modules used at the current host. For example if the host does not have a TPM2 chip then tpm modules are ignored. Universal image includes many kernel modules and tools that might be needed at a broad range of hardware configurations. > > Not sure if similar in nature to the fallback mkinitcpio generated images, but for sure more than when not applying "--universal". > > As for fallback if looking at "linux.preset" one realizes that for the fallback image generation the "-S autodetect" flag is the only thing added, which according to the mkinitcpio man page: > >> ?????? -S, --skiphooks hooks >> ?????????? Skip hooks when generating the image. Multiple hooks should be comma-separated. This option can be specified multiple times. > > means removing the "autodetect" hook.? This hook is what allows the default image to be way shorter than the fallback one, since: > >> % mkinitcpio -H autodetect >> ==> Help for hook 'autodetect': >> This hook shrinks your initramfs to a smaller size by autodetecting the needed >> modules. Be sure to verify included modules are correct and none are missing. >> This hook must be run before other subsystem hooks in order to take advantage >> of auto-detection.? Any hooks placed before 'autodetect' will be installed in >> full. > > As mentioned before, although the default mkinitcpio image is a bit more than twice as much the default booster image, it has a reasonable size of 14M, nothing particularly concerning.? So that's pretty much OK.? What got really big is the fallback mkinitcpio image.? And as "mkinitcpio" hadn't change recently that I'm aware of, but linux (the kernel) has, it might be now artix is building more modules than before, or that linux added a bunch of new stuff that artix decided to build as? modules, and now mkinitcpio is finding those bunch of modules.? Or it might be a bunch of pre existent modules on prior versions of linux were renamed (I believe this is not possible given linux policies to not change anything if it's not broken or without a good reason).? The thing is that if not trying to auto detect the needing modules, mkinitcpio is most probably adding a bunch of unneeded stuff which most probably it was not adding before. > > But all in all, although removing the "autodetect" hook on mkinitcpio might not be 1:1 equivalent to adding the flag "universal" to booster, since booster seems to be more effective on filtering out not needed stuff, and even with the "universal" flag there seems to be some reasoning on which might be the modules required on different machines for the specific linux version, and not just selecting every module found. > > So I'm convinced with booster.? The sad thing is that I believe booster by being written in go can support only x86 and arm (which to be honest covers what artix does, but it doesn't seem to be hope in the horizon for risc-v. > > Now the not so nice things: > > - Missing a pacman hook and the helper to generate the booster fallback image when in need.? The option is to whether modify the current scripts (which will get overwritten on booster upgrades), or creating new separate scripts while not available.? It'd be nice if artix would include it in both scripts, "regenerate_images" and "booster-install" and with the same command as the non fallback one.? I'm inclined to modify them both, and have and old copy of both to copare them in case of changes. > > - Not nicely integrated with "grub-mkconfig".? See: https://github.com/anatol/booster/issues/29.? The best work around, though still not perfect, is https://github.com/anatol/booster/issues/29#issuecomment-1148497160, which consists on modifying "/etc/grub.d/10_linux" to properly identify booster images as "initrd_real" ones, but that is not enough, pretty close.? I had to also remove the booster particular entry detection at bottom so that the booster image doesn't get duplicated, and instead a detection entry for the booster fallback image and add it as a "fallback" entry.? With all that grub-mkconfig works wonders, at least as I'd expect it.? It'd be nice if artix would add "booster-${version}.img" into that array, which is what I did, although most probably they'll get overwritten as well.? It would be even nicer if that would be adopted upstream, but I don't even know if upstream is arch, grub, or what else...? See PS for a snapshot of the > final grub.cfg I got...? So far all these changes might get overwritten upon upgrade.? I do have copies on "mine" sub-dirs though. > > - Non default keyboard layers are impacted by not being able to use the vconsole flag as I already mentioned, see https://github.com/anatol/booster/issues/234.? For this there's no work around unfortunately, but one can live with it if having whether a numpad or if one knows what the en-us mapping layout is even though the keyboard one is different. > > - Booster is a world package, so not treated exactly the same as mkinitcpio which is a system package.? The good thing is that although a system package mkinitcpio can be removed, but I'm not sure if there's a difference in upgrades urgency or things like that given the difference. > > - Written in Go, which I find uncommon for system software such as this.? I just have to deal with it, :) > > - I prefer GPL license and even more if GPL+ or AGPL+, dracut-ng has a GPL-2 one which although not GPL3 at least I'd prefer it to MIT which is not bad but not GPL, but ohh well, dracut is not as simple and probably to get it to the nice small footprint of booster several modules configurations would be needed I guess, and it won't ever match the booster speed on generation I'd guess, and its main advantage is being written in C.? I'm sticking with booster any ways. > > Once again @artis, many thanks ! > -- Javier