Re: [linux-lvm] Changing device numbers.

Re: [linux-lvm] Changing device numbers.

[Wichert Akkerman]

Previously Bas wrote:
> I want root to have major 58, minor 0 and usr major 58, minor 1. How can I
> get that done.

The first thing that comes to my mind is: why would anyone care
what the device numbers are? The whole purpose of device files,
and especially devfs, is that you can use names instead of number
and never need to care about them.

Wichert.

-- 
   ________________________________________________________________
 / Generally uninteresting signature - ignore at your convenience  \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: [linux-lvm] Changing device numbers.

[Wichert Akkerman]

Previously Bas wrote:
> Because since I removed a couple of LVs and created a few, lilo seems to
> have some trouble when it's told that root=/dev/rootvg/root. (this number
> has changed). Plus I think it looks a lot "nicer" ...

Just running lilo again should fix that, right? It would be nice if
someone updated grub to handle LVM

Wichert.

-- 
   ________________________________________________________________
 / Generally uninteresting signature - ignore at your convenience  \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: [linux-lvm] Changing device numbers.

[Terje Kvernes]

"Bas" <list@showme.wox.org> writes:

> Because since I removed a couple of LVs and created a few, lilo
> seems to have some trouble when it's told that
> root=/dev/rootvg/root. (this number has changed). 

  and rerunning lilo doesn't help? if it doesn't you could try playing
  with the "disk"-settings in lilo?

> Plus I think it looks a lot "nicer" ...

  yes, well, you have to break a few eggs to make an omelet. or
  something. YMMV.

-- 
Terje - who has / as a normal partition mostly because he got a new
        disk to install LVM on, and didn't bother moving /.

Re: [linux-lvm] Changing device numbers.

[Andreas Dilger]

Bas writes:
> Because since I removed a couple of LVs and created a few, lilo seems to
> have some trouble when it's told that root=/dev/rootvg/root. (this number
> has changed). Plus I think it looks a lot "nicer" ...

You have two significant problems:

1) The most important problem is that it is IMPOSSIBLE for LILO to boot
   from a striped LV (or MD RAID 0 for that matter).  No matter what you
   do, this will not be fixed, because the BIOS cannot handle a kernel
   image on multiple disks.

2) The next problem is that LILO doesn't support booting from an LV (yet).
   I posted a patch to lvm-devel with a fix for LILO, and if you are using
   the current CVS LVM kernel patch, you _can_ boot from an LV, but not
   a striped LV.

3) No matter what you do with LVM, you still need to follow the limitations
   that LILO already has - BIOS accessible drive, use "lba32" option for
   kernel images above 1024 cylinders, etc.  LILO _should_ give you a
   warning or error if these are broken, even with LVM.  However, with an
   LVM /boot partition, it is not always clear how things are layed out
   on disk (or at least less so than with DOS partitions).

"Niceness" has nothing to do with it.  LILO is complaining about not
recognizing device "58:15" (or whatever), but it would also complain about
device "58:0" until you apply the LILO patch.  After that, it will work no
matter what you do, as long as LILO is happy with where the kernel is
physically located on disk.

Here is the LILO patch again.  The LVM patch is in beta6.  If you use it
with anything older than beta3, it will crash your system.

Cheers, Andreas

PS - it would be interesting if you tried a patched LILO on your current
     setup (with striped LV) before you fix it.  I want to know if checks
     for a kernel over multiple devices is working (geo->base_dev test).
==========================================================================
diff -ru lilo-21.6.1/geometry.c lilo-21.6.1a/geometry.c
--- lilo-21.6.1/geometry.c	Sat Dec 16 15:09:21 2000
+++ lilo-21.6.1a/geometry.c	Wed Mar  7 23:30:10 2001
@@ -39,6 +39,18 @@
 #endif
 #endif
 
+struct lv_bmap {
+    __u32 lv_block;
+    __u16 lv_dev;
+};
+
+#ifndef LV_BMAP
+#define LV_BMAP				_IOWR(0xfe, 0x30, 1)
+#endif
+#ifndef LVM_GET_IOP_VERSION
+#define LVM_GET_IOP_VERSION		_IOR(0xfe, 0x98, 1)
+#endif
+
 #ifndef HDIO_GETGEO
 #define HDIO_GETGEO HDIO_REQ
 #endif
