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.
Hi: in partition 3 I have Slackware, installed by the Slackware installer skipping the lilo thing. In partition 1 there is Arch Linux. Now I want to build the slackware initrd file and, in order to do so I have two options, if I don't want to repeat the install: (a) boot the installer, enter as root and try to run mkinitrd, which I think is meaningless. (b) Use arch and run mkinitrd after doing
Code:
# mount /dev/mmcblk0p3 /mnt
# chroot /mnt/root
Does any of these options make sense?
NOTE: for the curious mind: in order to boot Slackware I need first to have a generic kernel with an initrd, due to the eMMC memory device playing the part of a hard disk and tell grub 2 to act in consecuence.
I mean, I don't think this will work but is an idea. Now all that is lacking is to run grub-mkconfig but, I think, this must be run from Arch. Does the command set root=(hd0,3) tell grub to look for the grub.cfg file in the third partition? For in that case it should be the Arch partition, partition 1.
EDIT: that's a naive question for the command, executed from Arch will be
Code:
# grub-mkconfig -o /boot/grub/grub.cfg
so there can be no mistake. What the set root= command does I really don't know.
Because grub is booting vmlinuz-generic, not vmlinuz-huge. That means, at the very least, the correct filesystem kernel module must be in the initrd, in order to mount the real, physical root partition and continue booting.
Thank you, gus3, of course I do know most reasons people use initrd and the generic kernel may even be top on the list since few people bother to "roll their own" anymore like us old-timers, but my point in asking is mainly that it should be asked since simply addinf file system support is so easy and the resulting simplicity makes life a bit simpler sometimes for years through "make oldconfig" which copies any customization to any new kernel build. AFAIK the only truly compelling reason for initrd is encryption.
Another compelling reason is to use less memory for the kernel, meaning more memory for user-space.
Yet another reason is less power usage for building a new kernel at every release. Granted, someone (else) spent the power to build the shipping kernel, but could you imagine the load on the grid if *everyone* built the new kernel every time Linus made an announcement? Not to mention the wear-and-tear on the CPU and the spinning platters/SD card!
Point is, stf92's reasons don't need justification. I did offer one possible reason, which is common enough that Pat allows for it in the Slackware software packages. Unseen possibilities are still possibilities.
Another compelling reason is to use less memory for the kernel, meaning more memory for user-space.
Pretty sure that's a non sequitur ever since on-demand module loading was adopted.
Quote:
Originally Posted by gus3
Yet another reason is less power usage for building a new kernel at every release. Granted, someone (else) spent the power to build the shipping kernel, but could you imagine the load on the grid if *everyone* built the new kernel every time Linus made an announcement? Not to mention the wear-and-tear on the CPU and the spinning platters/SD card!
I suppose many have that illogical Update Fever, but your "well" is poisoned before the "first bucket is drawn" by inserting the caveat that people update as soon as any minor revision is created. The only truly compelling reason to update a kernel is hardware support. In my case I tend to keep any particular kernel version for many months, if not more than a year.
Quote:
Originally Posted by gus3
Point is, stf92's reasons don't need justification. I did offer one possible reason, which is common enough that Pat allows for it in the Slackware software packages. Unseen possibilities are still possibilities.
Ah now I see. You misunderstood me. Choices within an OpSys never require justification as the choice is by nature "yours". You are who must live with those choices, not me. My6 opinion is more often than not, irrelevant. My question was not even "righteous indignation" let alone any sort of attack. My purpose was twofold, to stand and be counted for maintaining simplicity and also to keep track of new changes that may change the playing field and alter my perspective, changing my behaviour. That's all.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.