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.
And speaking about customizing the initrd, I think there's a huge lack on the infrastructure of initrd used by Slackware: the hooks for it.
Or at least, a way to merge a small custom script at the near end of "/boot/initrd-tree/init"
The single way I found today, even on slackware-current, to make my customization to survive to a clean generation of the initrd, is to modify this "/init" script within "/usr/share/mkinitrd/initrd-tree.tar.gz" then to careful watch if an upgrade of package will overide it or not.
Code:
...
else
echo
echo "RESCUE mode"
echo
echo " You can try to fix or rescue your system now. If you want"
echo " to boot into your fixed system, mount your root filesystem"
echo " read-only under /mnt:"
echo
echo " # mount -o ro -t filesystem root_device /mnt"
echo
echo " Type 'exit' when things are done."
echo
/bin/sh
fi
##########################################################
# HERE YOU CAN RUN CUSTOM MOUNTING OR WHATEVER
##########################################################
# Need to make sure OPTIONS+="db_persist" exists for all dm devices
# That should be handled in /sbin/mkinitrd now
/sbin/udevadm info --cleanup-db
/sbin/udevadm control --exit
unset ERR
mount -o move /proc /mnt/proc
mount -o move /sys /mnt/sys
mount -o move /run /mnt/run
[ "$DEVTMPFS" = "1" ] && mount -o move /dev /mnt/dev
echo "${INITRD}: exiting"
exec switch_root /mnt $INIT $RUNLEVEL
Last edited by LuckyCyborg; 06-09-2019 at 11:58 AM.
A fresh install for something like this would totally be the way to go.
Agreed. A clean install of Slackware64-current would be an easier path to success. A standard partition scheme would work well, something like swap, /, /home.
I would back up your data first and do a clean install with Eric's -current ISO.
Agreed. A clean install of Slackware64-current would be an easier path to success. A standard partition scheme would work well, something like swap, /, /home.
I would back up your data first and do a clean install with Eric's -current ISO.
To be clear, all attempts were clean installs. All data was backed up prior to the first attempt.
I did in fact try to download Eric's current ISO, but it was painfully slow, so I went with one from a mirror.
I just installed 14.2, this time without the /usr partition, it worked, no errors and it booted up as it should. So all is good.
I still see some sites recommending a /usr partition, go figure. It worked in the past, but times change.
Thank you @GazL for the suggestion!
Now I guess I get to start compiling/installing software.
While some will argue that there is some value in employing a separate partition for "/home" and there certainly are even better arguments for a separate "/boot" partition, there is very little value in separating "/usr" from "/" anymore (largely due to large, fast, cheap hard drive availability) especially on SOHO Desktop systems. It is simply more trouble than it is worth as far as I can tell.
While some will argue that there is some value in employing a separate partition for "/home" and there certainly are even better arguments for a separate "/boot" partition, there is very little value in separating "/usr" from "/" anymore (largely due to large, fast, cheap hard drive availability) especially on SOHO Desktop systems.
Indeed. I like having a /home partition mounted on its own. It makes upgrading to a new version of Slackware dead simple; you can keep your data intact. During a new installation of Slackware you mount /home, but, don't format it.
You're welcome. I don't have any documentation to point at but if you do a google search for 'udev' and 'separate /usr' plenty of stuff shows up, though much of it is systemd related. To be fair, slackware does a pretty good job of keeping the required stuff in /lib rather than /usr, but even so I think it's fair to characterise the idea of a separate /usr as problematic going forward.
For what it's worth I run with separate /, /home, /var and /tmp(which I put on tmpfs).
One issue I've encountered with my layout is that a separate /var causes issues with the alsactl restore udev rule as /var/lib/alsa/asound.state isn't available when the udev rule runs, so I have to work around that one, but it's a small matter.
You're welcome. I don't have any documentation to point at but if you do a google search for 'udev' and 'separate /usr' plenty of stuff shows up, though much of it is systemd related. To be fair, slackware does a pretty good job of keeping the required stuff in /lib rather than /usr, but even so I think it's fair to characterise the idea of a separate /usr as problematic going forward.
For what it's worth I run with separate /, /home, /var and /tmp(which I put on tmpfs).
One issue I've encountered with my layout is that a separate /var causes issues with the alsactl restore udev rule as /var/lib/alsa/asound.state isn't available when the udev rule runs, so I have to work around that one, but it's a small matter.
Yeah, I did do a search and most everything was related to "systemd", and that is probably the genesis of the problem.
But what I fail to understand, is why Debian would install and run with the separate /usr. One would think the results would be the same as Debian is also infected with "systemd".
But what I fail to understand, is why Debian would install and run with the separate /usr.
I believe that what Debian do, is just about a "smarter" initrd or its "smarter" generation.
Probably on the generation stage, they parse somehow the mounted partitions, then the structure is reconstructed by initrd before going to the real system.
Just to get this cleared up, when trying to upgrade your 13.37 setup did you follow UPGRADE.TXT and CHANGES_AND_HINTS.TXT, right? I'm assuming you did, but I just ask to be sure...
I believe that what Debian do, is just about a "smarter" initrd or its "smarter" generation.
Probably on the generation stage, they parse somehow the mounted partitions, then the structure is reconstructed by initrd before going to the real system.
It can be argued that self-driving cars are "smarter and more complex" than a stick shift Jaguar F-Type or a Porsche 911 but which would you rather take a ride in or more to the point, which would you rather drive? It can also be postulated that as we accept more and more things that "do everything for you" at some point we will be able to do absolutely nothing but require something to do it for us. There is a substantial price to pay for mere convenience. For those of us who demand control and knowing exactly what went wrong if and when something fails to do what we desire and then how to fix it, thankfully, there is Slackware. Avoiding learning curves results in ignorance and powerlessness. No thanks.
Just to get this cleared up, when trying to upgrade your 13.37 setup did you follow UPGRADE.TXT and CHANGES_AND_HINTS.TXT, right? I'm assuming you did, but I just ask to be sure...
No, I formatted the existing partitions and attempted a clean install...After backing up all my data of course.
What I found out is Slackware 14.2/current doesn't like a separate /usr partition, 13.37 had no issue with it at all.
It looks like it has to do with "systemd", I now have more reading/learning to do.
After deleting the /usr partition (added the space to /) 14.2 installed without issue, boots and runs as it should.
I'm now at the stage where I can compile/install software and configure the system to my liking.
It looks like it has to do with "systemd", I now have more reading/learning to do.
No, Slackware does NOT use systemd, in any release.
It has to do that some utils need shared libraries and terminal info files that are in /usr/lib
Pat fixed that in -current by including those libraries in the aaa_elflibs (and adding an extra aaa_terminfo) package too, but 14.2 still needs /usr to be available during install and/or boot up.
No, Slackware does NOT use systemd, in any release.
It has to do that some utils need shared libraries and terminal info files that are in /usr/lib
Pat fixed that in -current by including those libraries in the aaa_elflibs (and adding an extra aaa_terminfo) package too, but 14.2 still needs /usr to be available during install and/or boot up.
Ok, I'll take your word for it.
But, I am puzzled as to why I got the exact same errors when trying to install -current as I did with 14.2 with the /usr partition.
But, I am puzzled as to why I got the exact same errors when trying to install -current as I did with 14.2 with the /usr partition.
I never tried to install -current from scratch, so I wouldn't really know, but maybe the installer, being "ncurses" compiled, still needs /usr/lib/terminfo ??
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.