@@ -265,6 +277,39 @@
 }
 
 
+void lvm_bmap(struct lv_bmap *lbm)
+{
+    DEVICE dev;
+    static int lvmfd = -1;
+    static dev_t last_dev = 0;
+
+    if (lbm->lv_dev != last_dev) {
+	char lvm_char[] = "/dev/lvm";
+	unsigned short iop;
+
+	if (lvmfd != -1)
+	    close(lvmfd);
+
+	if ((lvmfd = open(lvm_char, lbm->lv_dev, O_RDONLY)) < 0)
+	    die("can't open LVM char device %s\n", lvm_char);
+
+	if (ioctl(lvmfd, LVM_GET_IOP_VERSION, &iop) < 0)
+	    die("LVM_GET_IOP_VERSION failed on %s\n", lvm_char);
+
+	if (iop < 10)
+	    die("LVM IOP %d not supported for booting\n", iop);
+	close(lvmfd);
+
+	lvmfd = dev_open(&dev, lbm->lv_dev, O_RDONLY);
+	if (lvmfd < 0)
+	    die("can't open LVM block device %#x\n", lbm->lv_dev);
+    }
+    if (ioctl(lvmfd, LV_BMAP, lbm) < 0) {
+	perror(__FUNCTION__);
+	pdie("LV_BMAP error or ioctl unsupported, can't have image in LVM.\n");
+    }
+}
+
 void geo_query_dev(GEOMETRY *geo,int device,int all)
 {
     DEVICE dev;
@@ -421,6 +472,28 @@
     DT_ENTRY *walk;
     int inherited,keep_cyls;
 
+    /*
+     * Find underlying device (PV) for LVM.  It is OK if the underlying
+     * PV is really an MD RAID1 device, because the geometry of the RAID1
+     * device is exactly the same as the underlying disk, so FIBMAP and
+     * LV_BMAP will return the correct block numbers regardless of MD.
+     */
+    if (MAJOR(device) == MAJOR_LVM)
+    {
+	struct lv_bmap lbmA, lbmB;
+
+#define DIFF 10
+	lbmA.lv_dev = lbmB.lv_dev = device;
+	lbmA.lv_block = 0;
+	lbmB.lv_block = DIFF;
+
+	lvm_bmap(&lbmA);
+	lvm_bmap(&lbmB);
+	if (lbmB.lv_block - lbmA.lv_block != DIFF)
+	    die("This version of LVM does not support boot LVs");
+	device = geo->base_dev = lbmA.lv_dev;
+    }
+    /* Find underlying device for MD RAID */
     if (MAJOR(device) == MD_MAJOR) {
         char mdxxx[11];
 	int md_fd, pass;
@@ -523,7 +592,8 @@
     if (fstat(geo->fd,&st) < 0) die("fstat %s: %s",name,strerror(errno));
     if (!S_ISREG(st.st_mode) && !S_ISBLK(st.st_mode))
 	die("%s: neither a reg. file nor a block dev.",name);
-    geo_get(geo,S_ISREG(st.st_mode) ? st.st_dev : st.st_rdev,user_dev,1);
+    geo->dev = S_ISREG(st.st_mode) ? st.st_dev : st.st_rdev;
+    geo_get(geo, geo->dev, user_dev, 1);
     geo->file = S_ISREG(st.st_mode);
     geo->boot = 0;
 #ifndef FIGETBSZ
@@ -549,16 +619,15 @@
 int geo_open_boot(GEOMETRY *geo,char *name)
 {
     struct stat st;
-    dev_t dev;
 
     if (stat(name,&st) < 0) die("stat %s: %s",name,strerror(errno));
     if (!S_ISREG(st.st_mode) && !S_ISBLK(st.st_mode))
 	die("%s: neither a reg. file nor a block dev.",name);
-    dev = S_ISREG(st.st_mode) ? st.st_dev : st.st_rdev;
-    if (MAJOR(dev) == MAJOR_FD) geo->fd = 0;
+    geo->dev = S_ISREG(st.st_mode) ? st.st_dev : st.st_rdev;
+    if (MAJOR(geo->dev) == MAJOR_FD) geo->fd = 0;
     else if ((geo->fd = open(name,O_NOACCESS)) < 0)
 	    die("open %s: %s",name,strerror(errno));
-    geo_get(geo,dev,-1,0);
+    geo_get(geo, geo->dev, -1, 0);
     geo->file = S_ISREG(st.st_mode);
     geo->boot = 1;
     geo->spb = 1;
@@ -596,6 +667,18 @@
 	if (ioctl(geo->fd,FIBMAP,&block) < 0) pdie("ioctl FIBMAP");
 	if (!block) {
 	    return 0;
 	}
+    }
+    if (MAJOR(geo->dev) == MAJOR_LVM) {
+	struct lv_bmap lbm;
+
+	lbm.lv_dev = geo->dev;
+	lbm.lv_block = block;
+
+	lvm_bmap(&lbm);
+	if (lbm.lv_dev != geo->base_dev)
+	    die("LVM boot LV cannot be on multiple PVs\n");
+	block = lbm.lv_block;
     }
     sector = block*geo->spb+((offset/SECTOR_SIZE) % geo->spb);
     sector += geo->start;
diff -ru lilo-21.6.1/geometry.h lilo-21.6.1a/geometry.h
--- lilo-21.6.1/geometry.h	Sat Nov  6 14:09:40 1999
+++ lilo-21.6.1a/geometry.h	Wed Mar  7 23:20:30 2001
@@ -16,6 +16,7 @@
     int spb; /* sectors per block */
     int fd,file;
     int boot; /* non-zero after geo_open_boot */
+    dev_t dev, base_dev;
 } GEOMETRY;
 
 typedef struct _dt_entry {
diff -ru lilo-21.6.1/lilo.h lilo-21.6.1a/lilo.h
--- lilo-21.6.1/lilo.h	Thu Sep 21 17:18:50 2000
+++ lilo-21.6.1a/lilo.h	Tue Jan 23 14:49:59 2001
@@ -41,6 +41,7 @@
 #define MAJOR_DAC960	48 /* First Mylex DAC960 PCI RAID controller */
 #define MAJOR_IDE5	55 /* IDE on fifth interface */
 #define MAJOR_IDE6	57 /* IDE on sixth interface */
+#define MAJOR_LVM	58 /* Logical Volume Manager devices */
 #define COMPAQ_SMART2_MAJOR	72 /* First Smart/2 Major */
 
 #define MAX_IMAGES      ((SECTOR_SIZE*2-2)/sizeof(IMAGE_DESCR))
 			  /* maximum number of images */
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Changing device numbers.

[Andreas Dilger]

Bas writes:
> Rerunning lilo seemed to work, but I had the same problem just a while ago
> without changing anything but adding a LV.

Maybe because you are running "vgscan" on each boot?  It is not really
needed by LVM unless the disk configuration changes.  When you run it,
there is the possibility of the VG and LV devices changing major numbers.

Even so, it is a problem (IMHO) that LVM likes to delete all of the
device files each time vgscan is run.  The correct thing to do would
be to have "pvscan" create a file of UUID->disk mappings on each boot,
and leave the LVM devices alone.  Then vgscan would only be needed if
there is a major disaster.

Another possibility is to use the "UUID root" patch, which can locate
the root filesystem at mount time by the ext2 UUID or LABEL.  I don't
think it is ported to 2.4 yet.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Changing device numbers.

[Andreas Dilger]

Bas writes:
> From: Andreas Dilger <adilger@turbolinux.com>
> > 1) The most important problem is that it is IMPOSSIBLE for LILO to boot
> >    from a striped LV (or MD RAID 0 for that matter).  No matter what you
> >    do, this will not be fixed, because the BIOS cannot handle a kernel
> >    image on multiple disks.
> 
> To avoid miscommunication: the LV is striped across 2 disks. I'm not using
> RAID or anything like that. To be more specific: I used lvcreate -i2 -I 4 -L
> (size) -n (name) (vgname).  The kernel image is on /boot, which is (the
> only) "normal" partition.

Yes, even "-i2" is striping across multiple disks, just like RAID 0.  However,
if you have /boot on a normal (DOS) partition, then you are OK.

> > "Niceness" has nothing to do with it.  LILO is complaining about not
> > recognizing device "58:15" (or whatever), but it would also complain about
> > device "58:0" until you apply the LILO patch.  After that, it will work no
> > matter what you do, as long as LILO is happy with where the kernel is
> > physically located on disk.
> 
> Why does it work when I manually type "root=/dev/rootvg/root"  ?

Maybe because vgscan is changing the device numbers for /dev/rootvg/root?
It may also be that the initrd has different device numbers for the LVM
devices than the root partition does?  If you put a line "root=/dev/vgX/lvY"
in the lilo.conf, it will store the major/minor into the boot parameters.
You probably should use "append=root=/dev/vgX/lvY" to get it correct.

> > Here is the LILO patch again.  The LVM patch is in beta6.  If you use it
> > with anything older than beta3, it will crash your system.
> 
> Just for my understanding: if I use this patch, I will not have to use an
> initrd anymore ?

No, you still need initrd, but you no longer need to keep /boot in a DOS
partition.  You DO need to have a boot LV that is not striped (MD RAID 1
mirroring should be OK).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] Changing device numbers.

