How to create entries for hard disk partitions in /dev?

I have a terrible job with making old distros to boot because their /dev doesn't list all high-number partitions I created.

Typically they stop at hda24 but I want to use the maximum hda63 permitted by Linux.

I can boot these distros, installed aat or moved to partitions higher than 24 by Grub but I would like to learn ways to persuade Lilo too.

At the moment Lilo reports

Code:

---

root@1[root]# lilo -b /dev/hda61
Ignoring entry 'boot'
Fatal: open /dev/hda61: No such file or directory

---

It is a bit of a laugh as I boot it by Grub and using this distro to post.

The distro I am working on is Slynux 2.0, with 2.4.27 Kernel and a Lilo 22.2 but I got others in the same situation.

There doesn't seem a lot of information on /dev and how to create additional entries. May be I am looking at the wrong spot.

Look into mknod, that's used to "make block or character special files"
I haven't used it myself in years, especially since udev has taken a lot of that hassle over. You'll have to make udev rules also so they don't 'go away' after you reboot.

Hope that's a good start for ya...

Icarus,

Thanks for the pointer. Other references aalso mention mknod too but I am nervrous as I lack the background knowledge of how Linux controsl the devices.

Nevertheless I can report that I am booting the same Linux by "LIlo" first time. That means I have found a temporary solution.

I came across the command mount --bind and tried it out as follow.

(1) Boot to another Linux A that has /dev that has a device name for the Linux B I want to boot (which is hda61). In other word /dev of Linux A has maximum hda63 but Linux B stops at hda24. I do have partitions up hda63 detected fully by Linux A.

(2) I then in Linux A do

Code:

---

mount --bind /dev  /mnt/hda61/dev

---

which I believe the full list of /dev of Linux A is now available to Linux B

(3) I then change root to Linux B and restore Lilo

Code:

---

chroot /mnt/hda61
lilo -b /dev/hda61
exit

---

The scheme seems to work satisfactorily. No alteration is done in the /dev of Linux B. Lilo still can't be restored once the Linux B is booted up with the same error as reported in Post #1 before. However as LIlo fails and so it keeps the last working version and so I can continue to boot B.

Although this is not a permanent solution still I am glad that I can understand the root cause ( I think) and have a cure for it, at least temporarily.

I dont have that many distro on my computer (usuallly 3 or 4) but using lilo to boot all my distro once i add a new one, i create a mount point in my (main distro A) in /mnt/newdistro_name/ and then i mount the new distro B (dev#) and i edit lilo.conf with 2 line for the new distro B init and image showing the mount point like this /mnt/newdistro-name/dev#/boot/Image and the same for init. then i run lilo. Its always available like this as a boot option in the future. But this solution would be a pain with the amount of distro you have to boot because you have to mount all of them every time you want to make a change to lilo. Unless you edit fstab to automount (all of your distros)every time you boot your main working distro. By the way you should contact the guiness record society for the guy with the most distro on 1 computer. :)

Davno,

I think I beginning to understand your proposal.

My interpretation of it is you work inside Linux A and use its Lilo to compile the booting requirement for Linux B. This is achieved by mounting the kernel image on the /mnt subdirectory of Linux B.

This should overcome my problem but I still don't know how the connection is made by Lilo. Can you post a typical lilo.conf for compiling Lilo for Linux B while inside Linux A?

I am on my last leg of the journey to fill up the 152 partitions in the four hard disks with over 140 systems. It has been a great way of learning Linux. I plan to write a howto to show how easy it can be done. The trouble is many will laugh their heads off when they see how simple it is.

If you have access to a /dev tree that has the correct device file in it, then you can simply:

Code:

---

cp -a /wherever/dev/hda59 /dev/hda59

---

or whatever you need. (Without bind-mounting, that is.) The -a option tells cp to preserve pretty much everything (owner, group, permissions), and to act appropriately when you give it a device file (without -a, cp would try to copy the entire partition's contents, instead of just the device file), or a symlink, or a named pipe, or a named socket. (It also makes cp act recursively, so you have to be careful when using it on a directory; don't just use -a all the time.)

Or, you could do this:

Code:

---

ls -l /wherever/dev/hda59
brw-rw---- 1 root disk 3, 59 Dec 29 19:59 /dev/hda5

---

and note the parts in bold (the "b" at the beginning, telling you it's a block device, and the "3, 59" in the middle telling you it's major 3, minor 59). Then use mknod:

Code:

---

mknod /dev/hda59 b 3 59
chown root:disk /dev/hda59
chmod 0660 /dev/hda59

---

(The last two can probably be rolled into options given to mknod, but oh well, this works too.) The important part is the "b 3 59" -- these come directly from the output of ls -l. :)

