Pages

Search

Fedora Core 2/Windows XP dual boot: selecting Linux doesn't work - Forums Linux

Fedora Core 2/Windows XP dual boot: selecting Linux doesn't work - Forums Linux

Fedora Core 2/Windows XP dual boot: selecting Linux doesn't work

Posted: 14 Dec 2005 12:03 AM PST

uu.nl wrote: 
 
 
 

Eh? What? Is it scsi or isn't it? SATA is serial-ATA, which is not
scsi!

You'll have to make a bit more sense for me there, I'm afraid.

I'm going to work on the supposition that that is IDE, not scsi, and
that the "raid" is some software raid which doesn't exist at the
moment (only one disk anyway). So that is your hde?

Anyway, it'll be hd0, for the little I know of grub's weird
numbering system.

All I can see in the grub info file is:

Note that GRUB does _not_ distinguish IDE from SCSI - it simply counts
the drive numbers from zero, regardless of their type. Normally, any
IDE drive number is less than any SCSI drive number, although that is
not true if you change the boot sequence by swapping IDE and SCSI
drives in your BIOS.

Which seems to me to confirm my impression that they count in bios bot
order.

Why don't you check the info out?

Then you can send a LART for this:

That was easy, admit it. Do read the next chapter, to find out how to
actually install GRUB on your drive.

No - it was incredibly unclear, like all the grub documentation. Rumor
has that it is written originally in dutch by a blind monkey.
 

That is your hdc? I suppose that would be hd1 to grub.
 
 

So that's the way yu have your bios set? Then hde is hd0.
 
 

I don't know what "device.map" is. I've never heard of it. Oh - it's
some grub thing. yes, now THERE you can see what the mapping is! DON'T
CHANGE IT.
 
 

DON'T. Why, in heavens name, why? What's wrong with the mapping you
had? You only have to TELL us about it!

Well, anyway, I suppose this changes things to match the probable
facts. But you will have to tell grub to use that mapping file. Why
bother?
 

This points at grub's boot code area on hdc1. I've forgotten
where you said everything was. This should be pointing at the /boot
partition. Does it?
 

PLEASE DO NOT USE LABELS! Be specifc. Say "root=/dev/hdc2" (or
whatever).
 

And please do not use ramdisks. Why? Oh why. Is your kernel so
crippled?

 

No. You have done nothing to make it so! Install grub on a boot record,
copy that boot record to windows, and point windows boot.ini at the
copy.


Peter

Web server and email server in different places with same domain name

Posted: 13 Dec 2005 05:18 PM PST

com wrote:
 
no, this is for your dns 

i'd suggest having these DNS Records

tbc.to A 63.247.133.36
www.tbc.to CNAME tbc.to
mail.tbc.to A 209.58.72.83
tbc.to MX mail.tbc.to


this way, mail for @tbc.to goes to 209.58.72.83 (via the MX, mail
exchange record). the website, www.tbc.to and just tbc.to go to
63.247.133.36 (the web server). and for you to check your mail you'll
set your pop3/imap clients to "mail.tbc.to", or if you're using webmail,
then set them to "http://mail.tbc.to/webmail".

hope this helps
 

yeah, leave this kind of stuff out of hosts.. if stuff is supposted to
work on a global scale (web, email) then it should be properly
configured in dns as above. the hosts file is more for local stuff..
like..

192.168.1.110 box1.tbc.to box1
192.168.1.115 box2.tbc.to box2

...just local stuff that can't be setup globally, or that would never
need to be used globally. 


--
alex ~ org ~ www.aeshells.org ~ www.aeirc.net ~

USER, n.:
The word computer professionals use when they mean "idiot."

diskless workstation

Posted: 13 Dec 2005 02:15 PM PST

On Tue, 13 Dec 2005 23:15:47 +0100, Brad Weiland <net> wrote:
 

Google "Linux Diskless HOWTO"

-Enrique

Installed etch - where is lp0?

Posted: 13 Dec 2005 07:34 AM PST

On Tue, 13 Dec 2005 16:34:30 +0100, Saleem Chaudry <de> wrote:
 

First check lsmod:

lsmod | egrep "lp|parport"


Disregard usblp. If you see no output, the driver module is not
loaded. If you have a standard parallel port in the computer, it
should load, or, at least, it does load automatically on my system.

If it's not loaded on your system, start there:

modprobe parport
modprobe lp
modprobe parport_pc

Now check again if the files have appeared in /dev.
If this fixes the problem, you will have to

a) figure out why the modules were not loaded automatically.
This is a bit of an academic exercise, but assuming your
distro has arranged this to happen automatically, it would
ideally be best to find the root cause why it is not happening
rather than just fixing symptoms. Or,

b) Just arrange this to happen on every boot, by adding the
lines above to your /etc/rc.local, and ensuring this file
is run on reboot: check or create the link

ln -s ../rc.local /etc/rc.d/rc5.d/S99local

and similar for other runlevels (2,3,4)

If the modules are loaded, or they were not, but are now, but the
nodes are still not there in /dev, there is a problem with udev.

Again, I cannot give a complete accountof how it is supposed to work,
but you could start here:

cat /proc/sys/kernel/hotplug

This should output the name of a program that the kernel uses to
notify the user-land programs about the discovery (or disappearance)
of devices that might need nodes in /dev. On my system, the output
is "/sbin/udevsend". This program is run with an argument on the command
line, and a bunch of environment variables. Just an example from my
computer:

/sbin/udevsend usb_device
PHYSDEVPATH=/devices/pci0000:00/0000:00:14.2/usb1/1-1/1-1.2
SUBSYSTEM=usb_device
DEVPATH=/class/usb_device/usbdev1.10
MINOR=9
PATH=/sbin:/bin:/usr/sbin:/usr/bin
ACTION=add
PWD=/
MAJOR=189
SHLVL=1
HOME=/
PHYSDEVDRIVER=usb
PHYSDEVBUS=usb
SEQNUM=552

Reading the manpage for udevsend, I find that eventually these data are
propagated to a program /sbin/udev. Man udev. Most of the actions of udev,
as I understand it, are controlled by the file
/etc/udev/rules.d/50-udev.rules. The manpages are actually written in
a secret language that resembles English just enough to confuse the
enemy. However, the rules can "match" the information provided with
the "hotplug" event, similar to above, in quite obvious way. Notice the
distinction between "==" and "=" in the rules. "==" are matching conditions,
"=" are assignements to new parameters, done if the conditions are true.

When a rule matches, additional keywords, like MODE or OWNER get their
values from the rule. All rules that match contribute to the result, not just
the first match. In the end, a node is created in /dev, owned by OWNER,
with mode MODE, with major and minor device numbers MAJOR and MINOR (see above)
etc. Sometimes a symbolic link is created also, or instead.

My rules file has a pair of lines:

KERNEL=="lp*", GROUP="lp", MODE="0660"
KERNEL=="parport*", GROUP="lp", MODE="0660"

Good hunt,
-Enrique

What am I doing wrong"

Posted: 12 Dec 2005 02:07 PM PST

On Tue, 13 Dec 2005 14:01:30 -0800, gregory.owen wrote:
 

In most cases, the DRDOS prompt is the result of setting the burner
software to "make bootable disk". Which is wrong, but hey, nearly
everyone burns a few wrong to start.
--
mark south: world citizen, net denizen
echo pb.hx|tr a-z n-za-m
"Take it? I can't even parse it!" - Kibo, in ARK