[Luca Berra]

On Tue, Mar 13, 2001 at 09:52:38PM -0800, Bas wrote:
> I thought so too, but that made me connect a monitor twice today and append
> a "root=/dev/rootvg/root" line ...
i put 
append="root=/dev/vg01/lvol1" in lilo.conf

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

[linux-lvm] Changing device numbers.

[Bas]

Hi,

I'm not sure if I'm correct with what I'm about to say, but please correct
me where I'm wrong:

I'm using devfs, (maybe not for long, depends on the answer), and since not
too long 2 SCSI disks. I decided to create striped LV's, and decided to go
all the way, so I included root. That made me create a temp LV, and copy all
the data. I did that with every LV. Now I didn't need my old LV that
contained root, so I deleted it.

I want root to have major 58, minor 0 and usr major 58, minor 1. How can I
get that done.
root is 58,15 now. This also caused trouble when I rebooted after deleting
old root.

Thanks,
Bas

Re: [linux-lvm] Changing device numbers.

[Bas]

Hi,

Because since I removed a couple of LVs and created a few, lilo seems to
have some trouble when it's told that root=/dev/rootvg/root. (this number
has changed). Plus I think it looks a lot "nicer" ...

Bye,
Bas

----- Original Message -----
From: Wichert Akkerman <wichert@cistron.nl>
To: <linux-lvm@sistina.com>
Sent: dinsdag 13 maart 2001 12:17
Subject: Re: [linux-lvm] Changing device numbers.


