Re: [Cooker] Attn. Brian: root on LVM works, just tested
hey gc, on your people.mandrakesoft page you have no link for rpmmon or anything related to it other than a tutorial in which i saw no place to d/l or code to write...you were the first to announce it so i assume it was your little project. pop it in the distro :). @localhost$ google -results=100 rpmmon no results found containing 'rpmmon' @localhost$ hmm...
Re: [Cooker] Attn. Brian: root on LVM works, just tested
Guillaume Cottenceau wrote: I did not know what it does. Besides, I suspect that for LVM you can't use device numbers, you have to use real names. Numbers are assigned dynamically when volume group is configured; if we rely on vgscan it may find another VG first, so minor number will be wrong. With LVM, once started, do you use mount with a device file or something else? Of course with device file. Device file has minor number. It is associated with with volume group when this volume group is activated. So, if you have VG1 and VG2 then if VG1 is activated first it gets minor number 0 and VG2 minor 1. If VG2 is activated first, *it* gets minor 0. Lilo encodes just major/minor for LVM device. But it may happen that you run lilo, and your root was minor 0 you added one more volume on another disk when you boot, the secobd disk is seen first and this VG gets minor 0 Brian, is it possible? 10 Megabytes??? waooh. And absolutely useless because at this point you need to configure exactly on volume - with root filesystem. 3. You cannot shutdown root volume but that's probably just cosmetic (warning on shutdown). May be sensible to filter root VG from shutdown. is the initrd getting umounted gracefully? What initrd? I speak about LV with root filesystem. You cannot shutdown it until is unmounted. And it is never unmounted (at least, not in any initscript). With the new mkinitrd, the initscripts will try to umount the initrd (located in /initrd) as third or fourth message after init booted. (disable aurora to see it well). There is some misunderstanding. I speak about *system*shutdown*. Not about unmounting initrd - here you have no problems. When system shuts down it deactivates LVM. It does not work for root device because it is busy. (what do you mean by tinylibc?) I've read about it in your description of stage1, may be I forgot the exact name, sorry. There was comparison how much stage1 takes with glibc and with another, apparently stripped down, libc. This was called tiny libc IIRC. Anyway, it appears to me like big headache for a seldom use. Well, this was intended for Brian in the first place as he had problems with rooting on LVM and I hoped it may help. I guess he had reasons to implement it. Actualy, there is not much headache and I guess it would be very interesting for enterprise server. -andrej
Re: [Cooker] Attn. Brian: root on LVM works, just tested
Blue Lizard [EMAIL PROTECTED] writes: hey gc, on your people.mandrakesoft page you have no link for rpmmon or anything related to it other than a tutorial in which i saw no place to well 1- previous 10 times i talked about it, i've put the exact url 2- the link is small (four letters) but it's here d/l or code to write...you were the first to announce it so i assume it was your little project. pop it in the distro :). no it won't go in the distro because it's mostly an internal tool (e.g. is for cooker users also) @localhost$ google -results=100 rpmmon no results found containing 'rpmmon' @localhost$ when the following works ;p http://freshmeat.net/search/?q=rpmmon -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Attn. Brian: root on LVM works, just tested
Borsenkow Andrej [EMAIL PROTECTED] writes: [...] 3. You cannot shutdown root volume but that's probably just cosmetic (warning on shutdown). May be sensible to filter root VG from shutdown. is the initrd getting umounted gracefully? What initrd? I speak about LV with root filesystem. You cannot shutdown it until is unmounted. And it is never unmounted (at least, not in any initscript). With the new mkinitrd, the initscripts will try to umount the initrd (located in /initrd) as third or fourth message after init booted. (disable aurora to see it well). There is some misunderstanding. I speak about *system*shutdown*. Not about unmounting initrd - here you have no problems. When system shuts down it deactivates LVM. It does not work for root device because it is busy. yep, but i thought that a still mounted initrd could be the cause of the busyness. (what do you mean by tinylibc?) I've read about it in your description of stage1, may be I forgot the exact name, sorry. There was comparison how much stage1 takes with glibc and with another, apparently stripped down, libc. This was called tiny libc IIRC. ok. this is dietlibc. i thought you were refering to something else unknown to me. Anyway, it appears to me like big headache for a seldom use. Well, this was intended for Brian in the first place as he had problems with rooting on LVM and I hoped it may help. I guess he had reasons to implement it. Actualy, there is not much headache and I guess it would be very interesting for enterprise server. by headache i mean incompat with mkbootdisk use and use of very large binaries/libraries. i still think that / is not so very important and one can use whatever partition he wants for /usr, /var, /home, etc. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Attn. Brian: root on LVM works, just tested
Borsenkow Andrej [EMAIL PROTECTED] writes:
I thought, I try it with new mkinitrd and new way how it handles devfs
(Chmouel, what is this magic handledevfs in nash? What it does - or,
rpmmon would have told you to ask me, not chmouel, the question.
[gc@bi ~] rpmmon -p mkinitrd
gc
better, how?) I had LVM volume so I formatted it (as Reiser), installed
It does:
void handledevfsCommand()
{
// I need to close my IO's in order to release the lock on initial /dev
close(0); close(1); close(2);
if (umount(/initrd/dev))
return;
mount(/dev, /dev, devfs, MS_MGC_VAL, NULL);
}
minimal number of packages, setup lilo to boot off main cooker but with
root on LVM volume, modified initrd - and what'd'you think? It booted
without any error messages.
So it works, that's it?
In case it helps, here are some files.
linuxrc (I obviously had to make initrd larger to put vgscan, vgchange and
libc on it). :
There is a patch to adapt the size of the initrd to what's inside. Wasn't
it enough?
[...]
echo Creating root device
#mkrootdev /dev/root
Why have you quoted mkrootdev?
[...]
I can run vgscan as many times as I like without any errors.
So in principle it is possible. Just how exactly is totally different :-)
So now you tell that it doesn't work... it's inconsistent. Does it work or
not ?
Some points:
1. Does mkrootdev handle LVM? What exactly it does?
Use the source luke.
void mkrootdevCommand(char * cmd, char * end) {
char * path;
unsigned int devNum = 0;
int fd;
int i;
char buf[1024];
if (!(cmd = getArg(cmd, end, path))) {
printf(mkrootdev: path expected\n);
return;
}
if (cmd end) {
printf(mkrootdev: unexpected arguments\n);
return;
}
fd = open(/proc/sys/kernel/real-root-dev, O_RDONLY, 0);
if (fd 0) {
printf(mkrootdev: failed to open /proc/sys/kernel/real-root-dev: %d\n,
errno);
return;
}
i = read(fd, buf, sizeof(buf));
if (i 0) {
printf(mkrootdev: failed to read real-root-dev: %d\n, errno);
close(fd);
return;
}
close(fd);
buf[i - 1] = '\0';
devNum = atoi(buf);
if (devNum 0) {
printf(mkrootdev: bad device %s\n, buf);
return;
}
unlink(path);
if (mknod(path, S_IFBLK | 0700, devNum)) {
printf(mkrootdev: mknod failed: %d\n, errno);
}
}
2. If you have really many volumes - is it possible that there will be no
space in ramdisk to create cofig files? Is it possible to limit scan to
specific group only (i.e. tell vgscan to *not* create configuration for
other groups). Or better yet do something like
vgscan | vgchange :-)
no idea, i don't understand the pb
3. You cannot shutdown root volume but that's probably just cosmetic
(warning on shutdown). May be sensible to filter root VG from shutdown.
is the initrd getting umounted gracefully?
4. We need static versions of vgchange and vgscan of course.
the problem is that it will be large - fscking the boodisks :-(.
--
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
Re: [Cooker] Attn. Brian: root on LVM works, just tested
Guillaume Cottenceau wrote:
So it works, that's it?
Yes.
There is a patch to adapt the size of the initrd to what's inside. Wasn't
it enough?
I did not know about it. It was quick'n'dirty just to see if it possible.
Why have you quoted mkrootdev?
I did not know what it does. Besides, I suspect that for LVM you can't
use device numbers, you have to use real names. Numbers are assigned
dynamically when volume group is configured; if we rely on vgscan it may
find another VG first, so minor number will be wrong.
So now you tell that it doesn't work... it's inconsistent. Does it
work or
not ?
I say that there are open issues if you want to use it in real life.
1. Does mkrootdev handle LVM? What exactly it does?
Use the source luke.
I can't at this moment, sorry.
2. If you have really many volumes - is it possible that there will be no
space in ramdisk to create cofig files? Is it possible to limit scan to
specific group only (i.e. tell vgscan to *not* create configuration for
other groups). Or better yet do something like
vgscan | vgchange :-)
no idea, i don't understand the pb
vgscan creates LVM coniguration files in /etc. Currently I have one PV,
one VG and one LV. The size of config is:
{pts/2}% ll /etc/lvmtab.d
? 148 -rw-r-1 root root 150840 ??? 8 23:45 VG
And if I have 100 groups? It is almost 10MB if I calculate correctly.
3. You cannot shutdown root volume but that's probably just cosmetic
(warning on shutdown). May be sensible to filter root VG from shutdown.
is the initrd getting umounted gracefully?
What initrd? I speak about LV with root filesystem. You cannot shutdown
it until is unmounted. And it is never unmounted (at least, not in any
initscript).
4. We need static versions of vgchange and vgscan of course.
the problem is that it will be large - fscking the boodisks :-(.
Well ... just how large? May be, it is possible to link them agains
tinylibc? Or probably make custom tools that do the same.
-andrej
Re: [Cooker] Attn. Brian: root on LVM works, just tested
Borsenkow Andrej [EMAIL PROTECTED] writes:
[...]
Why have you quoted mkrootdev?
I did not know what it does. Besides, I suspect that for LVM you can't
use device numbers, you have to use real names. Numbers are assigned
dynamically when volume group is configured; if we rely on vgscan it may
find another VG first, so minor number will be wrong.
With LVM, once started, do you use mount with a device file or something
else?
AFAIK, if you want to use the mount syscall from the kernel (and i don't
know any other mean to mount a filesystem) you need to use a device file
and a mount point.
So now you tell that it doesn't work... it's inconsistent. Does it work
or
not ?
I say that there are open issues if you want to use it in real life.
ok.
[...]
2. If you have really many volumes - is it possible that there will be no
space in ramdisk to create cofig files? Is it possible to limit scan to
specific group only (i.e. tell vgscan to *not* create configuration for
other groups). Or better yet do something like
vgscan | vgchange :-)
no idea, i don't understand the pb
vgscan creates LVM coniguration files in /etc. Currently I have one PV,
one VG and one LV. The size of config is:
{pts/2}% ll /etc/lvmtab.d
? 148 -rw-r-1 root root 150840 ??? 8 23:45 VG
And if I have 100 groups? It is almost 10MB if I calculate correctly.
10 Megabytes???
waooh.
3. You cannot shutdown root volume but that's probably just cosmetic
(warning on shutdown). May be sensible to filter root VG from shutdown.
is the initrd getting umounted gracefully?
What initrd? I speak about LV with root filesystem. You cannot shutdown it
until is unmounted. And it is never unmounted (at least, not in any
initscript).
With the new mkinitrd, the initscripts will try to umount the initrd
(located in /initrd) as third or fourth message after init booted.
(disable aurora to see it well).
[...]
4. We need static versions of vgchange and vgscan of course.
the problem is that it will be large - fscking the boodisks :-(.
Well ... just how large? May be, it is possible to link them agains
tinylibc? Or probably make custom tools that do the same.
(what do you mean by tinylibc?)
Anyway, it appears to me like big headache for a seldom use.
--
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
