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.
I have 3 requests, please, evaluate if they are feasible or not...
1) init script generated by mkinitrd -> add argument "livemedia=" (this will allow to use mkinitrd to boot live iso without tweaking init by hand each time)
2) mkinitrd and init script generated -> add argument "resume_offset=" (this will allow hibernation to swapfile without tweaking init by hand each time)
3) init scripts rc.S and rc.6 -> Slackware start script and ending script doesn't handle previously mounted / fs in nbd very well. In a VPS with nbd (network block device), ramdisk script mount nbd / disk and pass control to Slackware init. Then rc.S remount / ro and tries to fsck then hangs. At ending, rc.6 tries to remount ro/unmount all fs and hangs also. These scripts could skip / fs if / is on nbd as both mounting and umounting are done by VPS ramdisk script, and it should be writable since the beginning until the very end (and call /usr/sbin DO_PIVOT=1 /run/initramfs/shutdown reboot (or poweroff) after rc.6 ends).
I have 3 requests, please, evaluate if they are feasible or not...
1) init script generated by mkinitrd -> add argument "livemedia=" (this will allow to use mkinitrd to boot live iso without tweaking init by hand each time)
2) mkinitrd and init script generated -> add argument "resume_offset=" (this will allow hibernation to swapfile without tweaking init by hand each time)
3) init scripts rc.S and rc.6 -> Slackware start script and ending script doesn't handle previously mounted / fs in nbd very well. In a VPS with nbd (network block device), ramdisk script mount nbd / disk and pass control to Slackware init. Then rc.S remount / ro and tries to fsck then hangs. At ending, rc.6 tries to remount ro/unmount all fs and hangs also. These scripts could skip / fs if / is on nbd as both mounting and umounting are done by VPS ramdisk script, and it should be writable since the beginning until the very end (and call /usr/sbin DO_PIVOT=1 /run/initramfs/shutdown reboot (or poweroff) after rc.6 ends).
(maybe I can solve some of these requests...)
thanks
best regards
Weber Kai
I do not know how others think, but I consider the NBD devices usage as root just an exotic case of virtualization, which is barely of general interest. Maybe this kind of usage worths a custom sysv init scripts package for your virtualization solution?
However, I will love to see how "you tweak by hand every time" the initrd to support the parameters "livemedia" and "resume_offset" ...
So, you are kind to show us how you do it?
Last edited by LuckyCyborg; 11-10-2020 at 01:02 AM.
I do not know how others think, but I consider the NBD devices usage as root just an exotic case of virtualization, which is barely of general interest. Maybe this kind of usage worths a custom sysv init scripts package for your virtualization solution?
However, I will love to see how "you tweak by hand every time" the initrd to support the parameters "livemedia" and "resume_offset" ...
So, you are kind to show us how you do it?
1) When the init script stops, you will mount the partition which contains the iso file in another mount point like /myhd and after that you mount the iso file in /mnt, and then the script can continue. Or tweak init by hand to do it and compress again. (http://git.slackware.nl/liveslak/tree/liveinit.tpl) <- If default init would accept livemedia argument, you could have current iso file in any partition and boot it in grub only adding an argument "livemedia", instead of creating a tweaked initrd.gz to boot it. You could use installation iso as rescue easily. (I need to tweak the init everytime I upgrade the iso) A lot of people could download the iso and boot easily from hd without usb pendrive and install Slackware.
2) As the patch "init-swapfile.patch" in this page https://docs.slackware.com/howtos:sl...le_hibernation is not working anymore, I change init by hand, as it is easy to find the correct insertion points. Then compress initrd.gz again. (I need to tweak the init everytime I upgrade the kernel)
3) Agree, but a lot of VPS providers could enable Slackware 'out of the box' with this tweak. When Slackware don't boot or halt, they just give up...
1) When the init script stops, you will mount the partition which contains the iso file in another mount point like /myhd and after that you mount the iso file in /mnt, and then the script can continue. Or tweak init by hand to do it and compress again. (http://git.slackware.nl/liveslak/tree/liveinit.tpl) <- If default init would accept livemedia argument, you could have current iso file in any partition and boot it in grub only adding an argument "livemedia", instead of creating a tweaked initrd.gz to boot it. You could use installation iso as rescue easily. (I need to tweak the init everytime I upgrade the iso) A lot of people could download the iso and boot easily from hd without usb pendrive and install Slackware.
I think you are overcomplicating things here. Grub can boot a live ISO if you point to it like this (suppose you have a liveslak ISO stored on a disk with filesystem label MYHOME):
Code:
set imgdevpath='/dev/disk/by-label/MYHOME'
set isofile="/downloads/slackware64-live-current-x86_64.iso"
loopback loop $isofile
linux (loop)/boot/generic fromiso=$imgdevpath/$isofile load_ramdisk=1 prompt_ramdisk=0 rw printk.time=0
initrd (loop)/boot/initrd.img
No need for mkinitrd patches.
Quote:
2) As the patch "init-swapfile.patch" in this page https://docs.slackware.com/howtos:sl...le_hibernation is not working anymore, I change init by hand, as it is easy to find the correct insertion points. Then compress initrd.gz again. (I need to tweak the init everytime I upgrade the kernel)
Post your patch in this thread so that someone can have a look at it. It's always better to post solution proposals than just to mention that you want something changed.
Quote:
3) Agree, but a lot of VPS providers could enable Slackware 'out of the box' with this tweak. When Slackware don't boot or halt, they just give up...
Same here, if you have a working patch, show it. Most of us here probably do not use NBD on a VPS.
I think you are overcomplicating things here. Grub can boot a live ISO if you point to it like this:
No need for mkinitrd patches.
Unfortunately the Slackware 14.2 installation iso is not a live iso and doesn't support that direct boot... But I'll send a proposal here to current standard mkinitrd...
Quote:
Originally Posted by Alien Bob
Post your patch in this thread so that someone can have a look at it.
Cool! I'll do it!
Quote:
Originally Posted by Alien Bob
It's always better to post solution proposals than just to mention that you want something changed.
Agree. As I've said earlier I can propose solution to some of those requests.
I didn't send them before because I thought this thread was limited to requests not proposals...
Sorry, asperger here... But I'll send the patchs...
Quote:
Same here, if you have a working patch, show it. Most of us here probably do not use NBD on a VPS.
I've done all tweaks to Slackware stable.
I will update them against current, and maybe they can fit next release.
Unfortunately the Slackware 14.2 installation iso is not a live iso and doesn't support that direct boot... But I'll send a proposal here to current standard mkinitrd...
Also the Slackware -current does not have the installation ISO as a live ISO.
I believe that you make confusion between Mr. Hameleers' LiveSlak and the Slackware-current installation ISO.
And I do not see how the initrd from standard Slackware -current can use those ISOs for booting.
In the link given by you to LiveSlak's initrd, finding and mounting an ISO is useless unless further the initrd is also capable to assemble the live system from the compressed files found within ISO and to boot it.
AGAIN, I strongly believe that you confuse the LiveSlak and its live system way with the standard Slackware where the installer is in an initrd, and further, the operating system's initrd needs to find and prepare the root filestem, then to switch to it.
Last edited by LuckyCyborg; 11-10-2020 at 05:56 AM.
Just a question, out of curiosity, will slackware move to GRUB as a default boot loader ?
Not an answer, but: as I am enhancing the Slint installer, and now making it a modification of the files in https://mirrors.slackware.com/slackw...rce/installer/ instead of unpacking and modifying a Slackware installer as I did until now, I will share my modifications, including using GRUB as default boot loader, just providing an "installer" source directory in the main Slint repository as does Slackware. This will make possible to cherry pick some modifications, like our new "auto" script intended to provide a guided installation to help newbies in addition to the setup script. I appreciate that Pat[2] makes the source of the installer available and provide well documented ways to customize it, so let's do an "échange de bons procédés[1]"
[1]Even deepl.com and linguee didn't help much this time. Maybe "give and take" or "exchange of good manners"?
[2]Thanks to Pat and also to the authors of the main script Stuart Winter and Eric Hameleers.
Last edited by Didier Spaier; 11-10-2020 at 01:04 PM.
Reason: Note [2] added.
@drumz: it is very rare that an upgrade of a package brings a modified configuration file. But if this is the case, it is worth being aware of that and spotting the differences.
There are, however, packages that ship config files containing version numbers (hello s-nail), or paths to documentation files which also contain version numbers (hello mutt).
Having to review the diff when the version number is literally the only thing that has changed, is quite boring.
IMHO Slackware could benefit from a policy that config.new files must not contain software version numbers.
There are, however, packages that ship config files containing version numbers (hello s-nail), or paths to documentation files which also contain version numbers (hello mutt).
Having to review the diff when the version number is literally the only thing that has changed, is quite boring.
IMHO Slackware could benefit from a policy that config.new files must not contain software version numbers.
By association of ideas, this triggers another suggestion: remove the suffix -<version> when naming /usr/doc/<package>-<version>, which could make way easier for newbies to find the documentation for a given package (not having to rely on tab completion, just typing "cd /usr/doc/<package>"). The only caveat would be if several versions of a package are installed (like e.g. python3-3.5.9 and python3-3.9.0. But for these (very few) cases one could just put the docs for each version in a separate sub directory, or keep the current naming only in theses cases.
PS in case someone wonder: I suggest to make this change progressively, on occasion of packages' update for other reasons.
Last edited by Didier Spaier; 11-11-2020 at 06:07 PM.
Reason: PS added.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