> Previously Bas wrote:
> > I want root to have major 58, minor 0 and usr major 58, minor 1. How can
I
> > get that done.
>
> The first thing that comes to my mind is: why would anyone care
> what the device numbers are? The whole purpose of device files,
> and especially devfs, is that you can use names instead of number
> and never need to care about them.
>
> Wichert.
>
> --
>    ________________________________________________________________
>  / Generally uninteresting signature - ignore at your convenience  \
> | wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
> | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

Re: [linux-lvm] Changing device numbers.

[Bas]

I thought so too, but that made me connect a monitor twice today and append
a "root=/dev/rootvg/root" line ...

----- Original Message -----
From: Wichert Akkerman <wichert@cistron.nl>
To: <linux-lvm@sistina.com>
Sent: dinsdag 13 maart 2001 12:43
Subject: Re: [linux-lvm] Changing device numbers.


> Previously Bas wrote:
> > Because since I removed a couple of LVs and created a few, lilo seems to
> > have some trouble when it's told that root=/dev/rootvg/root. (this
number
> > has changed). Plus I think it looks a lot "nicer" ...
>
> Just running lilo again should fix that, right? It would be nice if
> someone updated grub to handle LVM
>
> Wichert.
>
> --
>    ________________________________________________________________
>  / Generally uninteresting signature - ignore at your convenience  \
> | wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
> | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

