SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I've found that recent kernels identify hdd's, external hdd's, usb's, sdd's (and whatever else you may have "plugged-in") differently with each boot.
Hence, when you first installed Slackware64, your boot hdd may have been /dev/sdb, yet on a reboot, it's /dev/sdc, or /sdf...basically, one can't be sure what /dev/sdx your boot partition may be (this also affects your fstab.)
To expound somewhat on what Didier has suggested, the solution is to use /dev/disk/by-(label/uuid) in both your lilo.conf and fstab, in conjunction with an initrd.
Bear in mind that I'm no expert, so my experience may be anecdotal....
so that I can see Windows from Linux, but in lilo.conf I have :
# Windows bootable partition config begins
other = /dev/sda1
label = Windows
table = /dev/sda
# Windows bootable partition config ends
So I can boot Windows from its system partition.
In any case I would boot Linux from the Linux root partition, not from the MBR. To do that, just replace in your /etc/lilo.conf
and make /dev/sde1 bootable with fdisk or cfdisk. Then run 'lilo -t -v' and if all goes well 'lilo'.
Or, run 'liloconfig' as root in the 'expert' mode. Of course then do not choose the 'Recycle' option, but 'Begin' then 'Linux' then 'Windows' then 'Install' and, when asked, choose to put LILO in your Linux root partition. Still, you will have to make that partition bootable with fdisk or cfdisk.
I really don't know why you prevented Windows 7 to create a system partition, this doesn't hurt.
I also prevented windows (XP) to create a system partition. I don't trust window$ to play nice when it has been violated by linux. If I ever need to access the windows partition from linux I can always mount it (ro) myself.
Distribution: Slint64-14.2beta2 on Lenovo Thinkpad W520
In my understanding, this has nothing to do with that. You can let Windows have its own system partition and never access it from Linux (or only read only, choosing or not to put a line in /etc/fstab for that. If it detects a Windows partition, Slackware's installer asks what you want to do with that. You will answer 'nothing' for the system partition and either 'nothing' or 'I want to be able to access it from Linux' for the other. In the latter case the installer asks you how it should set the permissions in /etc/fstab.)
Besides that, would I think Windows be that dangerous for Linux, I would simply wipe it out completely.
Anyhow I realize that we are not addressing captkrill's question with that discussion, so let's go back to the topic.
Last edited by Didier Spaier; 02-16-2013 at 02:57 AM.
Seems to me the windows is a non issue at this point. Considering lilo is functioning correctly and he can pick either windows or Slack. Windows boots but the Slack kernel panics. His motherboard is listed as MB: ASUS P8Z68-V Pro.
Does anyone know if vmlinuz-huge-3.2.29 has full support for this board? Or perhaps he needs to build a newer kernel?
It might be difficult to build a new kernel if captkrill can't boot into linux (and a bit ambitious to boot). Assuming that captkrill is correctly loading the huge kernel and getting nowhere, an alternative might be to download the 3.7.1 kernel from Slackware Current and try that instead.
Ok I will try and change booting to the huge kernel.
In the meantime, as I am away from my home PC. Is there anywhere I can download a stable slack-current ISO just to have that as a possible fix if changing the boot does not work?
Also, would building a slack64 ISO with kernel 3.7.8 be a possible solution as well?
Just to give some insight on my installation method.
The reason that I prevented Windows from creating the system reserved partition is because it was the only way that my current set up dual boot with dual drives would boot lilo, a non working slack and windows. Without doing so, no matter the install method, Lilo would not load and thus not be able to get into windows or a non-working Slack.