And as Icarus said, it's easier when using udev -- the partitions that exist just show up, automatically. But if your distro is still running kernel 2.4, that's not really an option. ;)

I used to do something like this in the past. I made a script that made the devices for me when I installed a distro. I think my script was something like this:

Code:

---

#!/bin/sh

for more_devices in 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63; do
      mknod -m 660 /dev/hda$more_devices b 3 $more_devices ; chgrp disk /dev/hda$more_devices
done

---

:)

Thanks everybody for suggestions(Davno), directions(Icarus), explanation(bwkaz) and the exact script from Exodus2001

All excellent stuff! Exactly the ticket as shown below

Code:

---

bash-3.00# chmod 755 morehda
bash-3.00# lilo -b /dev/hda51
Ignoring entry 'boot'
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.01.01 (2005-03-29)(compat) and kernel driver
Fatal: raid_setup: stat("/dev/hda51")
bash-3.00# bash morehda
bash-3.00# lilo -b /dev/hda51
Ignoring entry 'boot'
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
Incompatible libdevmapper 1.01.01 (2005-03-29)(compat) and kernel driver
Warning: '/proc/partitions' does not match '/dev' directory structure.
    Name change: '/dev/hda21' -> '/tmp/dev.0'
Warning: '/dev' directory structure is incomplete; device (3, 21) is missing.
Warning: '/dev' directory structure is incomplete; device (3, 22) is missing.
Warning: '/dev' directory structure is incomplete; device (3, 23) is missing.
Warning: '/dev' directory structure is incomplete; device (3, 24) is missing.
Warning: '/dev' directory structure is incomplete; device (22, 21) is missing.
Warning: '/dev' directory structure is incomplete; device (22, 22) is missing.
Warning: '/dev' directory structure is incomplete; device (22, 23) is missing.
Warning: '/dev' directory structure is incomplete; device (22, 24) is missing.
Added scilinux *
Added single-user
bash-3.00#

---

I cut and paste Exodus2001 script as "morehda" without any alteration. The above show Lilo didn't compile before the issue of "morehda" and it did after.

You're going to want to add 21, 22, 23, and 24 to the list of devices that Exodus2001's script creates. Then run it again. (It doesn't matter where you add them; just put them somewhere in the list of numbers in the for statement. Each item that the for loops through is space-separated.)

As it is, you're missing 4 partitions from each disk. :)

bwkaz,

Thanks for the reminder. I checked and my /dev list. It stopped at hda24 and so Exodus2001's script is spot on. Some distros stop at hda19 or hda20 while others are willing to go up to hda32.

In one of the distros I tried your method but didn't go through your warning in post #6 first but attempted to "drag N drop" the higher hda device names between the mounted partitions in the desktop. I got myself into trouble exactly as you predicted.

In a panic I deleted all the hdaX device after I discovered by the normal copying the fully partition was copied and not just the device name The deletion included "hda" which is the one for the whole disk. Exodus2001 script works between hda1 and hda63 so I had to follow your method of using the -a parameter to copy hda back.

I managed to kick start 3 Distros' Lilo with your and Exodus2001 suggestions.

Quote:

---

Originally Posted by saikee

Thanks for the reminder. I checked and my /dev list. It stopped at hda24 and so Exodus2001's script is spot on. Some distros stop at hda19 or hda20 while others are willing to go up to hda32.

---

That's a little strange, because lilo is complaining that you don't have (3, 21), (3, 22), (3, 23), and (3, 24). (This is e.g. block-major-3-minor-21, which is hda21. It also complains about the same minors on block major 22, which is hdc/hdd.) Perhaps lilo is wrong, but it might not be a bad idea to double check the major/minor numbers on hda2[1-4].

OTOH, you did get a message in there about "name change: /dev/hda21 -> /tmp/dev.0", so I'm not sure what that means. Perhaps it has something to do with the issue too.

Quote:

---

The deletion included "hda" which is the one for the whole disk. Exodus2001 script works between hda1 and hda63 so I had to follow your method of using the -a parameter to copy hda back.

---

Well, you could manually mknod hda as well -- its parameters will be "b 3 0" (block, major 3, minor 0). But this works too.

bwkaz,

Sorry I was confusing you. You are right in your interpretation of the error message, as I know you can understand every "." and "-".

I cured the first Linux Slynux (from India) that has hda goes up to hda24 and moved to the the second Linux SciLinux (From USA) which has dev limit stops at hda20.

It was my mistake that I didn't make it clear to everybody.

I now feel more comfortable about the dev names. It has been a great help because for months I couldn't figure out why a Linux can be moved and operate at a high partition, say hda61, but when I restore its boot loader Lilo throw at my face with the message "Fatal :Open /dev/hda61 : no such file or directory". This make me feel guilty of booting up the Linux manually by Grub, thinking that I might have committed a crime in Linux for doing something that I am not supposed to.

I cuased the confusion because after satisfying with the cure suggested by Exodus2001 on Slynus Linux I attempt your method with SciLinux and forgot to report their /dev lists are different.

I was just curious, what do you have on those partitions? 60 distros?

Sepero,

From this thread

The distro in each partition is shown by menu.lst in Post #2.
For example SciLinux is in hda51, Slynux in hda61.


The size of each partition is shown in the "fdisk -l" listing.

I have one fully operaing system in each partition. The thread shows a simple way to do it. It is almost like proposing to build 145 apartments and have a door bell system (boot loader) wired up before the tennants (distros) are filled.

Before I install a system pressing the bell gives no answer but after installation the call will be answered.

Quote:

---

Originally Posted by saikee

I cured the first Linux Slynux (from India) that has hda goes up to hda24 and moved to the the second Linux SciLinux (From USA) which has dev limit stops at hda20.

---

Ah, I get it. Thanks! :)