Re: [linux-lvm] Changing device numbers.

[Bas]

Subject: Re: [linux-lvm] Changing device numbers.


> "Bas" <list@showme.wox.org> writes:
>
> > Because since I removed a couple of LVs and created a few, lilo
> > seems to have some trouble when it's told that
> > root=/dev/rootvg/root. (this number has changed).
>
>   and rerunning lilo doesn't help? if it doesn't you could try playing
>   with the "disk"-settings in lilo?

Rerunning lilo seemed to work, but I had the same problem just a while ago
without
changing anything but adding a LV.

>
> > Plus I think it looks a lot "nicer" ...
>
>   yes, well, you have to break a few eggs to make an omelet. or
>   something. YMMV.

>
> --
> Terje - who has / as a normal partition mostly because he got a new
>         disk to install LVM on, and didn't bother moving /.
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

Re: [linux-lvm] Changing device numbers.

[Bas]

----- Original Message -----
From: Andreas Dilger <adilger@turbolinux.com>
To: <linux-lvm@sistina.com>
Sent: dinsdag 13 maart 2001 12:55
Subject: Re: [linux-lvm] Changing device numbers.


> Bas writes:
> > Because since I removed a couple of LVs and created a few, lilo seems to
> > have some trouble when it's told that root=/dev/rootvg/root. (this
number
> > has changed). Plus I think it looks a lot "nicer" ...
>
> You have two significant problems:
>
> 1) The most important problem is that it is IMPOSSIBLE for LILO to boot
>    from a striped LV (or MD RAID 0 for that matter).  No matter what you
>    do, this will not be fixed, because the BIOS cannot handle a kernel
>    image on multiple disks.

To avoid miscommunication: the LV is striped across 2 disks. I'm not using
RAID
or anything like that. To be more specific: I used lvcreate -i2 -I 4 -L
(size) -n (name) (vgname).  The kernel image is on /boot, which is (the
only) "normal" partition.

> 2) The next problem is that LILO doesn't support booting from an LV (yet).
>    I posted a patch to lvm-devel with a fix for LILO, and if you are using
>    the current CVS LVM kernel patch, you _can_ boot from an LV, but not
>    a striped LV.

>
> 3) No matter what you do with LVM, you still need to follow the
limitations
>    that LILO already has - BIOS accessible drive, use "lba32" option for
>    kernel images above 1024 cylinders, etc.  LILO _should_ give you a
>    warning or error if these are broken, even with LVM.  However, with an
>    LVM /boot partition, it is not always clear how things are layed out
>    on disk (or at least less so than with DOS partitions).
>
> "Niceness" has nothing to do with it.  LILO is complaining about not
> recognizing device "58:15" (or whatever), but it would also complain about
> device "58:0" until you apply the LILO patch.  After that, it will work no
> matter what you do, as long as LILO is happy with where the kernel is
> physically located on disk.

Why does it work when I manually type "root=/dev/rootvg/root"  ?

> Here is the LILO patch again.  The LVM patch is in beta6.  If you use it
> with anything older than beta3, it will crash your system.

Just for my understanding: if I use this patch, I will not have to use an
initrd anymore ?

