Requests for current-next (15.0-->15.1)

marav · 10-27-2023, 10:44 PM

gexiv2 needs to be recompiled against exiv2

https://www.linuxquestions.org/quest...0/#post6461306

This, broke gimp and xsane

baldzhang · 10-28-2023, 12:21 AM

Code:

Fri Oct 13 20:51:23 UTC 2023
a/xfsprogs-6.5.0-x86_64-1.txz: Upgraded.

man page of mkfs.xfs said nrext64 will assumed 1 if omitted, after mount a xfs fs formatted with this version on kernel 6.1.60, dmesg will print

Code:

[  308.358673] XFS (sda3): EXPERIMENTAL Large extent counts feature in use. Use at your own risk!
[  308.359082] XFS (sda3): Mounting V5 Filesystem
[  308.393870] XFS (sda3): Ending clean mount

could be re-produced with slackware64-live-current/2023-10-27

xfs_info output:

Code:

meta-data=/dev/sda3              isize=512    agcount=4, agsize=3112895 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=1
         =                       reflink=1    bigtime=1 inobtcount=1 nrext64=1
data     =                       bsize=4096   blocks=12451579, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

henca · 10-28-2023, 05:04 AM

Quote:

Originally Posted by ZhaoLin1457

Can someone smarter than me explain for what the huge kernel is good at this moment?

I would say that the explanation is not in the name "huge", but in its extension ".s". Once there was a number of kernels to choose from, most people which only had an IDE drive did choose the "bare.i" kernel, then there was also a number of rather minimalistic kernels called things like "advansys.s", "aha1542.s" and so on which each added only support for a single or very few SCSI cards. To simplify things all those SCSI drivers went into the same "huge.s".

regards Henrik

lonestar_italy · 10-28-2023, 07:30 AM

Personally I'm not pleased for this change with the generic kernel.
I've always used it with the goal of minimizing the kernel footprint with the removal of anything that is not in use in my hardware setup.

I see some have shown that the change added about 5-6MB, which could be considered irrelevant. But being given the choice I would go for removing 5-6MB more from the total kernel memory usage rather than adding them.

Also I do happen to create VMs with 512MB of memory where such differences can matter.

Of course I can compile my own kernels with the settings I like, which is something I'll probably go back to do.

That's it, just so that nobody can say "oh but nobody complained on LQ" :-D

marav · 10-28-2023, 07:52 AM

Quote:

Originally Posted by lonestar_italy

with the removal of anything that is not in use in my hardware setup.

That's what we call a personal kernel, or a custom kernel. Not a generic kernel
As far as possible, a generic kernel should be suitable for all hardware and for all users

Didier Spaier · 10-28-2023, 08:44 AM

Quote:

Originally Posted by marav

I'm pretty sure that these generic kernels, which are now capable of booting without initrd, are not primarily designed for advanced users who deal with Lucks in Slackware. But much more so for standard users who experience boot issues after a kernel update

Quote:

Originally Posted by pghvlaans

Piggybacking off of Didier's comment: now that booting without initrd is the expected case, grub-mkconfig should probably default to using the device name instead of UUID. In etc.default.grub:

Code:

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
  GRUB_DISABLE_LINUX_UUID=true

Then, what if the system lands in uncharted territory, or is just installed in a removable device whose name can vary? Is this not allowed to standard users? So, there still remain not so uncommon use cases where an initramfs is necessary. This notwithstanding I assume that the new generic kernel will help users who just forget to build one so I have nothing to say against this change.

Anyway I am not really in concern as Slint doesn't ship a huge kernel since version 15.0 and builds an initramfs associated to each kernel just after its installation (the kernel has been upgraded at least 22 times for slint64-15.0 since its release, without anyone complaining "The system can't boot after a kernel upgrade!" but I digress, sorry).

As an aside, the UUID is not enough to know where to mount / in case of a btrfs subvolume, as it is shared by other subvolumes like for instance for /home, fortunately grub can take care of that, with a command line like:

Code:

BOOT_IMAGE=/@/boot/vmlinuz-6.1.60 root=UUID=814caaa2-ab8e-44e4-b1cb-2e7a58e04a0b ro rootflags=subvol=@ rootdelay=10

marav · 10-28-2023, 09:32 AM

