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.
ZhaoLin1457 and LuckyCyborg : these patches could help generating a grub.conf from Slackware with its current naming scheme, but do not address the issues when it is generated from another OS installed in the same machine, unless you want to patch also the grub files of these other OS. For this reason I would rather just write a grub.conf and never change it (for users intending to run Slackware only) or adopt the same naming scheme for the kernel and initrd as other distributions, as I already wrote.
I don't think it's a good idea to use another OS to directly boot Slackware or any other operating system. There are always problems and incompatibilities. Therefore, as it was said in this thread, but also in other forums, the best idea is chainloading.
That's why I don't consider booting Slackware from Fedora or etc.
But that's no reason not to have GRUB2 scripts adapted for Slackware. And I wanted to see how complicated it is if they haven't managed to do this in so many years.
And I'm sorry, but I don't believe in "fixed config" and multi-kernel initrd. I build kernels every week, and only fixed is not my grub.cfg. And besides, GRUB2 is not new to me, I've been using it for so many years, and I don't see any advantage in adopting what the people from Slackware want.
In the end, it is enough for the installer to succeed in booting Slackware with GRUB2 and then I know what I have to do.
As I said, I think these choices should be left up to the users. And for that, it is enough for install/doinst.sh from a package containing both kernel and its modules to execute /boot/setup-kernel or whatever they like to call it.
Last edited by ZhaoLin1457; 08-14-2023 at 04:49 PM.
I've had to swap several motherboards recently and purchase a few laptops... Some of them (looking at you Asus) do not have legacy boot and do NOT work well with elilo. I had to put Grub on them (and then they worked).
I'm NOT anti-grub but, as I have stated before, I like 'vanilla' installs and have stuck with Slackware's default (e)lilo for as long as I could.
That being said, elilo hasn't been maintained for years (2015 I think). I welcome Pat's move to Grub and it makes me happy to be able to go back to "vanilla installs" once it becomes official.
Pat, PLEASE get the lilo to Grub switch-over going soon. Such a headache with elilo now.
I will say that I'm going to miss that old lilo boot box... I might make a screen saver out of it.
Based on your patch, I made a patch to add support for managing Slackware kernel flavors.
to disable the use of initrd for huge kernels, use the option:
Code:
GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS="true"
The menu entries for Slackware kernels are like this: "Slackware-15.0 GNU/Linux, with Linux Generic 5.15.118"
Combined with disabling the sub-menus, a flat menu results, similar to that custom script.
Code:
--- 10_linux.new 2021-09-10 21:45:00.000000000 +0300
+++ 10_linux 2023-08-14 23:32:11.601222790 +0300
@@ -84,17 +84,22 @@
os="$1"
version="$2"
type="$3"
- args="$4"
+ flavor="$4"
+ args="$5"
if [ -z "$boot_device_id" ]; then
boot_device_id="$(grub_get_device_id "${GRUB_DEVICE}")"
fi
if [ x$type != xsimple ] ; then
+ niceflavor=
+ if [ "x${flavor}" != xdefault ]; then
+ niceflavor="${flavor^} "
+ fi
case $type in
recovery)
- title="$(gettext_printf "%s, with Linux %s (recovery mode)" "${os}" "${version}")" ;;
+ title="$(gettext_printf "%s, with Linux %s%s (recovery mode)" "${os}" "${niceflavor}" "${version}")" ;;
*)
- title="$(gettext_printf "%s, with Linux %s" "${os}" "${version}")" ;;
+ title="$(gettext_printf "%s, with Linux %s%s" "${os}" "${niceflavor}" "${version}")" ;;
esac
if [ x"$title" = x"$GRUB_ACTUAL_DEFAULT" ] || [ x"Previous Linux versions>$title" = x"$GRUB_ACTUAL_DEFAULT" ]; then
replacement_title="$(echo "Advanced options for ${OS}" | sed 's,>,>>,g')>$(echo "$title" | sed 's,>,>>,g')"
@@ -102,7 +107,7 @@
title_correction_code="${title_correction_code}if [ \"x\$default\" = '$quoted' ]; then default='$(echo "$replacement_title" | grub_quote)'; fi;"
grub_warn "$(gettext_printf "Please don't use old title \`%s' for GRUB_DEFAULT, use \`%s' (for versions before 2.00) or \`%s' (for 2.00 or later)" "$GRUB_ACTUAL_DEFAULT" "$replacement_title" "gnulinux-advanced-$boot_device_id>gnulinux-$version-$type-$boot_device_id")"
fi
- echo "menuentry '$(echo "$title" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-$version-$type-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
+ echo "menuentry '$(echo "$title" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-$version-$type-$flavor-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
else
echo "menuentry '$(echo "$os" | grub_quote)' ${CLASS} \$menuentry_id_option 'gnulinux-simple-$boot_device_id' {" | sed "s/^/$submenu_indentation/"
fi
@@ -194,7 +199,6 @@
is_top_level=true
while [ "x$list" != "x" ] ; do
linux=`version_find_latest $list`
- gettext_printf "Found linux image: %s\n" "$linux" >&2
basename=`basename $linux`
dirname=`dirname $linux`
rel_dirname=`make_system_path_relative_to_its_root $dirname`
@@ -202,6 +206,13 @@
alt_version=`echo $version | sed -e "s,\.old$,,g"`
linux_root_device_thisversion="${LINUX_ROOT_DEVICE}"
+ # We will skip the vmlinuz-generic and and vmlinuz-huge which are symlinks
+ if [ "x${version}" = xgeneric ] || [ "x${version}" = xhuge ]; then
+ list=`echo $list | tr ' ' '\n' | fgrep -vx "$linux" | tr '\n' ' '`
+ continue
+ fi
+ gettext_printf "Found linux image: %s\n" "$linux" >&2
+
initrd_early=
for i in ${GRUB_EARLY_INITRD_LINUX_STOCK} \
${GRUB_EARLY_INITRD_LINUX_CUSTOM}; do
@@ -219,6 +230,7 @@
"initramfs-genkernel-${alt_version}" \
"initramfs-genkernel-${GENKERNEL_ARCH}-${version}" \
"initramfs-genkernel-${GENKERNEL_ARCH}-${alt_version}" \
+ "initrd-generic-${version}.gz" "initrd-generic-${version}.img" \
"initrd.gz"; do
if test -e "${dirname}/${i}" ; then
initrd_real="${i}"
@@ -226,6 +238,16 @@
fi
done
+ flavor="default"
+ if echo $basename | grep -wq vmlinuz-huge ; then
+ if [ "x${GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS}" = xyes ]; then
+ initrd_real=
+ fi
+ flavor="huge"
+ elif echo $basename | grep -wq vmlinuz-generic ; then
+ flavor="generic"
+ fi
+
initrd=
if test -n "${initrd_early}" || test -n "${initrd_real}"; then
initrd="${initrd_early} ${initrd_real}"
@@ -284,10 +306,10 @@
is_top_level=false
fi
- linux_entry "${OS}" "${version}" advanced \
+ linux_entry "${OS}" "${version}" advanced "$flavor" \
"${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
if [ "x${GRUB_DISABLE_RECOVERY}" != "xtrue" ]; then
- linux_entry "${OS}" "${version}" recovery \
+ linux_entry "${OS}" "${version}" recovery "$flavor" \
"single ${GRUB_CMDLINE_LINUX}"
fi
Yup! Seems that you did it!
With your patch, looks that the Slackware files are properly handled, and even for the huge kernels gets the early initrds (for CPU microcode) but the base initrd can be skipped.
There may be need to initialize $GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS , but overall works fine. I will make a patch for the grub.SlackbBuild.
So, let's make a grubconfig then!
Starting with the one made by Monsieur Didier. Do you agree?
Last edited by LuckyCyborg; 08-14-2023 at 06:13 PM.
With your patch, looks that the Slackware files are properly handled, and even for the huge kernels gets the early initrds (for CPU microcode) but the base initrd can be skipped.
There may be need to initialize $GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS , but overall works fine. I will make a patch for the grub.SlackbBuild.
Thank you for the appreciations. I'm sure this patch can be improved, but at least in the tests I did, it behaved OK.
Quote:
Originally Posted by LuckyCyborg
So, let's make a grubconfig then!
Starting with the one made by Monsieur Didier. You agree?
Why not? I don't think that that grubconfig is that complicated. A very fine piece of code. Like French cuisine.
I don't think it's a good idea to use another OS to directly boot Slackware or any other operating system. There are always problems and incompatibilities. Therefore, as it was said in this thread, but also in other forums, the best idea is chainloading.
That's why I don't consider booting Slackware from Fedora or etc.
But that's no reason not to have GRUB2 scripts adapted for Slackware. And I wanted to see how complicated it is if they haven't managed to do this in so many years.
I think he means that in a dual boot scenario with these patches, the Slackware install MUST be the one to manage grub, because it relies on its own custom patched 10_linux script to generate its entries properly.
Someone may want to dual boot two linux installations, and want to use the other distro and it's grub package to manage the bootloader instead. Then they have the vanilla 10_linux script and generate the same menu entries as before, or they would need to apply the same patches in that distros install to handle slackware conventions.
It would be nice if the fix didn't affect your ability/choice to manage the bootloader from other os's.
I don't know the ideal fix for this since I'm not a grub expert. Adapting the majority of distro's conventions are one route, though the versioned symlinks seem simplest, no?
I think he means that in a dual boot scenario with these patches, the Slackware install MUST be the one to manage grub, because it relies on its own custom patched 10_linux script to generate its entries properly.
Someone may want to dual boot two linux installations, and want to use the other distro and it's grub package to manage the bootloader instead. Then they have the vanilla 10_linux script and generate the same menu entries as before, or they would need to apply the same patches in that distros install to handle slackware conventions.
It would be nice if the fix didn't affect your ability/choice to manage the bootloader from other os's.
I don't know the ideal fix for this since I'm not a grub expert. Adapting the majority of distro's conventions are one route, though the versioned symlinks seem simplest, no?
I think you are confusing here.
Let me explain what advice you would get if you went to a Fedora forum and asked how to boot Slackware using Fedora's GRUB2 as the master bootloader. They will tell you that the safest solution is to use GRUB2 from Fedora like a boot manager and do "chainloading".
What this means? They will advise you to add in Fedora, in /etc/grub.d/40_custom
And of course, you should update the GRUB2 config.
What does this code do? This code will create a menu item with the name "Slackware Linux 15.0" in Fedora's GRUB2 main menu, which entry will execute GRUB2 for Slackware. From here on, it's up to GRUB2 for Slackware how it does its job.
Using similar snippets, you can run Memtest86+ or the bootloader for Windows 10 . This is called "chainloading" and it is the safest method to multi-boot with GRUB2 and it is used by everyone. When Linux distros are similar, for example Ubuntu with Debian, it is also possible to include another config.
That "os-prober" is an elephant with a giraffe's neck and tail of crock, which never worked well. That's why it's disabled by default in the GRUB2 scripts.
Personally, I think that /etc/grub.d/30_os-prober should have 0644 permissions by default even in Slackware.
Last edited by ZhaoLin1457; 08-14-2023 at 08:31 PM.
Let me explain what advice you would get if you went to a Fedora forum and asked how to boot Slackware using Fedora's GRUB2 as the master bootloader. They will tell you that the safest solution is to use GRUB2 from Fedora like a boot manager and do "chainloading".
What this means? They will advise you to add in Fedora, in /etc/grub.d/40_custom
And of course, you should update the GRUB2 config.
What does this code do? This code will create a menu item with the name "Slackware Linux 15.0" in Fedora's GRUB2 main menu, which entry will execute GRUB2 for Slackware. From here on, it's up to GRUB2 for Slackware how it does its job.
Well, I think this snippet should be like this:
Code:
if [ "${grub_platform}" == "efi" ]; then
menuentry "Slackware Linux 15.0" {
insmod part_gpt
insmod fat
insmod chain
search --no-floppy --set=root --fs-uuid <UUID>
chainloader /EFI/Slackware/grubx64.efi
}
fi
You have forgot to add a guard for platform (because this menuentry does not work on legacy BIOS) and to add GPT partitions support.
BUT, in principle you are right. This chainloading is the safest way to do a multi-boot with GRUB2.
Nothing works better than each OS being booted with its own independent bootloader.
Last edited by LuckyCyborg; 08-14-2023 at 08:54 PM.
However Grub gets enabled, it needs to be automatic. That switch from default huge kernels to generic ones (then requiring manually running mkinitrd) after upgrades almost made me quit Slackware because my many machines started crashing on reboots and I had to search for why it was happening (and then make an ugly update script so I didn't forget about it).
I get the "do it by hand" Slackware way but, there's a trade off between being usable for the masses and being all done by hand for purists. The purist numbers are dwindling.
I notice that the posters in this forum tend to be much older than in other forums and that's because Slackware is (for the most part) NOT attracting new blood. The reason for that is because we are losing people (contributors and users) and it seems to be slipping. The slipping then causes headaches for the current users and scares off new users. The user base goes down and less bugs get reported. Less bugs get reported and it slips more. It's a cycle to oblivion.
EFI support has been a major headache to me and I understand that Slackware developers mostly don't have time for this but, broken EFI is stopping some new adopters. Ubuntu just works with EFI so people are going there.
So, whatever solution happens, it needs to be mostly automatic and it has to NOT BREAK machines after updates. Adding some automation in no way stops the purists from changing what they want back to as manual as they like. But, making things "just work" will help attract/keep people.
LuckyCyborg/ZhaoLin1457, please feel free to flame me here if I am getting something wrong.
I notice that the posters in this forum tend to be much older than in other forums and that's because Slackware is (for the most part) NOT attracting new blood. The reason for that is because we are losing people (contributors and users) and it seems to be slipping.
EFI support has been a major headache to me and I understand that Slackware developers mostly don't have time for this but, broken EFI is stopping some new adopters. Ubuntu just works with EFI so people are going there.
I think grub would go a long way to fixing this. And, yeah, it's worrying being one of the younger members on the forum (at 48). The installer is also off-putting, too. I'm fine with ncurses, but if it's the first thing a new user sees, it's going to color their experience. That's why I think Alien Bob's live media would go a long way in attracting new people--it's a system ready to use.
Yes, you are right. For the stock mkinitrd the -F parameter is mandatory.
Seems like ZhaoLin1457 still uses (just like me) a /sbin/mkinitrd to which have applied long time ago this patch bellow (made by me) for Slackware 15.0:
My rationale for this patch is that a program (or script) should use in a mandatory way its configuration file, not in an optionally way how does the stock /sbin/mkinitrd . Yeah, probably the patch can be improved.
Well all and good, yet most of us do not use a patched mkinitrd. the mkinitrd.conf saves having to type in frequently used options. I disagree with making in mandatory if a mkinitrd.conf exist. May as well get rid of the "-F" option and require mkinitrd.conf.
However Grub gets enabled, it needs to be automatic. That switch from default huge kernels to generic ones (then requiring manually running mkinitrd) after upgrades almost made me quit Slackware because my many machines quit starting on reboots and I had to search for why it was happening (and then make an ugly update script so I didn't forget about it).
I get the "do it by hand" Slackware way but, there's a trade off between being usable for the masses and being all done by hand for purists.
I notice that the posters in this forum tend to be much older than in other forums and that's because Slackware is (for the most part) NOT attracting new blood. The reason for that is because we are losing people (contributors and users) and it seems to be slipping.
EFI support has been a major headache to me and I understand that Slackware developers mostly don't have time for this but, broken EFI is stopping some new adopters. Ubuntu just works with EFI so people are going there.
So, whatever solution happens, it needs to be mostly automatic and it has to NOT BREAK machines after updates. Adding some automation in no way stops the purists from changing what they want back to as manual as they like. But, making things "just work" will help attract/keep people.
I for one, I agree fully with your words.
I believe that any operating system, be it Windows, UNIX or Slackware has a main job to do: to boot properly.
Honestly I believe that this is the main job of any operating system no matter what, how nice is Windows or what cool is to not have dependency resolution support and how customizable it's the Slackware - these things are on the next floor, somewhere bellow.
In other hand, I believe that how cool are the mega-initrds with 100 kernels within or how cool are the initrds with versioned names, this is something secondary.
The main issue is another: to give to users some good defaults with a robust automation, yet to permit to users to chose what solution they want. The people should understand something very simple: the system boot is not a place to play purist games! The system boot must be resilient like hell! By default!
The irony is that to solve this seems rather simple. We need three things:
First, we need to really adapt the GRUB2 package to Slackware. This is on the way, anyway, as the patch started by me, then made by ZhaoLin1457 and tuned by me, seems to do a fine job.
Secondly, we need a grubconfig script to be plugged in installer or to simplify the job when the user wants to reinstall the GRUB2. We already have a fine example and start point, thanks to Monsieur Didier. What we need? To add some dialogs, as to extend its abilities. Probably ready in a week or two, if not faster. BUT, the ground work is already done by Monsieur Didier.
Thirdly, we need a package containing both the (generic) kernel and its modules (only because Slackware has no dependency resolution, BTW) and having on its install/doinst.sh the following snippet:
Code:
if [ -x boot/setup-kernel ]; then
/bin/chroot . /bin/sh -c "/boot/setup-kernel @@KERNEL_VERSION@@"
fi
WHERE, this this /boot/setup-kernel script should NOT be overwritten in upgrade (having the .new support then) and it can contain (for a full automation) just these lines bellow, as example:
Well all and good, yet most of us do not use a patched mkinitrd. the mkinitrd.conf saves having to type in frequently used options. I disagree with making in mandatory if a mkinitrd.conf exist. May as well get rid of the "-F" option and require mkinitrd.conf.
Well, it's rather a mater of personal taste, and I do not tried to push it on Slackware.
Anyway, I find strange to need to specify "by hand" to a program to use its configuration file...
Rather, I would like a way to specify it to use another/custom config file. At least this way I have seen that the programs do.
Last edited by LuckyCyborg; 08-14-2023 at 11:20 PM.
The main issue is another: to give to users some good defaults with a robust automation, yet to permit to users to chose what solution they want. The people should understand something very simple: the system boot is not a place to play purist games! The system boot must be resilient like hell! By default!
100% agree. Nothing drives off users like not being able to get the system to at least boot.
..and any distribution that wants to survive needs users.
Whatever system you guys come up with, make it automated for the average user and let the purists customize/disable whatever they want.
No one ever had to use liloconf or eliloconf... Purists (for a lack of a better word) could do it all by hand if they wanted but those were needed for us average users.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.