> Cheers, Andreas
>
> PS - it would be interesting if you tried a patched LILO on your current
>      setup (with striped LV) before you fix it.  I want to know if checks
>      for a kernel over multiple devices is working (geo->base_dev test).
> ==========================================================================
> diff -ru lilo-21.6.1/geometry.c lilo-21.6.1a/geometry.c
> --- lilo-21.6.1/geometry.c Sat Dec 16 15:09:21 2000
> +++ lilo-21.6.1a/geometry.c Wed Mar  7 23:30:10 2001
> @@ -39,6 +39,18 @@
>  #endif
>  #endif
>
> +struct lv_bmap {
> +    __u32 lv_block;
> +    __u16 lv_dev;
> +};
> +
> +#ifndef LV_BMAP
> +#define LV_BMAP _IOWR(0xfe, 0x30, 1)
> +#endif
> +#ifndef LVM_GET_IOP_VERSION
> +#define LVM_GET_IOP_VERSION _IOR(0xfe, 0x98, 1)
> +#endif
> +
>  #ifndef HDIO_GETGEO
>  #define HDIO_GETGEO HDIO_REQ
>  #endif
> @@ -265,6 +277,39 @@
>  }
>
>
> +void lvm_bmap(struct lv_bmap *lbm)
> +{
> +    DEVICE dev;
> +    static int lvmfd = -1;
> +    static dev_t last_dev = 0;
> +
> +    if (lbm->lv_dev != last_dev) {
> + char lvm_char[] = "/dev/lvm";
> + unsigned short iop;
> +
> + if (lvmfd != -1)
> +     close(lvmfd);
> +
> + if ((lvmfd = open(lvm_char, lbm->lv_dev, O_RDONLY)) < 0)
> +     die("can't open LVM char device %s\n", lvm_char);
> +
> + if (ioctl(lvmfd, LVM_GET_IOP_VERSION, &iop) < 0)
> +     die("LVM_GET_IOP_VERSION failed on %s\n", lvm_char);
> +
> + if (iop < 10)
> +     die("LVM IOP %d not supported for booting\n", iop);
> + close(lvmfd);
> +
> + lvmfd = dev_open(&dev, lbm->lv_dev, O_RDONLY);
> + if (lvmfd < 0)
> +     die("can't open LVM block device %#x\n", lbm->lv_dev);
> +    }
> +    if (ioctl(lvmfd, LV_BMAP, lbm) < 0) {
> + perror(__FUNCTION__);
> + pdie("LV_BMAP error or ioctl unsupported, can't have image in LVM.\n");
> +    }
> +}
> +
>  void geo_query_dev(GEOMETRY *geo,int device,int all)
>  {
>      DEVICE dev;
> @@ -421,6 +472,28 @@
>      DT_ENTRY *walk;
>      int inherited,keep_cyls;
>
> +    /*
> +     * Find underlying device (PV) for LVM.  It is OK if the underlying
> +     * PV is really an MD RAID1 device, because the geometry of the RAID1
> +     * device is exactly the same as the underlying disk, so FIBMAP and
> +     * LV_BMAP will return the correct block numbers regardless of MD.
> +     */
> +    if (MAJOR(device) == MAJOR_LVM)
> +    {
> + struct lv_bmap lbmA, lbmB;
> +
> +#define DIFF 10
> + lbmA.lv_dev = lbmB.lv_dev = device;
> + lbmA.lv_block = 0;
> + lbmB.lv_block = DIFF;
> +
> + lvm_bmap(&lbmA);
> + lvm_bmap(&lbmB);
> + if (lbmB.lv_block - lbmA.lv_block != DIFF)
> +     die("This version of LVM does not support boot LVs");
> + device = geo->base_dev = lbmA.lv_dev;
> +    }
> +    /* Find underlying device for MD RAID */
>      if (MAJOR(device) == MD_MAJOR) {
>          char mdxxx[11];
>   int md_fd, pass;
> @@ -523,7 +592,8 @@
>      if (fstat(geo->fd,&st) < 0) die("fstat %s: %s",name,strerror(errno));
>      if (!S_ISREG(st.st_mode) && !S_ISBLK(st.st_mode))
>   die("%s: neither a reg. file nor a block dev.",name);
> -    geo_get(geo,S_ISREG(st.st_mode) ? st.st_dev : st.st_rdev,user_dev,1);
> +    geo->dev = S_ISREG(st.st_mode) ? st.st_dev : st.st_rdev;
> +    geo_get(geo, geo->dev, user_dev, 1);
>      geo->file = S_ISREG(st.st_mode);
>      geo->boot = 0;
>  #ifndef FIGETBSZ
> @@ -549,16 +619,15 @@
>  int geo_open_boot(GEOMETRY *geo,char *name)
>  {
>      struct stat st;
> -    dev_t dev;
>
>      if (stat(name,&st) < 0) die("stat %s: %s",name,strerror(errno));
>      if (!S_ISREG(st.st_mode) && !S_ISBLK(st.st_mode))
>   die("%s: neither a reg. file nor a block dev.",name);
> -    dev = S_ISREG(st.st_mode) ? st.st_dev : st.st_rdev;
> -    if (MAJOR(dev) == MAJOR_FD) geo->fd = 0;
> +    geo->dev = S_ISREG(st.st_mode) ? st.st_dev : st.st_rdev;
> +    if (MAJOR(geo->dev) == MAJOR_FD) geo->fd = 0;
>      else if ((geo->fd = open(name,O_NOACCESS)) < 0)
>       die("open %s: %s",name,strerror(errno));
> -    geo_get(geo,dev,-1,0);
> +    geo_get(geo, geo->dev, -1, 0);
>      geo->file = S_ISREG(st.st_mode);
>      geo->boot = 1;
>      geo->spb = 1;
> @@ -596,6 +667,18 @@
>   if (ioctl(geo->fd,FIBMAP,&block) < 0) pdie("ioctl FIBMAP");
>   if (!block) {
>       return 0;
>   }
> +    }
> +    if (MAJOR(geo->dev) == MAJOR_LVM) {
> + struct lv_bmap lbm;
> +
> + lbm.lv_dev = geo->dev;
> + lbm.lv_block = block;
> +
> + lvm_bmap(&lbm);
> + if (lbm.lv_dev != geo->base_dev)
> +     die("LVM boot LV cannot be on multiple PVs\n");
> + block = lbm.lv_block;
>      }
>      sector = block*geo->spb+((offset/SECTOR_SIZE) % geo->spb);
>      sector += geo->start;
> diff -ru lilo-21.6.1/geometry.h lilo-21.6.1a/geometry.h
> --- lilo-21.6.1/geometry.h Sat Nov  6 14:09:40 1999
> +++ lilo-21.6.1a/geometry.h Wed Mar  7 23:20:30 2001
> @@ -16,6 +16,7 @@
>      int spb; /* sectors per block */
>      int fd,file;
>      int boot; /* non-zero after geo_open_boot */
> +    dev_t dev, base_dev;
>  } GEOMETRY;
>
>  typedef struct _dt_entry {
> diff -ru lilo-21.6.1/lilo.h lilo-21.6.1a/lilo.h
> --- lilo-21.6.1/lilo.h Thu Sep 21 17:18:50 2000
> +++ lilo-21.6.1a/lilo.h Tue Jan 23 14:49:59 2001
> @@ -41,6 +41,7 @@
>  #define MAJOR_DAC960 48 /* First Mylex DAC960 PCI RAID controller */
>  #define MAJOR_IDE5 55 /* IDE on fifth interface */
>  #define MAJOR_IDE6 57 /* IDE on sixth interface */
> +#define MAJOR_LVM 58 /* Logical Volume Manager devices */
>  #define COMPAQ_SMART2_MAJOR 72 /* First Smart/2 Major */
>
>  #define MAX_IMAGES      ((SECTOR_SIZE*2-2)/sizeof(IMAGE_DESCR))
>     /* maximum number of images */
> --
> Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
>                  \  would they cancel out, leaving him still hungry?"
> http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

Re: [linux-lvm] Changing device numbers.

[Heinz J. Mauelshagen]

On Tue, Mar 13, 2001 at 02:37:06PM -0700, Andreas Dilger wrote:
> Bas writes:
> > Rerunning lilo seemed to work, but I had the same problem just a while ago
> > without changing anything but adding a LV.
> 
> Maybe because you are running "vgscan" on each boot?  It is not really
> needed by LVM unless the disk configuration changes.  When you run it,
> there is the possibility of the VG and LV devices changing major numbers.
> 
> Even so, it is a problem (IMHO) that LVM likes to delete all of the
> device files each time vgscan is run.  The correct thing to do would
> be to have "pvscan" create a file of UUID->disk mappings on each boot,
> and leave the LVM devices alone.  Then vgscan would only be needed if
> there is a major disaster.

Andreas, we are planning for something very similar to this, because we need
it for Cluster-LVM anyway: the driver will do the scanning and keep
the mapping list which can be requested by the tools later.

> 
> Another possibility is to use the "UUID root" patch, which can locate
> the root filesystem at mount time by the ext2 UUID or LABEL.  I don't
> think it is ported to 2.4 yet.
> 
> Cheers, Andreas
> -- 
> Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
>                  \  would they cancel out, leaving him still hungry?"
> http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] Changing device numbers.

[Heinz J. Mauelshagen]

On Wed, Mar 14, 2001 at 08:11:44PM -0800, Bas wrote:
> ----- Original Message -----
> From: Heinz J. Mauelshagen <Mauelshagen@sistina.com>
> To: <linux-lvm@sistina.com>
> Sent: woensdag 14 maart 2001 8:37
> Subject: Re: [linux-lvm] Changing device numbers.
> 
> 
> > On Tue, Mar 13, 2001 at 02:37:06PM -0700, Andreas Dilger wrote:
> > > Bas writes:
> > > > Rerunning lilo seemed to work, but I had the same problem just a while
> ago
> > > > without changing anything but adding a LV.
> > >
> > > Maybe because you are running "vgscan" on each boot?  It is not really
> > > needed by LVM unless the disk configuration changes.  When you run it,
> > > there is the possibility of the VG and LV devices changing major
> numbers.
> > >
> > > Even so, it is a problem (IMHO) that LVM likes to delete all of the
> > > device files each time vgscan is run.  The correct thing to do would
> > > be to have "pvscan" create a file of UUID->disk mappings on each boot,
> > > and leave the LVM devices alone.  Then vgscan would only be needed if
> > > there is a major disaster.
> >
> > Andreas, we are planning for something very similar to this, because we
> need
> > it for Cluster-LVM anyway: the driver will do the scanning and keep
> > the mapping list which can be requested by the tools later.
> >
> 
> That looks good. How are minor numbers assigned now ? By LE (1st LE means
> device number 58,0) ?

s/LE/LV/ -> yes.

1st LV in 1st VG -> 58,0
2nd LV in 1st VG -> 58,1
1st LV in 2nd VG -> 58,2

and so on.

If you run vgscan while VGs are active, the active ones come first and
the inactive ones in a row after those.

> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-lvm] Changing device numbers.

