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.
To get Slackware64-current running on AWS cloud I did the following (roughly described):
1. Installed Slackware in my own VM to create an image (sets A, AP, D, E, F, K, L, N, skipped LILO, selected DHCP, set root password).
2. Extracted the file tree from the image.
3. On AWS started an Ubuntu 12.04 instance (handy source of files mentioned below).
4. On local changed /etc/fstab ... sda1 -> xvda1
5. Copied /boot/grub stuff from cloud version of Ubuntu
6. Copied kernel and stuff from /boot of Ubuntu
7. Edited /boot/grub/grub.cfg to say Slackware instead of Ubuntu (but this didn't matter)
7. On AWS created an empty 8GB EBS volume
8. Attached volume to instance as /dev/sdf
9. On instance noted volume attached as /dev/xvdf
10. Formatted /dev/xvdf with ext4 and same options as /dev/xvda1 (see list in "tune2fs -l /dev/xvda1")
11. Mounted /dev/xvdf as /mnt/xvdf (with "-o rw,noatime")
12. Uploaded the extracted/modified tree from above to the instance loading /mnt/xvdf (I used rsync).
13. Waited around while the 4GB uploaded.
14. On AWS instance unmount /mnt/xvdf
15. On AWS console detached volume
16. Made snapshot of volume
17. Made AMI of volume using a PVGRUB kernel. Visit page http://docs.amazonwebservices.com/AW...edkernels.html to select an "hd0" (not "hd00") kernel AKI id for your preferred AWS region.
18. Launched the AMI into an instance.
19. Waited a few minutes then checked instance system log to be sure it came up.
20. Logged in via SSH (be sure your security groups setting allows you on port 22).
It's rough, but it's a go. More tweaks to smooth it out before I make an AMI public. I'll need to add some "cloud init" stuff to do run time config tweaks such as adding in the AWS configured public keys, and such.
Would you be interested to write your exercise as a page here? http://docs.slackware.com/howtos:cloud:start
Initially, Darren Austin was going to write that page but I do not think (six months later) that he is ever going to deliver.
At the time when the OP was written, there was no Slackware AMI available. There is one now (search for slackware14), in the Ireland region IIRC.
Of course this doesn't mean that I don't want to read how to build my own if the need arises
At the time when the OP was written, there was no Slackware AMI available. There is one now (search for slackware14), in the Ireland region IIRC.
Of course this doesn't mean that I don't want to read how to build my own if the need arises
I think it is still not quite ready. Last time I tested it, no kernel modules were loaded.
I wants to create the own kernel package of Slackware with Xen support.
Please find my slackbuild below.. but here modules are not build with the package.
"Processor type and features" -> "High Memory Support" -> Make sure it is set to 64GB
•"Processor type and features" -> "PAE (Physical Address Extension) Support" -> enable
•"Processor type and features" -> "Paravirtualized guest support" -> enable
•"Processor type and features" -> "Paravirtualized guest support" -> "Xen guest support" -> enable
•"Device Drivers" -> "Block devices" -> "Xen virtual block device support" -> enable either as a module or built in
•"Device Drivers" -> "Network device support" -> "Xen network device frontend driver" -> enable either as a module or built in
if [ ! -d $TMP ]; then
mkdir -p $TMP
fi
rm -rf $PKG
mkdir -p $PKG
echo "Using /lib/modules/${VERSION}/"
echo "Make sure these are *ready*... compressed, or not."
echo "However you want 'em."
sleep 5
mkdir -p $PKG/lib/modules
cp -a /lib/modules/${VERSION} $PKG/lib/modules
mkdir -p $PKG/etc/rc.d
cat $CWD/rc.modules.new > $PKG/etc/rc.d/rc.modules-${VERSION}.new
chmod 755 $PKG/etc/rc.d/rc.modules-${VERSION}.new
mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc
# Write out the doinst.sh:
cat << EOF > $PKG/install/doinst.sh
config() {
NEW="\$1"
OLD="\$(dirname \$NEW)/\$(basename \$NEW .new)"
# If there's no config file by that name, mv it over:
if [ ! -r \$OLD ]; then
mv \$NEW \$OLD
elif [ "\$(cat \$OLD | md5sum)" = "\$(cat \$NEW | md5sum)" ]; then # toss the redundant copy
rm \$NEW
fi
# Otherwise, we leave the .new copy for the admin to consider...
}
config etc/rc.d/rc.modules-${VERSION}.new
# If rc.modules is a real file, back it up:
if [ -r etc/rc.d/rc.modules -a ! -L etc/rc.d/rc.modules ]; then
cp -a etc/rc.d/rc.modules etc/rc.d/rc.modules.bak
fi
## Now that -smp is default, we probably shouldn't be so paranoid about
## preserving existing symlinks as it causes a full install to point to
## the wrong rc.modules script. If you want your rc.modules to endure,
## copy it to rc.modules.local.
## Make rc.modules a symlink if it's not already, but do not replace
## an existing symlink. You'll have to decide to point at a new version
## of this script on your own...
#if [ ! -L etc/rc.d/rc.modules ]; then
# ( cd etc/rc.d ; rm -rf rc.modules )
# ( cd etc/rc.d ; ln -sf rc.modules-${VERSION} rc.modules )
#fi
# A good idea whenever kernel modules are added or changed:
if [ -x sbin/depmod ]; then
chroot . /sbin/depmod -a ${VERSION} 1> /dev/null 2> /dev/null
fi
EOF
cd $PKG
makepkg -l y -c n $TMP/kernel-modules-${VERSION}-$ARCH-$BUILD.txz
That is still the case, at least with the image I took around a month ago.
Well, I went back to this issue, mainly because I wanted to use iptables. After many attempts and short-lived instances, I was able to find the right tweaks and boot the Slackware kernel included in this image.
1. Edit /boot/grub/menu.lst. Change reference from /dev/sda1 to /dev/xvda1. Optionally, add "3" at the end of the command line, since the default runlevel is 4 and we don't need a graphical login here.
2. Edit /etc/fstab. Change root partition to /dev/xvda1
3. Add module ext3 to the initrd (the included initrd has ext4 only, and the FS is ext3)
4. Boot with hd00 kernel (since the volume has a partition table)
That's it, no extra steps. The only problem is that, due to the change in the fstab file, booting with a non-pvgrub kernel is not possible, unless further changes are made (I read something about a patch for Xen to make it devices appear as sd*, I'm not sure if that is actually required or any other hack can be used)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.