Quote:

Originally Posted by Didier Spaier

Is this not allowed to standard users?

This is not a question of if they are allowed or not
Standard users use standard features, by "standard" I mean "out of the box" features

So no, for me removable device boot, luks or whatever you want that's not related to Slackware-HOWTO is non-standard

marav · 10-28-2023, 09:33 AM

@Pat
Maybe you could change this :-)

Code:

generic.s   The trimmed down, more modular version of huge.s. Found on
            the system as:
              /boot/vmlinuz-generic-5.15.19
            This also requires using an initrd.

http://ftp.slackware.com/pub/slackwa...lackware-HOWTO

glennmcc · 10-28-2023, 12:45 PM

Thank you Pat,

This new larger generic kernel works perfectly without an initrd on this circa 1997 P-II, 266Mhz, 512MB RAM, 40gig IDE/PATA HDD.

IMO, It's a keeper for 15.1 and beyond.

volkerdi · 10-28-2023, 01:02 PM

Quote:

Originally Posted by lostintime

FWIW observation:

The new changes to the generic kernel now means the df command lists the system partition as /dev/root rather than /dev/sdXY, despite there being no /dev/root device node. The /etc/mtab file (sym link to /proc/mounts) shows /dev/root.

The mount command is unaffected.

Continuing to use an initrd avoids the /dev/root issue with the system partition being listed as /dev/sdXY.

Ah yes, I remember that problem. We used to solve it when booting a system without an initrd by building /etc/mtab to contain the correct root device. But mount doesn't support mtab any longer, so if you boot without an initrd you're stuck with that issue.

I never changed my recommendation to use generic + initrd and don't plan to change any documentation regarding that. I just noted that it'll probably work better for that than the huge kernel did since the modules match the kernel better, and several footbullets have been unloaded.

glennmcc · 10-28-2023, 02:04 PM

Quote:

Originally Posted by lostintime

FWIW observation:

The new changes to the generic kernel now means the df command lists the system partition as /dev/root rather than /dev/sdXY, despite there being no /dev/root device node. The /etc/mtab file (sym link to /proc/mounts) shows /dev/root.

The mount command is unaffected.

Continuing to use an initrd avoids the /dev/root issue with the system partition being listed as /dev/sdXY.

FWIW,

It's the same in 15.0 booted to the huge kernel.

Both df & /etc/mtab show /dev/root, mount shows /dev/sda1

IMO, this is not a 'problem' because any sysadmin will know which /dev/sdXY is /

Anyone who does not know it is not the sysadmin therefore has no reason to know it.

lostintime · 10-28-2023, 03:03 PM

Quote:

Ah yes, I remember that problem.

I remembered too, which I is why I posted. I seem to remember you saying there was little anybody could do except use an initrd. I posted only so folks would know the difference.

Quote:

IMO, this is not a 'problem' because any sysadmin will know which /dev/sdXY is /

I posted an observation, not a complaint.

That said, the /dev/root concept is -- silly, but not a hill I'm going to die on.

SCerovec · 10-28-2023, 03:05 PM

I would politely ask for gtkmm4-4.4.0 or newer to get included into current.

Next to it i would like to see cairomm-1.16 or newer and mm-common-1.0.0 or newer updated there too.

I ask for because i'm trying to build a novel CAD program on 15.0 and there is little chance i upgrade all this dependencies and not break the rest of the system.

The program in question is Dune 3D, a very fresh drop in replacement for the venerable and dreaded Free CAD.

Dune 3D can be found on github: https://github.com/dune3d/dune3d should any fellow Slacker have the need for a more accessible CAD suite.

@BDFL: Take care Pat, and God speed

franzen · 10-28-2023, 03:12 PM

vid.stab 1.1.1
https://github.com/georgmartius/vid....b-1.1.1.tar.gz

franzen · 10-28-2023, 03:40 PM

Quote:

Originally Posted by glennmcc

This new larger generic kernel works perfectly without an initrd on this circa 1997 P-II, 266Mhz, 512MB RAM, 40gig IDE/PATA HDD.
IMO, It's a keeper for 15.1 and beyond.

While this is nice to know, i hope the 32bit tree will not be a keeper for 15.1 and beyond(in the hope it saves some time for Pat).