Quote:

---

but when I restore its boot loader Lilo throw at my face with the message "Fatal :Open /dev/hda61 : no such file or directory".

---

Yeah, that's only because the file doesn't exist on that distro. Lilo doesn't care about the device files themselves after it's been run, and grub doesn't really care at all (except when you're running the grub-install script). Lilo uses hardcoded calls into some kind of disk access thingy (the BIOS perhaps?) that takes numbers for each disk, and doesn't care about the partition structure (it just passes a sector offset from the disk's start that it figured out when you initially ran it). Grub has its own partition numbering scheme, (hd0,0) and friends, but it basically uses that to come up with the same sector number that lilo uses. (Of course grub does it at runtime, which is part of the reason you don't have to reinstall grub every time you change your config file.)

I have picked up a lot from the moderators because of the in-depth knowledge and experience of you guys.

This post is just on the method of extending the /dev list which is the first time I have an interest to look into, mainly from a booting problem from Lilo. I wanted to find out why Lilo is such a poor performer when comparing with Grub in booting and so would do anything to get to the bottom. For sure I get a lot other information out of it.

You have confirmed what I have suspected all along with the following:-

Lilo is a boot loader that cannot operate outside Linux as it needs to be compiled whenever its configuration file lilo.conf is amended.

Grub is different as you has said

Quote:

---

(Of course grub does it at runtime, which is part of the reason you don't have to reinstall grub every time you change your config file.)

---

This implies Grub can operate outside the Linux, at least before kernel is booted.

Therefore Grub can enjoy the full range of hardware devices (in my case they are the hda21 to hda63) using the information from the Bios and not from the kernel.

Lilo on the other hand relies on the kernel exclusively. If a distro is using an older kernel for stability it may only detect a limited amount of hardware devices. For other stability reasons the disto could be unwilling to risk uncharted area of going into the newer devices because some internal software are not ready yet. Then the ability of Lilo to boot high-number devices (beyond the hda20 in my case) has been capped inadvertently.

I can report exactly the same thing is happening to Grub too after the Linux has bbeen booted and so Grub is fed by the kernel's information.

I have many feedbacks saying my proposal of restoring Grub in the mbr by grub-install /dev/hda inside partition hd(i,j) doesn't work. I then would tell them at the Grub's booting screen pressing "c" can get a Grub prompt and type

Code:

---

root (hd(i,j)
setup (hd0)

---

The success rate of the second alternative is much higer because in a Grub prompt the kernel is not yet booted and thus Grub gets the device list from the Bios and not from inside a Linux.

The grub-install is a Linux command on the other hand and suffers whatever limitation imposed by the kernel on the access of devces.

Linux is remarkably logical and many features can be "reason-out" if one pays attention to their characteristics. A few important pointers from the moderators can do magic in guiding the direction for those who wishes to learn.

no second ( , saikee... look at root (hd(i,j)

as a side note, lilo stands for linux loader. seems reasonable to rely on linux...

however, /dev/hd??? syntax is rather *nix, not linux only... I wouldn't call it reliance on linux. The thing is, lilo is designed to be as small as possible to fit on the mbr. naturally, these things get relegated to the executable, and since it is going to be static, reusing things done by the kernel is the way to go. grub was designed from scratch to be multiboot compliant ( and they defined multiboot too) and they meant to do the thing at runtime, so the difference.

and I agree that out mods are way too cool! :)

mknod is how you make devices under *NIX systems. read the man pages on it. its not to complexs. also if you cd into /dev there is usually a MAKEDEV script that you could run to create the devices you need.