LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 08-14-2023, 04:35 PM   #76
ZhaoLin1457
Senior Member
 
Registered: Jan 2018
Posts: 1,034

Rep: Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240

Quote:
Originally Posted by Didier Spaier View Post
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.
 
Old 08-14-2023, 04:48 PM   #77
arfon
Member
 
Registered: Apr 2004
Distribution: Slackware & RHEL
Posts: 380

Rep: Reputation: Disabled
My 2¢-

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.

Last edited by arfon; 08-14-2023 at 04:51 PM.
 
1 members found this post helpful.
Old 08-14-2023, 06:01 PM   #78
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,550

Rep: Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405
Quote:
Originally Posted by ZhaoLin1457 View Post
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.
 
1 members found this post helpful.
Old 08-14-2023, 06:26 PM   #79
ZhaoLin1457
Senior Member
 
Registered: Jan 2018
Posts: 1,034

Rep: Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240
Quote:
Originally Posted by LuckyCyborg View Post
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.
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 View Post
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.
 
1 members found this post helpful.
Old 08-14-2023, 06:38 PM   #80
0XBF
Member
 
Registered: Nov 2018
Distribution: Slackware
Posts: 781

Rep: Reputation: 895Reputation: 895Reputation: 895Reputation: 895Reputation: 895Reputation: 895Reputation: 895
Quote:
Originally Posted by ZhaoLin1457 View Post
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?
 
Old 08-14-2023, 07:09 PM   #81
ZhaoLin1457
Senior Member
 
Registered: Jan 2018
Posts: 1,034

Rep: Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240
Quote:
Originally Posted by 0XBF View Post
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

Code:
menuentry "Slackware Linux 15.0" {
	insmod fat
	insmod chain
	search --no-floppy --set=root --fs-uuid <UUID>
	chainloader /EFI/Slackware/grubx64.efi
}
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.
 
1 members found this post helpful.
Old 08-14-2023, 08:47 PM   #82
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,550

Rep: Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405
Quote:
Originally Posted by ZhaoLin1457 View Post
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

Code:
menuentry "Slackware Linux 15.0" {
	insmod fat
	insmod chain
	search --no-floppy --set=root --fs-uuid <UUID>
	chainloader /EFI/Slackware/grubx64.efi
}
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.
 
1 members found this post helpful.
Old 08-14-2023, 09:03 PM   #83
ZhaoLin1457
Senior Member
 
Registered: Jan 2018
Posts: 1,034

Rep: Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240Reputation: 1240
Quote:
Originally Posted by LuckyCyborg View Post
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.
Yes you are right. Thanks for the correction.

BTW, I think that to initialize $GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS it is enough to add somewhere to the beginning of the script:
Code:
GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS=${GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS-true}
 
1 members found this post helpful.
Old 08-14-2023, 09:04 PM   #84
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,550

Rep: Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405
Quote:
Originally Posted by ZhaoLin1457 View Post
BTW, I think that to initialize $GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS it is enough to add somewhere to the beginning of the script:
Code:
GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS=${GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS-true}
That's exactly what I have did.

You have bellow the patch as I use right now.

Code:
--- 10_linux.new	2021-09-10 21:45:00.000000000 +0300
+++ 10_linux	2023-08-15 05:24:37.945897588 +0300
@@ -47,6 +47,9 @@
 # older kernels.
 GRUB_DISABLE_LINUX_PARTUUID=${GRUB_DISABLE_LINUX_PARTUUID-true}
 
+# Default to disabling the initrd support for the Slackware's huge kernels.
+GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS=${GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS-true}
+
 # btrfs may reside on multiple devices. We cannot pass them as value of root= parameter
 # and mounting btrfs requires user space scanning, so force UUID in this case.
 if ( [ "x${GRUB_DEVICE_UUID}" = "x" ] && [ "x${GRUB_DEVICE_PARTUUID}" = "x" ] ) \
@@ -84,17 +87,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 +110,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 +202,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 +209,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 +233,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 +241,16 @@
     fi
   done
 
+  flavor="default"
+  if echo "${basename}" | grep -wq vmlinuz-huge ; then
+    if [ "x${GRUB_DISABLE_INITRD_FOR_HUGE_KERNELS}" = xtrue ]; 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}"
@@ -271,7 +296,7 @@
   fi
 
   if [ "x$is_top_level" = xtrue ] && [ "x${GRUB_DISABLE_SUBMENU}" != xtrue ]; then