[Bas]

----- Original Message -----
From: Heinz J. Mauelshagen <Mauelshagen@sistina.com>
To: <linux-lvm@sistina.com>
Sent: woensdag 14 maart 2001 8:37
Subject: Re: [linux-lvm] Changing device numbers.


> On Tue, Mar 13, 2001 at 02:37:06PM -0700, Andreas Dilger wrote:
> > Bas writes:
> > > Rerunning lilo seemed to work, but I had the same problem just a while
ago
> > > without changing anything but adding a LV.
> >
> > Maybe because you are running "vgscan" on each boot?  It is not really
> > needed by LVM unless the disk configuration changes.  When you run it,
> > there is the possibility of the VG and LV devices changing major
numbers.
> >
> > Even so, it is a problem (IMHO) that LVM likes to delete all of the
> > device files each time vgscan is run.  The correct thing to do would
> > be to have "pvscan" create a file of UUID->disk mappings on each boot,
> > and leave the LVM devices alone.  Then vgscan would only be needed if
> > there is a major disaster.
>
> Andreas, we are planning for something very similar to this, because we
need
> it for Cluster-LVM anyway: the driver will do the scanning and keep
> the mapping list which can be requested by the tools later.
>

That looks good. How are minor numbers assigned now ? By LE (1st LE means
device number 58,0) ?

Re: [linux-lvm] Changing device numbers.

[Bas]

> s/LE/LV/ -> yes.
>
> 1st LV in 1st VG -> 58,0
> 2nd LV in 1st VG -> 58,1
> 1st LV in 2nd VG -> 58,2
>
> and so on.
>

Ok, that's what I found out with that changing root device number. But what
makes 58,0 device 58,0 ? What I mean is: my old LV root was the first LV I
made. I didn't have 2 disks, now I do, and I wanted everything striped. I
removed the 1st LV, created a new (striped) one, and copied all the data
from old root to new root. I removed old root, and renamed templv to root,
thus giving it a device number. Then rebooted, to use the new root, and
created a LV.
That caused a shift in device numbers, and I wonder why. It makes me think
that the first LE on a disk that is used to create an LV, makes than device
58,0. Right ?