SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Regarding MariaDB and user friendliness: any chance a reminder for users to run "mysql_upgrade" command[1] or related instructions after MariaDB is updated (in a similar fashion to run lilo after new kernel)? Maybe other tools out there too require similar manual steps?
Better to refer to a somewhat more relevant page like https://mariadb.com/kb/en/upgrading/ ? You point to MySQL 8.0 documentation but Slackware switched from MySQL 5.x to MariaDB 5.x eight years ago and Slackware 14.2 is now at 10.0.
But indeed, upgrading from Slackware 14.2 to 15.0 will require some careful reading of that page I linked, since the upgrade will probably not be trivial for anyone who makes serious use of this SQL database server. It cost me quite some headaches and an export/re-import of all my data to migrate to -current.
Better to refer to a somewhat more relevant page like https://mariadb.com/kb/en/upgrading/ ? You point to MySQL 8.0 documentation but Slackware switched from MySQL 5.x to MariaDB 5.x eight years ago and Slackware 14.2 is now at 10.0.
But indeed, upgrading from Slackware 14.2 to 15.0 will require some careful reading of that page I linked, since the upgrade will probably not be trivial for anyone who makes serious use of this SQL database server. It cost me quite some headaches and an export/re-import of all my data to migrate to -current.
I agree 100% with using relevant information, however as you mention, the export/re-import is not covered on the MariaDB KB pages, whereas the steps on the MySQL 8 are still applicable. Now, there may be better directions - I’m no database expert myself. Perhaps those who are already know what needs to be done whenever they see an upgrade to their most beloved tool. Or perhaps one can chime in with the right place to point. My intention is towards folks who have simple database based apps that all of a sudden begin to misbehave, with a fix being something that takes a couple seconds and could be easily pointed out.
The message “don’t forget to run lilo” is my reference point. In theory, one can crash his/her own system by not updating the boot loader with the new kernel before rebooting. Whereas other distros run things and rebuild your initrd/boot loader, Slackware only notifies the user. So to keep within this alignment, my suggestion was about adding another set of reminders whenever applicable - perhaps a simple “consult the documentation on how to upgrade MariaDB database files” reminder/hint message would suffice.
The message “don’t forget to run lilo” is my reference point. In theory, one can crash his/her own system by not updating the boot loader with the new kernel before rebooting. Whereas other distros run things and rebuild your initrd/boot loader, Slackware only notifies the user. So to keep within this alignment, my suggestion was about adding another set of reminders whenever applicable - perhaps a simple “consult the documentation on how to upgrade MariaDB database files” reminder/hint message would suffice.
That's not the same situation. lilo needs to be run any time the kernel is updated. mysql_upgrade only needs to run on mariadb minor version bumps, not patch level bumps. This is something that squarely falls into the responsibility of the admin.
I think they forgot to mention the changes to the udev rules that seem to be trying to call out to systemd-run.
I may be wrong (as I am not very familiar with lvm). And this is probably a very (too) simplistic interpretation
but :
69-dm-lvm.rules. L 75
Code:
...
# pvscan will check if this device completes a VG,
# i.e. all PVs in the VG are now present with the
# arrival of this PV. If so, it prints to stdout:
# LVM_VG_NAME_COMPLETE='foo'
#
# When the VG is complete it can be activated, so
# vgchange -aay <vgname> is run. It is run via
# systemd since it can take longer to run than
# udev wants to block when processing rules.
# (if there are hundreds of LVs to activate,
# the vgchange can take many seconds.)
#
# pvscan only reads the single device specified,
# and uses temp files under /run/lvm to check if
# other PVs in the VG are present.
#
# If event_activation=0 in lvm.conf, this pvscan
# (using checkcomplete) will do nothing, so that
# no event-based autoactivation will be happen.
#
# TODO: adjust the output of vgchange -aay so that
# it's better suited to appearing in the journal.
IMPORT{program}="/sbin/lvm pvscan --cache --listvg --checkcomplete --vgonline --udevoutput --journal=output $env{DEVNAME}"
ENV{LVM_VG_NAME_COMPLETE}=="?*", RUN+="/usr/bin/systemd-run -r --no-block --property DefaultDependencies=no --unit lvm-activate-$env{LVM_VG_NAME_COMPLETE} lvm vgchange -aay --nohints $env{LVM_VG_NAME_COMPLETE}"
...
lvm.conf. L 1165
Code:
...
# event_activation = 1
...
So, if we provide a lvm.conf with event_activation = 0
From what I understand, this rule (69-dm-lvm.rules), and more specifically the pvscan, does nothing, right?
Last edited by marav; 11-30-2021 at 12:22 PM.
Reason: typo
Bump for cups-2.4.0. Supposed to be a big release. I just dumped it in the official volderki slackbuild folder and it compiled. I installed it, I uninstalled a printer , installed a printer, printed a test page. Smooth. Maybe testing or extra?
Bump for cups-2.4.0. Supposed to be a big release. I just dumped it in the official volderki slackbuild folder and it compiled. I installed it, I uninstalled a printer , installed a printer, printed a test page. Smooth. Maybe testing or extra?
Many build options are obsolets in the cups.SlackBuild for cups-2.4.0:
Regarding MariaDB and user friendliness: any chance a reminder for users to run "mysql_upgrade" command[1] or related instructions after MariaDB is updated (in a similar fashion to run lilo after new kernel)? Maybe other tools out there too require similar manual steps?
Bug fixes
- Fixed printing of struct bpf_prog_info.map_ids array.
- Fixed behaviour of "dev", "pidfd", and "socket" arguments of the --print-fds
option to no longer imply the "path" argument.
- Fixed insufficient buffer size used for network interface name printing,
that previously led to assertions on attempts of printing interface names
that require quoting, for example, names longer than 4 characters in -xx
mode (addresses RHBZ bug #2028146).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