-    linux_entry "${OS}" "${version}" simple \
+    linux_entry "${OS}" "${version}" simple "$flavor" \
     "${GRUB_CMDLINE_LINUX} ${GRUB_CMDLINE_LINUX_DEFAULT}"
 
     submenu_indentation="$grub_tab"
@@ -280,14 +305,14 @@
 	boot_device_id="$(grub_get_device_id "${GRUB_DEVICE}")"
     fi
     # TRANSLATORS: %s is replaced with an OS name
-    echo "submenu '$(gettext_printf "Advanced options for %s" "${OS}" | grub_quote)' \$menuentry_id_option 'gnulinux-advanced-$boot_device_id' {"
+    echo "submenu '$(gettext_printf "Advanced options for %s" "${OS}" | grub_quote)' \$menuentry_id_option 'gnulinux-advanced-$flavor-$boot_device_id' {"
     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
But I want to transform it soon in a patch for the GRUB2 SlackBuild.

Well, without that "initrd-generic" naming support.

LATER:

BTW, I have updated the patch - by mistake I have posted an old one. This one is good.

Heck, I miss the grub-emu! What a nice tool! But it does not build in Slackware...

Last edited by LuckyCyborg; 08-14-2023 at 09:40 PM.
 
1 members found this post helpful.
Old 08-14-2023, 09:38 PM   #85
arfon
Member
 
Registered: Apr 2004
Distribution: Slackware & RHEL
Posts: 380

Rep: Reputation: Disabled
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.

Last edited by arfon; 08-14-2023 at 10:59 PM.
 
5 members found this post helpful.
Old 08-14-2023, 10:06 PM   #86
garpu
Senior Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 1,588

Rep: Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917Reputation: 917
Quote:
Originally Posted by arfon View Post

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.
 
Old 08-14-2023, 10:11 PM   #87
chrisretusn
Senior Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware64-current
Posts: 2,979

Rep: Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556
Quote:
Originally Posted by LuckyCyborg View Post
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.
 
Old 08-14-2023, 11:13 PM   #88
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,550

Rep: Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405
Quote:
Originally Posted by arfon View Post
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:
Code:
#!/bin/sh

VERSION=${1:-$(uname -r)}

mkinitrd -F -c -k ${VERSION} -o /boot/initrd-${VERSION}.img -s /boot/initrd-${VERSION}

grub-mkconfig -o /boot/grub/grub.cfg
True, the example given generates intrds with versioned names and our BDFL wants /boot/initrd.gz and "fixed config" so maybe this one would be better:
Code:
#!/bin/sh

VERSION=${1:-$(uname -r)}

mkinitrd -F -k ${VERSION}
BUT, the fundamental thing is this script to exists (not necessarily with this path) and the people to be able to tune it.

For example, I am quite sure that a good friend of mine will change it ASAP to:
Code:
#!/bin/sh

VERSION=${1:-$(uname -r)}

echo "Just a kindly reminder that you need soon to update your mega-initrd and edit your grub.cfg . By hand."
That's all we need to "fix" the Slackware boot on the hardware without the usage Secure Boot.

I may be wrong, but this is one way to have a Slackware up to its fame: the legendary robustness.

Last edited by LuckyCyborg; 08-14-2023 at 11:52 PM.
 
1 members found this post helpful.
Old 08-14-2023, 11:15 PM   #89
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 3,550

Rep: Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405Reputation: 3405
Quote:
Originally Posted by chrisretusn View Post
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.
 
Old 08-14-2023, 11:21 PM   #90
arfon
Member
 
Registered: Apr 2004
Distribution: Slackware & RHEL
Posts: 380

Rep: Reputation: Disabled
Quote:
Originally Posted by LuckyCyborg View Post
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.

Last edited by arfon; 08-14-2023 at 11:24 PM.
 
4 members found this post helpful.
  


Reply

Tags
grub, grub2



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Infinite Grub Loop: GRUB GRUB GRUB GRUB GRUB GRUB GRUB GRUB GRUB GRUB... beeblequix MEPIS 2 11-02-2013 10:56 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 10:30 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration