From: Daniel S. <dan...@au...> - 2004-04-19 14:22:38
|
Currently, colinux creates new block special devices for it's drives, /dev/cobd1, /dev/cobd2, etc. Since we're already patching the linux kernel, how difficult would it be to patch the code responsible for handling the /dev/hd* and /dev/sd* block devices so that they are redirected to the colinux devices. If this could be done, it would certainly simplify the lives of the people with dual-boot systems. The xml format could be enhanced to something look like this: =20 =20 <block_device index=3D"0" path=3D"\Device\Harddisk0\Partition1" alias_major=3D"3" alias_minor=3D"1" enabled=3D"true" /> =20 =20 This would redirect /dev/hda1 to /dev/cobd0. =20 Another nice feature might be to create an entry either a directory or a file in /proc that startup scripts can check for to determine if you're running under colinux - something like=20 =20 if [ -e /proc/colinux ] then .... else =20 fi =20 (Excuse me if my bash syntax isn't quite correct, but I think you get the idea. :-) ) =20 =20 |
From: Jaroslaw K. <ja...@zd...> - 2004-04-19 15:39:47
|
It would be great if colinux supported specifying "LABEL=" as device name both in kernel parameters and /etc/fstab. Currently it doesn't seem to work. With this in place you'd be able to write in /etc/fstab: -------------------------- LABEL=/ROOT / ext3 defaults 0 0 LABEL=/USR /usr ext3 defaults 0 0 -------------------------- Under colinux it would map to /dev/cobdXXX, under "hardware" linux it would be /dev/hdaXXX Unfortunately I have no kernel knowledge to fix this myself, but it should be pretty easy. +1 for the "/proc/colinux" idea. Jarek BTW. I don't think that mapping /dev/cobd to /dev/hda would be good. They support different fctls() so it would probably do a lot of harm. ----- Original Message ----- From: "Daniel Slater" <dan...@au...> To: <col...@li...> Sent: Monday, April 19, 2004 4:22 PM Subject: [coLinux-devel] /dev/hd* vs. /dev/cobd* Currently, colinux creates new block special devices for it's drives, /dev/cobd1, /dev/cobd2, etc. Since we're already patching the linux kernel, how difficult would it be to patch the code responsible for handling the /dev/hd* and /dev/sd* block devices so that they are redirected to the colinux devices. If this could be done, it would certainly simplify the lives of the people with dual-boot systems. The xml format could be enhanced to something look like this: <block_device index="0" path="\Device\Harddisk0\Partition1" alias_major="3" alias_minor="1" enabled="true" /> This would redirect /dev/hda1 to /dev/cobd0. Another nice feature might be to create an entry either a directory or a file in /proc that startup scripts can check for to determine if you're running under colinux - something like if [ -e /proc/colinux ] then .... else fi (Excuse me if my bash syntax isn't quite correct, but I think you get the idea. :-) ) |
From: John N. <jo...@mo...> - 2004-04-19 17:00:51
|
Daniel Slater wrote: > Another nice feature might be to create an entry either a directory or > a file in /proc that startup scripts can check for to determine if > you’re running under colinux – something like > > if [ -e /proc/colinux ] then > > …. > > else > > fi > > (Excuse me if my bash syntax isn’t quite correct, but I think you get > the idea. J ) > In the mean time, you can use the <bootparams> element in the XML file to set an environmental variables that you can test on.... for example: <bootparams>root=vmlinux BOOTSYSTEM=colinux</bootparams> The colinux daemon will pass this on to the kernel, and the kernel will pass on the BOOTSYSTEM portion (which it doesn't understand) to init, and init will setup the appropriate environmental variable. Once setup, your startup scripts can test for this by a number of means, such as: if [ x"$BOOTSYSTEM" == x"colinux"]; then blah, blah, blah fi I'm doing this right now in my dual-boot environment to automatically adjust various configuration files (in /etc) at startup and shutdown so that everything continues to work. That is, I have effectively created separate hardware profiles, and I use the presence of this environment variable to distinguish them. |
From: Daniel R. S. <dan...@ya...> - 2004-04-19 17:18:05
|
Very interesting, I wasn't aware you could do this - you learn something new evey day :). Would it be possible to use this method to dynamically change /etc/fstab during startup? i.e. you could have something like /etc/fstab.native, /etc/fstab.colinux and then early in your startup code have something like: rm /etc/fstab if [ x"$BOOTSYSTEM" == x"colinux"]; then ln -s /etc/fstab.colinux /etc/fstab else ln -s /etc/fstab.native /etc/fstab fi or does the linux startup process read /etc/fstab before executing any of it's startup scripts? Dan -----Original Message----- From: col...@li... [mailto:col...@li...] On Behalf Of John Nelson Sent: Monday, April 19, 2004 1:01 PM To: col...@li... Subject: Re: [coLinux-devel] /dev/hd* vs. /dev/cobd* Daniel Slater wrote: > Another nice feature might be to create an entry either a directory or > a file in /proc that startup scripts can check for to determine if > you're running under colinux - something like > > if [ -e /proc/colinux ] then > > .. > > else > > fi > > (Excuse me if my bash syntax isn't quite correct, but I think you get > the idea. J ) > In the mean time, you can use the <bootparams> element in the XML file to set an environmental variables that you can test on.... for example: <bootparams>root=vmlinux BOOTSYSTEM=colinux</bootparams> The colinux daemon will pass this on to the kernel, and the kernel will pass on the BOOTSYSTEM portion (which it doesn't understand) to init, and init will setup the appropriate environmental variable. Once setup, your startup scripts can test for this by a number of means, such as: if [ x"$BOOTSYSTEM" == x"colinux"]; then blah, blah, blah fi I'm doing this right now in my dual-boot environment to automatically adjust various configuration files (in /etc) at startup and shutdown so that everything continues to work. That is, I have effectively created separate hardware profiles, and I use the presence of this environment variable to distinguish them. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ coLinux-devel mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-devel |
From: Ronald P. <pij...@ds...> - 2004-04-19 18:38:15
Attachments:
preinit
|
On Mon, Apr 19, 2004 at 01:17:51PM -0400, Daniel R. Slater wrote: > Very interesting, > I wasn't aware you could do this - you learn something new evey day := ). > Would it be possible to use this method to dynamically change /etc/fsta= b > during startup? i.e. you could have something like /etc/fstab.native, > /etc/fstab.colinux and then early in your startup code have something l= ike: > > rm /etc/fstab > > if [ x"$BOOTSYSTEM" =3D=3D x"colinux"]; then > ln -s /etc/fstab.colinux /etc/fstab > else > ln -s /etc/fstab.native /etc/fstab > fi > > or does the linux startup process read /etc/fstab before executing any = of > it's startup scripts? In fact, I have written something like that. I use the "init=3D/root/prei= nit" kernel parameter, where /root/preinit is a script that `fixes' things. See attachment. If people find this useful, please add to the wiki. Comments are welcome. Ronald. |
From: John N. <jo...@mo...> - 2004-04-19 23:06:33
|
Ronald Pijnacker wrote: >On Mon, Apr 19, 2004 at 01:17:51PM -0400, Daniel R. Slater wrote: > > >>Very interesting, >> I wasn't aware you could do this - you learn something new evey day :). >>Would it be possible to use this method to dynamically change /etc/fstab >>during startup? i.e. you could have something like /etc/fstab.native, >>/etc/fstab.colinux and then early in your startup code have something like: >> >>rm /etc/fstab >> >>if [ x"$BOOTSYSTEM" == x"colinux"]; then >> ln -s /etc/fstab.colinux /etc/fstab >>else >> ln -s /etc/fstab.native /etc/fstab >>fi >> >>or does the linux startup process read /etc/fstab before executing any of >>it's startup scripts? >> >> > >In fact, I have written something like that. I use the "init=/root/preinit" >kernel parameter, where /root/preinit is a script that `fixes' things. >See attachment. If people find this useful, please add to the wiki. > >Comments are welcome. > >Ronald. > > A most excellent idea! Much superior to my approach, since you can effectively do everything all in one script, rather than relying on individual changes here and there throughout the system. This solution, although practical, does have one theoretical drawback: eventually we'll have fsck working again, and the fact that this approach requires us to modify the file system before checking it stinks a bit. We could duplicate the check, but that is redundant. The best long-term solution, IMHO, is to go with Sergey Okhapkin's suggestion (in this same thread) and find a way to make the colinux daemon "educate" the kernel at boot time that certain major/minor numbers devices are actually aliases for other ones (so, for example, we could make /dev/hdb1 and /dev/cobd2 become the same thing), but only when running in hosted -- not native -- mode. |
From: Sergey O. <so...@so...> - 2004-04-19 23:54:34
|
John Nelson wrote: > This solution, although practical, does have one theoretical drawback: > eventually we'll have fsck working again, and the fact that this > approach requires us to modify the file system before checking it stinks > a bit. We could duplicate the check, but that is redundant. The best > long-term solution, IMHO, is to go with Sergey Okhapkin's suggestion (in > this same thread) and find a way to make the colinux daemon "educate" > the kernel at boot time that certain major/minor numbers devices are > actually aliases for other ones (so, for example, we could make > /dev/hdb1 and /dev/cobd2 become the same thing), but only when running > in hosted -- not native -- mode. That was not my suggestion but you forced me to think a little bit... The solution is simple! Don't reinvent the wheel but... use devfs:-) Here is a fragment of my dual-boot compatible (now :-) fstab: /dev/hda2 /boot ext2 noauto,noatime 1 1 /dev/hda6 / ext3 noatime 0 0 /dev/hda7 none swap sw 0 0 And the additional lines in /etc/devfsd.conf: #coLinux stuff REGISTER ^cobd0$ CFUNCTION GLOBAL mksymlink $devname hda6 UNREGISTER ^cobd0$ CFUNCTION GLOBAL unlink hda6 REGISTER ^cobd3$ CFUNCTION GLOBAL mksymlink $devname hda2 UNREGISTER ^cobd3$ CFUNCTION GLOBAL unlink hda2 REGISTER ^cobd1$ CFUNCTION GLOBAL mksymlink $devname hda7 UNREGISTER ^cobd1$ CFUNCTION GLOBAL unlink hda7 Huh? -- Sergey Okhapkin Somerset, NJ |
From: Kevin J. M. Jr. <nir...@ne...> - 2004-04-20 00:33:09
|
But isn't devfs deprecated? I know it'll work, but is this really the best solution? -- Kevin Sergey Okhapkin wrote: > That was not my suggestion but you forced me to think a little bit... > The solution is simple! Don't reinvent the wheel but... use devfs:-) |
From: Sergey O. <so...@so...> - 2004-04-20 01:02:19
|
Kevin J. Menard, Jr. wrote: > But isn't devfs deprecated? I know it'll work, but is this really the > best solution? > Devfs successor udev can do exactly the same. -- Sergey Okhapkin Somerset, NJ |
From: Kevin J. M. Jr. <nir...@ne...> - 2004-04-20 05:42:21
|
Oh ok. That's good to know. I use a gentoo system, so I've just been using devfs anyway. -- Kevin On Apr 19, 2004, at 9:03 PM, Sergey Okhapkin wrote: > Devfs successor udev can do exactly the same. |
From: John N. <jo...@mo...> - 2004-04-20 06:13:00
|
Kevin J. Menard, Jr. wrote: > Oh ok. That's good to know. I use a gentoo system, so I've just been > using devfs anyway. > > > On Apr 19, 2004, at 9:03 PM, Sergey Okhapkin wrote: > > Devfs successor udev can do exactly the same. Udev won't work under 2.4 kernels, so it should only be remembered for when we all have colinux-2.6 running. Devfs, although obsolete, will continue to work for the foreseeable future. |
From: Daniel R. S. <dan...@ya...> - 2004-04-20 13:11:16
|
I'm not sure how using devfs really solves the problem for dual-boot. Don't you still need 2 different /etc/devfsd.conf files, one for running under colinux and one for running natively? Dan -----Original Message----- From: Sergey Okhapkin [mailto:so...@so...] Sent: Monday, April 19, 2004 7:55 PM To: John Nelson Cc: 'Ronald Pijnacker'; 'Daniel R. Slater'; col...@li... Subject: Solved! Was: [coLinux-devel] /dev/hd* vs. /dev/cobd* John Nelson wrote: > This solution, although practical, does have one theoretical drawback: > eventually we'll have fsck working again, and the fact that this > approach requires us to modify the file system before checking it stinks > a bit. We could duplicate the check, but that is redundant. The best > long-term solution, IMHO, is to go with Sergey Okhapkin's suggestion (in > this same thread) and find a way to make the colinux daemon "educate" > the kernel at boot time that certain major/minor numbers devices are > actually aliases for other ones (so, for example, we could make > /dev/hdb1 and /dev/cobd2 become the same thing), but only when running > in hosted -- not native -- mode. That was not my suggestion but you forced me to think a little bit... The solution is simple! Don't reinvent the wheel but... use devfs:-) Here is a fragment of my dual-boot compatible (now :-) fstab: /dev/hda2 /boot ext2 noauto,noatime 1 1 /dev/hda6 / ext3 noatime 0 0 /dev/hda7 none swap sw 0 0 And the additional lines in /etc/devfsd.conf: #coLinux stuff REGISTER ^cobd0$ CFUNCTION GLOBAL mksymlink $devname hda6 UNREGISTER ^cobd0$ CFUNCTION GLOBAL unlink hda6 REGISTER ^cobd3$ CFUNCTION GLOBAL mksymlink $devname hda2 UNREGISTER ^cobd3$ CFUNCTION GLOBAL unlink hda2 REGISTER ^cobd1$ CFUNCTION GLOBAL mksymlink $devname hda7 UNREGISTER ^cobd1$ CFUNCTION GLOBAL unlink hda7 Huh? -- Sergey Okhapkin Somerset, NJ |
From: Sergey O. <so...@so...> - 2004-04-20 13:20:33
|
No I don't. /dev/cobd* are not exist when running natively and devfsd don't attempt to create symlinks. These devfsd.conf entries have an effect when running under colinux only. > -----Original Message----- > From: col...@li... > [mailto:col...@li...] On Behalf > Of Daniel R. Slater > Sent: Tuesday, April 20, 2004 9:11 AM > To: col...@li... > Subject: RE: Solved! Was: [coLinux-devel] /dev/hd* vs. /dev/cobd* > > > I'm not sure how using devfs really solves the problem for > dual-boot. Don't you still need 2 different /etc/devfsd.conf > files, one for running under colinux and one for running natively? > > Dan > > -----Original Message----- > From: Sergey Okhapkin [mailto:so...@so...] > Sent: Monday, April 19, 2004 7:55 PM > To: John Nelson > Cc: 'Ronald Pijnacker'; 'Daniel R. Slater'; > col...@li... > Subject: Solved! Was: [coLinux-devel] /dev/hd* vs. /dev/cobd* > > John Nelson wrote: > > > This solution, although practical, does have one > theoretical drawback: > > eventually we'll have fsck working again, and the fact that this > > approach requires us to modify the file system before > checking it stinks > > a bit. We could duplicate the check, but that is > redundant. The best > > long-term solution, IMHO, is to go with Sergey Okhapkin's > suggestion (in > > this same thread) and find a way to make the colinux daemon > "educate" > > the kernel at boot time that certain major/minor numbers > devices are > > actually aliases for other ones (so, for example, we could make > > /dev/hdb1 and /dev/cobd2 become the same thing), but only > when running > > in hosted -- not native -- mode. > > That was not my suggestion but you forced me to think a little bit... > The solution is simple! Don't reinvent the wheel but... use devfs:-) > > Here is a fragment of my dual-boot compatible (now :-) fstab: > > /dev/hda2 /boot ext2 noauto,noatime > 1 1 > > /dev/hda6 / ext3 noatime > 0 0 > > /dev/hda7 none swap sw > 0 0 > > > And the additional lines in /etc/devfsd.conf: > > #coLinux stuff > > REGISTER ^cobd0$ CFUNCTION GLOBAL mksymlink $devname hda6 > > UNREGISTER ^cobd0$ CFUNCTION GLOBAL unlink hda6 > > > > REGISTER ^cobd3$ CFUNCTION GLOBAL mksymlink $devname hda2 > > UNREGISTER ^cobd3$ CFUNCTION GLOBAL unlink hda2 > > > > REGISTER ^cobd1$ CFUNCTION GLOBAL mksymlink $devname hda7 > > UNREGISTER ^cobd1$ CFUNCTION GLOBAL unlink hda7 > > > Huh? > > -- > Sergey Okhapkin > Somerset, NJ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President > and CEO of GenToo technologies. Learn everything from > fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > > |
From: <ch...@to...> - 2004-04-20 14:19:33
|
Not every distro uses devfs so this would not qualify as one simple solution that would work for every distro. Also, Dan your mapping Idea would make it alot easier to use native setup programs that do not have the option of "install to /dev/cobd0" 1 big potential use of coLinux on windows or Linux will be to try out different distros. Another neat idea may be to have the ability to tunnel the emulation of the blockdevice through another program (or an addon to the console) so that removable disks that are images can be swapped. chris > I'm not sure how using devfs really solves the problem for dual-boot. > Don't > you still need 2 different /etc/devfsd.conf files, one for running under > colinux and one for running natively? > > Dan > > -----Original Message----- > From: Sergey Okhapkin [mailto:so...@so...] > Sent: Monday, April 19, 2004 7:55 PM > To: John Nelson > Cc: 'Ronald Pijnacker'; 'Daniel R. Slater'; > col...@li... > Subject: Solved! Was: [coLinux-devel] /dev/hd* vs. /dev/cobd* > > John Nelson wrote: > >> This solution, although practical, does have one theoretical drawback: >> eventually we'll have fsck working again, and the fact that this >> approach requires us to modify the file system before checking it stinks >> a bit. We could duplicate the check, but that is redundant. The best >> long-term solution, IMHO, is to go with Sergey Okhapkin's suggestion (in >> this same thread) and find a way to make the colinux daemon "educate" >> the kernel at boot time that certain major/minor numbers devices are >> actually aliases for other ones (so, for example, we could make >> /dev/hdb1 and /dev/cobd2 become the same thing), but only when running >> in hosted -- not native -- mode. > > That was not my suggestion but you forced me to think a little bit... > The solution is simple! Don't reinvent the wheel but... use devfs:-) > > Here is a fragment of my dual-boot compatible (now :-) fstab: > > /dev/hda2 /boot ext2 noauto,noatime 1 1 > > /dev/hda6 / ext3 noatime 0 0 > > /dev/hda7 none swap sw 0 0 > > > And the additional lines in /etc/devfsd.conf: > > #coLinux stuff > > REGISTER ^cobd0$ CFUNCTION GLOBAL mksymlink $devname hda6 > > UNREGISTER ^cobd0$ CFUNCTION GLOBAL unlink hda6 > > > > REGISTER ^cobd3$ CFUNCTION GLOBAL mksymlink $devname hda2 > > UNREGISTER ^cobd3$ CFUNCTION GLOBAL unlink hda2 > > > > REGISTER ^cobd1$ CFUNCTION GLOBAL mksymlink $devname hda7 > > UNREGISTER ^cobd1$ CFUNCTION GLOBAL unlink hda7 > > > Huh? > > -- > Sergey Okhapkin > Somerset, NJ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: <ch...@to...> - 2004-04-20 10:54:51
|
I agree that the file system should not be modified before being checked. Also I feel that the solutions should be one which does not require modification to the distro's kernel for native mode boot. The previous method that I used was make /etc/fstab and other files that needed changed in two different directories and a chain of sym links directed through /initrd directed to the apropriate folder. The actual initrd would have a sym link to the native folder and the /initrd mount point would have sym link to the coLinux folder so depending on if an initrd was used the links in the mountpoint would be covered. see topologilinux howto in the wiki for details. this can get confusing I did like the original idea of this thread how I understood it. donot have cobd? in /dev just have the colinux kernel map hd?? to them. So this way a distro could be used with much less modification. But this should only be done if it is possible to set the mapping in the config file hda1 = cobd0 somewhere that would be easy to change for different hardware so sda1 = cobd0 would be just as easy chris > Ronald Pijnacker wrote: > >>On Mon, Apr 19, 2004 at 01:17:51PM -0400, Daniel R. Slater wrote: >> >> >>>Very interesting, >>> I wasn't aware you could do this - you learn something new evey day >>> :). >>>Would it be possible to use this method to dynamically change /etc/fstab >>>during startup? i.e. you could have something like /etc/fstab.native, >>>/etc/fstab.colinux and then early in your startup code have something >>> like: >>> >>>rm /etc/fstab >>> >>>if [ x"$BOOTSYSTEM" == x"colinux"]; then >>> ln -s /etc/fstab.colinux /etc/fstab >>>else >>> ln -s /etc/fstab.native /etc/fstab >>>fi >>> >>>or does the linux startup process read /etc/fstab before executing any >>> of >>>it's startup scripts? >>> >>> >> >>In fact, I have written something like that. I use the >> "init=/root/preinit" >>kernel parameter, where /root/preinit is a script that `fixes' things. >>See attachment. If people find this useful, please add to the wiki. >> >>Comments are welcome. >> >>Ronald. >> >> > A most excellent idea! Much superior to my approach, since you can > effectively do everything all in one script, rather than relying on > individual changes here and there throughout the system. > > This solution, although practical, does have one theoretical drawback: > eventually we'll have fsck working again, and the fact that this > approach requires us to modify the file system before checking it stinks > a bit. We could duplicate the check, but that is redundant. The best > long-term solution, IMHO, is to go with Sergey Okhapkin's suggestion (in > this same thread) and find a way to make the colinux daemon "educate" > the kernel at boot time that certain major/minor numbers devices are > actually aliases for other ones (so, for example, we could make > /dev/hdb1 and /dev/cobd2 become the same thing), but only when running > in hosted -- not native -- mode. > |
From: Daniel R. S. <dan...@ya...> - 2004-04-20 11:57:56
|
In my original post, this is exactly what I proposed, although I proposed a mapping based on major and minor numbers: <block_device index="0" path="\Device\Harddisk0\Partition1" alias_major="3" alias_minor="1" enabled="true" /> This maps /dev/hda1 to /dev/cobd0 Dan -----Original Message----- From: col...@li... [mailto:col...@li...] On Behalf Of ch...@to... Sent: Tuesday, April 20, 2004 6:55 AM To: John Nelson Cc: 'Ronald Pijnacker'; 'Daniel R. Slater'; col...@li... Subject: Re: [coLinux-devel] /dev/hd* vs. /dev/cobd* But this should only be done if it is possible to set the mapping in the config file hda1 = cobd0 somewhere that would be easy to change for different hardware so sda1 = cobd0 would be just as easy coLinux-devel mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-devel |
From: <ch...@to...> - 2004-04-20 12:57:46
|
Ok, I had forgotten the exact details of your original post. The major and minor numbers can be a little more confusing than mapping devices would be more in guru teritory than intermediate linux user. But with the Gui configuration tool linux beginners would never have to see it. I like this idea alot. It would make porting root images to work dual mode alot easier. IMHO the less changes outside kernel space for the native to colinux boot the better. So unless there is a good reason not to do this then I think the option should be avaliable. chris > In my original post, this is exactly what I proposed, although I proposed > a > mapping based on major and minor numbers: > > <block_device index="0" path="\Device\Harddisk0\Partition1" > alias_major="3" > alias_minor="1" enabled="true" /> > > This maps /dev/hda1 to /dev/cobd0 > > Dan > > -----Original Message----- > From: col...@li... > [mailto:col...@li...] On Behalf Of > ch...@to... > Sent: Tuesday, April 20, 2004 6:55 AM > To: John Nelson > Cc: 'Ronald Pijnacker'; 'Daniel R. Slater'; > col...@li... > Subject: Re: [coLinux-devel] /dev/hd* vs. /dev/cobd* > > But this should only be done if it is possible to set the mapping in the > config file > hda1 = cobd0 > somewhere that would be easy to change for different hardware so > sda1 = cobd0 would be just as easy > > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Samuel L. <sa...@li...> - 2004-04-23 22:31:06
|
<ch...@to...> wrote in message news:157...@we...... > Ok, I had forgotten the exact details of your original post. > > The major and minor numbers can be a little more confusing than mapping > devices would be more in guru teritory than intermediate linux user. But > with the Gui configuration tool linux beginners would never have to see > it. > > I like this idea alot. It would make porting root images to work dual mode > alot easier. IMHO the less changes outside kernel space for the native to > colinux boot the better. > > So unless there is a good reason not to do this then I think the option > should be avaliable. I like it because it doesn't taint the distro installtion. The coLinux specific magic is part of the coLinux config. Sam > > chris > > > In my original post, this is exactly what I proposed, although I proposed > > a > > mapping based on major and minor numbers: > > > > <block_device index="0" path="\Device\Harddisk0\Partition1" > > alias_major="3" > > alias_minor="1" enabled="true" /> > > > > This maps /dev/hda1 to /dev/cobd0 > > > > Dan > > > > -----Original Message----- > > From: col...@li... > > [mailto:col...@li...] On Behalf Of > > ch...@to... > > Sent: Tuesday, April 20, 2004 6:55 AM > > To: John Nelson > > Cc: 'Ronald Pijnacker'; 'Daniel R. Slater'; > > col...@li... > > Subject: Re: [coLinux-devel] /dev/hd* vs. /dev/cobd* > > > > But this should only be done if it is possible to set the mapping in the > > config file > > hda1 = cobd0 > > somewhere that would be easy to change for different hardware so > > sda1 = cobd0 would be just as easy > > > > coLinux-devel mailing list > > coL...@li... > > https://lists.sourceforge.net/lists/listinfo/colinux-devel > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IBM Linux Tutorials > > Free Linux tutorial presented by Daniel Robbins, President and CEO of > > GenToo technologies. Learn everything from fundamentals to system > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > > _______________________________________________ > > coLinux-devel mailing list > > coL...@li... > > https://lists.sourceforge.net/lists/listinfo/colinux-devel > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click |
From: Ronald P. <pij...@ds...> - 2004-04-21 19:56:50
|
> [...] The best > long-term solution, IMHO, is to go with Sergey Okhapkin's suggestion (in > this same thread) and find a way to make the colinux daemon "educate" > the kernel at boot time that certain major/minor numbers devices are > actually aliases for other ones (so, for example, we could make > /dev/hdb1 and /dev/cobd2 become the same thing), but only when running > in hosted -- not native -- mode. That still leaves the problem of having different settings other than fstab (networking, xdm.conf, default-runlevel entries to name a few). In my script I can handle these quite well. I've spend some time investigating initd, but gave up after a while (lack of good documentation). I don't see an elegant alternative solution. This is something that a lot of users will run into, I guess. Ronald. |
From: Eric S. J. <es...@ha...> - 2004-04-21 20:39:47
|
Ronald Pijnacker wrote: >>[...] The best >>long-term solution, IMHO, is to go with Sergey Okhapkin's suggestion (in >>this same thread) and find a way to make the colinux daemon "educate" >>the kernel at boot time that certain major/minor numbers devices are >>actually aliases for other ones (so, for example, we could make >>/dev/hdb1 and /dev/cobd2 become the same thing), but only when running >>in hosted -- not native -- mode. > > > That still leaves the problem of having different settings other than > fstab (networking, xdm.conf, default-runlevel entries to name a few). > In my script I can handle these quite well. I've spend some time > investigating initd, but gave up after a while (lack of good > documentation). I don't see an elegant alternative solution. This > is something that a lot of users will run into, I guess. I've often thought it would be useful in many contexts to have indirect symlinks. Specifically a symlinks which returns a file based on an entry in a database. This file could be a real file based on some calculation or even a window onto a file or database. Could be very powerful. I must admit having not one whit of clue on how to implement it as my OS internals knowledge is almost 20 years old and on a different structure of OS entirely. Although I will admit it was kind of cool implementing a distributed file system before 99 percent of the technical world could spell it let alone know what it was. all if I have to guess, I would create a new inode code or type. Something to identify the entry. It would functionally be the same as symlink so we could reuse is much of that path as possible. I wish I knew whether or not something like the VFS layer would be a good point for file switching but assuming it is, as soon as you could detect that you had a indirect link, you would do a look up in a database or dbm file for the original path, what you need to run to generates the real path and once you have the real path, return the appropriate information (real inode etc. etc.) again, this is extremely crude guess based on very old knowledge but just trying to give some structure to the idea. |
From: John N. <jo...@mo...> - 2004-04-21 22:44:29
|
Eric S. Johansson wrote: > Ronald Pijnacker wrote: > >> John Nelson wrote: >> >>> [...] The best long-term solution, IMHO, is to go with Sergey >>> Okhapkin's suggestion (in this same thread) and find a way to make >>> the colinux daemon "educate" the kernel at boot time that certain >>> major/minor numbers devices are actually aliases for other ones (so, >>> for example, we could make /dev/hdb1 and /dev/cobd2 become the same >>> thing), but only when running in hosted -- not native -- mode. >> >> >> That still leaves the problem of having different settings other than >> fstab (networking, xdm.conf, default-runlevel entries to name a few). >> In my script I can handle these quite well. I've spend some time >> investigating initd, but gave up after a while (lack of good >> documentation). I don't see an elegant alternative solution. This >> is something that a lot of users will run into, I guess. > > > I've often thought it would be useful in many contexts to have > indirect symlinks. Specifically a symlinks which returns a file based > on an entry in a database. This file could be a real file based on > some calculation or even a window onto a file or database. > ... > It would functionally be the same as symlink so we could reuse is much > of that path as possible. I wish I knew whether or not something like > the VFS layer would be a good point for file switching but assuming it > is, as soon as you could detect that you had a indirect link, you > would do a look up in a database or dbm file for the original path, > what you need to run to generates the real path and once you have the > real path, return the appropriate information (real inode etc. etc.) Okay, I'm going to philosophize for a bit... (I figure that it's a good idea right about now since we all seem to be groping around for solutions and not really liking many of the ones that we already have.) The proc, devfs file systems already do this type of virtualization thing, inasmuch as the files are really just "virtual" files. For that matter, NFS and SMBFS also do it to a certain degree, inasmuch as accessing those files doesn't actually open anything on the local machine, but rather causes network activity to occur. My point here is just that a file is not necessarily a group of bytes on a local hard drive - it can be disk information, but can also be network info, kernel info, or basically anything else we care to implement. For the short term, I'd say that the devfs/udev approach is best for dealing with fstab related issues, but we are really talking about concocting a system that has multiple configuration *profiles*. When I think about this, the best precedent that occurs to me is either in a laptop computer that acquires whole new bits of hardware when connected to a docking station, or else USB devices that are designed to be inserted/removed regularly. Since I am philosophizing here, I'd generalize this to say that the system configuration changes dynamically with its environment. (Of course, the changes are not arbitrary, and cannot be to any extent, but this is just a caveat.) Part of the problem we're dealing with is that the existing configuration system in Unix is basically a bunch of flat-file databases (that is, all data pertaining to a particular configuration is contained within one or more flat-files). While extraordinarily easy to work with, it has nagging property of being static -- there really is no such thing as a schizophrenic fstab file, for example, that suddenly *becomes* the correct version because of an environmental change. The historical solution to this has always been to employ indirection -- where the place to look for the configuration doesn't actually have anything in it except a reference of some kind that points to the current, correct location. Unix uses this extensively to handle separate user instances (mostly using environmental variables such as $HOME, $USER, or even the dreaded '~'). Anyone who has ever perused the Windows registry will also notice the same type of thing happening there -- consider the HKEY_CURRENT_USER subtree, or the fact that each configuration is in a "control set". For that matter, all of the DosDevices we like to use with CoLinux are actually aliases for different COM identifies (although I haven't checked, I suspect they actually point to the device drivers for those particular pieces of hardware). I am not sufficiently familiar with MacOS to say how they do it, but I have always been impressed with the their ability to take "plug 'n play" to a new level when it comes to USB peripherals -- for the most part, they just work. The great thing about the original thread problem (mount disks when fstab can't be counted on) is that devfs and udev (Sergey Okhapkin's later suggestion) provides this *exact* type of dynamic referencing that we need to make this happen. Nevertheless, the solution, while effective, is still sloppy since it depends on a side-effect to work. The side effect to which I am referring is that it depends on the presence of a kernel driver with major number 117 -- that's our magic cobd number -- in order to decide when it should symlink /dev/hdx to the appropriate /dev/cobdy. Although we would tell them to _always_ symlink /dev/hda2 to /dev/cobd1 (for example), it only actually does it if device (117,1) is present -- so the fact that our linux system still works when booted natively is a side-effect. I think we really ought to depend on something a little more reliable than the presence of a device major number. Regardless of this qualm, it still works, and does not require us to modify the file system before any fs checks are made, which is a definite plus. So far, the best solution for every other type of config file seems to be to replace it (or else replace its symlink). I can't say I really like this one either but I am at a loss as to a better approach. The reason I don't like it is because we have essentially moved the switch (ie the choice of going with one configuration or another) all the way to the hard drive. While I think the *choices* should be there, the thing controlling whether we go with choice A or B ought to be in memory. To me, the existing solution seems like driving 50 kilometers to another town to buy milk when you could just walk to the grocer down the street. Perhaps I am being overly nit-picky on this one, but I am also at a loss for how to fix it, since the /etc directory must exist on the root file system, which will make it *really* hard to virtualize it in way. Of course, what I'd really like to see (personally) is the ability to have a symlink destination given dynamically (which I think is kind of like what Eric Johansson was talking about). Instead of having the symlink fixed in the filesystem, it would be advantageous to have it point to something in memory, which in turn points to some other file. The closest thing to this that I'm aware of is block special files (like /dev/cobd, /dev/hda, etc), but that's just ugly, since we'd really like to know what the file was linked to, just like we can see what a symlink points to. So far as I am aware, ext2 doesn't support anything like this, and I doubt if any other common file systems do either. Obviously, there would need to be some kind of daemon running that would effect the precise choice whenever one of its link files was accessed, but the issue still remains as to how a link to this daemon would exist in an ext2 filesystem (which it would have to be able to do so long as we can't virtualize /etc). Of course, it goes without saying that an ability like this would be a tremendous boon for anything requiring dynamic configuration. But others would simply argue that flat files should be done away with entirely and replaced with hierarchical databases (which is precisely what Microsoft did when it moved from away INI files to the registry, and what the Gnome people have done with gconf). Unix systems are already quite good at switching things up based on user, and we are trying to figure out the best way forward for switching things up based on hardware environment. Maybe we should try to glean inspiration from MacOS X (which is a BSD derrivative and handles dynamic hardware nicely) and Knoppix (which is dynamically self-configuring). That is, of course, unless any of you out there has any good ideas as to how to virtualize a file on an existing file system. Anyway, I'm just philosophizing here, perhaps its time I got back into the real world. Back to work... |
From: <ch...@to...> - 2004-04-21 23:06:22
|
If I am not mistaken changing the filesystem would require patching the kernel used for the native mode boot. I think it would be best to have a system that could use a stock kernel when booting natively. Also this would limit the choice of filesystem used so if this was added to ext3 then people would not be able to use reiserfs. there should be plenty of ways to handle this in init scripts. someone on this list once refered me to hprofile http://hprofile.sourceforge.net/ but it is a bit complex and has features that would not easily work with all distro's with the fstab problem solved networking would be the only other thing that I can think of off hand. I'll try to give this some thought how about some ideas of other things that might need changed. How about a "coetc" image that could be mounted on etc? a pre init script could do this without an fstab entry. Just throwing an idea out there I havn't completely thought it through yet. chris > > I've often thought it would be useful in many contexts to have indirect > symlinks. Specifically a symlinks which returns a file based on an > entry in a database. This file could be a real file based on some > calculation or even a window onto a file or database. > > > all if I have to guess, I would create a new inode code or type. > Something to identify the entry. It would functionally be the same as > symlink so we could reuse is much of that path as possible. I wish I > knew whether or not something like the VFS layer would be a good point > for file switching but assuming it is, as soon as you could detect that > you had a indirect link, you would do a look up in a database or dbm > file for the original path, what you need to run to generates the real > path and once you have the real path, return the appropriate information > (real inode etc. etc.) > > again, this is extremely crude guess based on very old knowledge but > just trying to give some structure to the idea. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: John N. <jo...@mo...> - 2004-04-21 23:54:37
|
ch...@to... wrote: >there should be plenty of ways to handle this in init scripts. >someone on this list once refered me to hprofile >http://hprofile.sourceforge.net/ >but it is a bit complex and has features that would not easily work with >all distro's > > That's not a bad idea. Beyond the distribution problems, though, doesn't it still just modify the file system? That makes it unsuitable for anything that occurs before the root file system is remounted into read-write mode (such as, for example, checking the root file system). >with the fstab problem solved networking would be the only other thing >that I can think of off hand. I'll try to give this some thought >how about some ideas of other things that might need changed. > > I also have dual samba configurations and dual /etc/modules.conf files (so my networking still works); I also just read a post earlier about getting sound to work from xmms under colinux. I'm not sure, but that might also involve some dynamic changes when moving from hosted to native mode. I can imagine a few other uses as well. >How about a "coetc" image that could be mounted on etc? a pre init script >could do this without an fstab entry. Just throwing an idea out there I >havn't completely thought it through yet. > I had the same thought not long after my last post (a certain epithet about "great minds" occurs to me right now... :-)).... although I have also not yet fully thought it through, some ideas did occur to me: * I agree that it needs to be done before init loads; otherwise little things like loading the correct inittab won't work. * This makes it rather dangerous to switch configuration sets after a boot. All kinds of things could suddently stop working. * It is unnecessary to devote partitions to this, since we can just use image files with a loopback. * It is probably best to keep these image files within the linux file space. The most sensible place to keep them is on the root file system, but obviously not within the /etc directory thereon. * To really be reasonable, there would need to be more than one of these: one for each configuration set (at present, we might as well call them the "hosted" and "native" sets). * It might even be possible to compress the images (any good compressed file systems available?) * It will make adding new startup daemons a real pain, since you'd have to duplicate the scripts and configs to the other versions of /etc. So this might be a typical startup sequence: 1. Because of boot parameters telling the kernel to do so, the kernel executes a pre-init script. 2. That script makes a decision as to what hardware environment it is running in (using environmental variables as with how linux currently differentiates user environments, presence of a cobd driver loaded in the kernel space, ...., whatever, the method here is not really important). 3. The script mounts the appropriate image onto /etc as read-only (you can't mount it read-write so long as the root file system is read-only, since the image is actually just a file). 4. Once the preinit script has returned, the kernel starts init. 5. Everything else proceeds normally until the root partition is remounted read-write. 6. Immediately after the root fs is remounted, the /etc mount is also remounted read-write. This is important since the /etc/mtab file (and others) gets modified pretty quickly, and we'd best be modifying the correct one! (An alternative would be to make all files that change into symlinks, perhaps onto somewhere in /var, but then we'd have to be sure that /var is already mounted, so some more elegant thinking would need to go into that one.) 7. The system boots up, completely unaware that an entirely different configuration is possible. Since each configuration is nicely encapsulated as an image file, all of the configuration elements are nicely separated, which makes commiting errors less likely. Still, we need to find out whether we can mount image files that early in the bootup process (because that's a real show-stopper if we can't), and the redundancy of configurations could sometimes be annoying (unless we could find some miraculous way to share *some* of the configurations between the two sets). Further, there is the headache of duplicating scripts and other settings whenever something new is installed (or, conversely, removing them whenever something is uninstalled). Owing to the difficulties I just mentioned, I'd say this idea is just begging for its own configuration management software (which would take care of the redundant install/uninstall stuff for each of the config sets, as well as managing changes between the two, etc). |
From: <ch...@to...> - 2004-04-22 12:07:18
|
Ok, looks like we are getting there. I'll just make a few comments inline below. I would like to hear a comment from Dan Aloni on if the mapping that started this thread would be possible or undesireable for some reason. chris > >>there should be plenty of ways to handle this in init scripts. >>someone on this list once refered me to hprofile >>http://hprofile.sourceforge.net/ >>but it is a bit complex and has features that would not easily work with >>all distro's >> >> > That's not a bad idea. Beyond the distribution problems, though, > doesn't it still just modify the file system? That makes it unsuitable > for anything that occurs before the root file system is remounted into > read-write mode (such as, for example, checking the root file system). > Yeah, but assuming that the mapping of cobd? to major and minor numbers that are used by the physical drives. the fstab problem would be out of the way filesystem checking should be the same. Everything else should be able to be done after mounting / rw . right? >>with the fstab problem solved networking would be the only other thing >>that I can think of off hand. I'll try to give this some thought >>how about some ideas of other things that might need changed. >> >> > I also have dual samba configurations and dual /etc/modules.conf files > (so my networking still works); I also just read a post earlier about > getting sound to work from xmms under colinux. I'm not sure, but that > might also involve some dynamic changes when moving from hosted to > native mode. I can imagine a few other uses as well. > >>How about a "coetc" image that could be mounted on etc? a pre init script >>could do this without an fstab entry. Just throwing an idea out there I >>havn't completely thought it through yet. >> > I had the same thought not long after my last post (a certain epithet > about "great minds" occurs to me right now... :-)).... although I have > also not yet fully thought it through, some ideas did occur to me: > > * I agree that it needs to be done before init loads; otherwise > little things like loading the correct inittab won't work. > * This makes it rather dangerous to switch configuration sets after > a boot. All kinds of things could suddently stop working. > * It is unnecessary to devote partitions to this, since we can just > use image files with a loopback. I was thinking this myself but I was thinking there may be advantages to using a "partition" but havn't figured out what just yet. No problem this would be easy to change if a need came up for a "partition" > * It is probably best to keep these image files within the linux > file space. The most sensible place to keep them is on the root > file system, but obviously not within the /etc directory thereon. > * To really be reasonable, there would need to be more than one of > these: one for each configuration set (at present, we might as > well call them the "hosted" and "native" sets). why? /etc can contain the native mode files files in a directory that is used as a mount point just become invisible until the "partition"/loop is unmounted. Only problem is no access to modify native configuration when in hosted mode. > * It might even be possible to compress the images (any good > compressed file systems available?) cramfs ? I remember hearing about it. I do not know if it is depreciated or not and don't know about writability. Keep in mind any configuration management software that you spoke of before would need to mount it. > * It will make adding new startup daemons a real pain, since you'd > have to duplicate the scripts and configs to the other versions of > /etc. some thinking necessary here.......see comments near end. > > So this might be a typical startup sequence: > > 1. Because of boot parameters telling the kernel to do so, the kernel > executes a pre-init script. init=/pre-init would make # 2 unnecessary init would be init when booting native. Keeping the native mode files in the real /etc would make pre-init unnecessary for native mode. > 2. That script makes a decision as to what hardware environment it is > running in (using environmental variables as with how linux > currently differentiates user environments, presence of a cobd > driver loaded in the kernel space, ...., whatever, the method here > is not really important). > 3. The script mounts the appropriate image onto /etc as read-only > (you can't mount it read-write so long as the root file system is > read-only, since the image is actually just a file). > 4. Once the preinit script has returned, the kernel starts init. > 5. Everything else proceeds normally until the root partition is > remounted read-write. > 6. Immediately after the root fs is remounted, the /etc mount is also > remounted read-write. This is important since the /etc/mtab file > (and others) gets modified pretty quickly, and we'd best be > modifying the correct one! (An alternative would be to make all > files that change into symlinks, perhaps onto somewhere in /var, > but then we'd have to be sure that /var is already mounted, so > some more elegant thinking would need to go into that one.) > 7. The system boots up, completely unaware that an entirely different > configuration is possible. > > Since each configuration is nicely encapsulated as an image file, all of > the configuration elements are nicely separated, which makes commiting > errors less likely. Still, we need to find out whether we can mount > image files that early in the bootup process (because that's a real > show-stopper if we can't), I will not have time for that experiment for at least a week. > and the redundancy of configurations could > sometimes be annoying (unless we could find some miraculous way to share > *some* of the configurations between the two sets). maby make stuff that is definalty always shared sym links in both configs to real files somewhere else in the file system? converse of what you said in #6 of start sequence. > Further, there is > the headache of duplicating scripts and other settings whenever > something new is installed (or, conversely, removing them whenever > something is uninstalled). see last comment. > > Owing to the difficulties I just mentioned, I'd say this idea is just > begging for its own configuration management software (which would take > care of the redundant install/uninstall stuff for each of the config > sets, as well as managing changes between the two, etc). > Links to shared files would minimize this but something may still be necessary hopefully not. I really want to follow "KISS" on this. |
From: John N. <jo...@mo...> - 2004-04-23 23:14:54
Attachments:
pre-init
|
ch...@to... wrote: >> * It is unnecessary to devote partitions to this, since we can just >> use image files with a loopback. >> >> > >I was thinking this myself but I was thinking there may be advantages to >using a "partition" but havn't figured out what just yet. No problem this >would be easy to change if a need came up for a "partition" > > There is a slight speed advantage with a partition... when you are using a mounted image, you are reading a file system that exists *within* another file system. This additional level adds overhead, so a partition is a bit faster, albeit marginally. On the other hand, an image file has significantly greater flexibility, as you can make new "test" versions at will, keep old copies around, and so forth. I tend to prefer the image approach since I seriously doubt that the slight added speed of a real partition could possibly outweigh the problems created by its inherent lack of flexibiity, especially when one considers that you just might want to jumble images around every now and then. >> * To really be reasonable, there would need to be more than one of >> these: one for each configuration set (at present, we might as >> well call them the "hosted" and "native" sets). >> >> >why? /etc can contain the native mode files files in a directory that is >used as a mount point just become invisible until the "partition"/loop is >unmounted. Only problem is no access to modify native configuration when >in hosted mode. > > Perhaps I should have stated that one more clearly... yeah we could simply mount an image file on top of the /etc directory, effectively hiding the real contents until the image is unmounted, but that creates problems for copying configs and other settings between the two versions, since one of them might be hidden. Suppose, for example, that your native bootup used the normal /etc, while your hosted (colinux) bootup used an image mounted over /etc. In that case, the only time it would be safe to mess around with the two of them would be when you were booted into native mode (and so you could mount the colinux /etc image elsewhere, such as onto /mnt). My own purpose for using colinux was to be able to do work in both environments without rebooting, but this problem takes away the no-reboot advantage. By using separate image files, whichever one was not in use at a given time could be mounted elsewhere, and so configuration management between the two config sets is easy whether in a native or hosted boot. >>So this might be a typical startup sequence: >> >> 1. Because of boot parameters telling the kernel to do so, the kernel >> executes a pre-init script. >> >> >init=/pre-init >would make # 2 unnecessary init would be init when booting native. Keeping >the native mode files in the real /etc would make pre-init unnecessary for >native mode. > > #2 (which has the preinit script deciding which environment it is running in and making appropriate changes) is only unnecessary if we don't need to worry about mounting the native /etc... that is, if the native /etc is another image file, we'd still need a pre-init script. This means that lilo (or grub or whatever other bootloader you prefer) you need to append that kernel parameter, even for native boots. >>and the redundancy of configurations could >>sometimes be annoying (unless we could find some miraculous way to share >>*some* of the configurations between the two sets). >> > >maby make stuff that is definalty always shared sym links in both configs >to real files somewhere else in the file system? converse of what you said >in #6 of start sequence. > > > >>Owing to the difficulties I just mentioned, I'd say this idea is just >>begging for its own configuration management software (which would take >>care of the redundant install/uninstall stuff for each of the config >>sets, as well as managing changes between the two, etc). >> >> >> >Links to shared files would minimize this but something may still be >necessary hopefully not. I really want to follow "KISS" on this. > I thought of a variation on this approach that might be better, and is definitely simpler... while having multiple /etc's exist is an effective solution, I've still had a personal issue with the mess created by two versions of everything... even the excessively symlinking was a bit too sloppy for me to really like. Your suggestion to have the common stuff symlinked to something elsewhere was a good suggestion, but how about this... instead of symlinking the *common* stuff, symlink the *different* stuff.... let me explain. First, we leave /etc completely alone. We establish a pair of minimal file system images (maybe even just a few hundred KB each) which we put somewhere in the root filesystem (since we're leaving /etc alone, we might even put them in /etc). As before one of these images is for hosted bootups, the other is for native runs. We standardize the mount location, such that *one* of them will be mounted as /bootenviron, with the choice of which depending on whether the bootup was native or hosted. Within a mounted image, you expect to find various configuration files, such as /bootenviron/fstab, /bootenviron/modules.conf, /bootenviron/smb.conf, ect, etc. The real /etc has symbolic links into the mounted space. It might look like this: # ls -l /etc/fstab lrw-r--r-- 1 root root 5 Apr 21 13:37 /etc/fstab -> /bootenviron/fstab # mount ... /dev/loop0 on /bootenviron type ext2 (rw) # ls /etc/*img native_environ.img hosted_environ.img # My thinking on this one is that there is likely to be more in common between two different configuration sets than there would be different, so I'd prefer to spend my time managing differences rather than managing sameness. I already did this up and tested it, and it works, mostly. I've identified a couple of problems, a few of which remain outstanding. Here are all the problems I encountered: * Since the mounting occurs before the root file system is writeable, the mounting of /bootenviron was never recorded in the /etc/mtab file. My distro (debian), doesn't symlink this file against /proc/mounts. This means that running 'mount' or 'df -k' doesn't show the image file system. It also means that unmounting the root file system when the system shuts down will fail, and so the fs had to be checked on the next bootup. Just symlinking /etc/mtab to /proc/mounts seemed to fix it (although I'm a little bit leery of side-effects... those debian guys are usually pretty good at making sure that things are the way they are for a really good reason). * We can't check the file systems of the images before mounting them. This is because the images are just files on the root fs, and that has only been mounted read-only at this point. This isn't really a problem, since it isn't important to check the fs until we want to remount it for writing. We'll probably need an init script for remounting it anyway. * When my system goes down, it still seems to want the fstab file even after it has unmounted everything (including /bootenviron)... this doesn't seem to create any problems other than a "file not found" error. Nevertheless, I'd like to pay a bit more attention to what is going on there.... I'd rather not have any warnings at all. * I can't seem to remount the /bootenviron images unless I use a different loop device entirely. If I remount with the first one used (/dev/loop0, in my case) I get an error about the loop device been locked against writing. Perhaps this has something to do with the fact that it was originally mounted with the root file system in read-only mode. At first I thought this could solved by just unmounting it and the remounting using a different loop device, but.... (see next problem) * Whenever I unmount a loop device, I cannot reclaim that device. For instance, if I unmount /bootenviron (using /dev/loop0) and then try to remount it again with a call to the 'mount -o remount', it will complain that the device is still busy even though the image has been unmounted. * If I unmount the /bootenviron from its initial loop device (/dev/loop0) and then remount it with another device (/dev/loop1, for instance), the root fs will still be "busy" when the computer goes down for reboot, so that the root fs is not properly unmounted. Could it be that the kernel is unable to cope with the remount? (either because the image file originally read-only or because the loop-device was read-only). I am liking this solution so far... the whole use of kernel mounting in order to virtualize a symlink is elegant, IMHO. I'd rather use images than partitions, and so the only remaining problems that I can see to this approach is to work out the loop device locking. Incidently, this was my approach 1. Create an image file: dd if=/dev/zero of=/etc/native-environ-image.ext2 bs=1024 count=256 2. Make a file system in the images: mke2fs /etc/native-environ-image.ext2 (I had it continue despite the "not a block device" warning) 3. Since there isn't anything in image yet, I made a copy called /etc/colinux-environ-image.ext2 4. Made a new directory: mkdir /bootenviron 5. I mounted them, one at a time: mount /etc/native-environ-image.ext2 /bootenviron -t ext2 -o loop=/dev/loop0 6. I copied over those files that I wanted separate versions for. 7. I modified those files in the /bootenviron version. 8. I unmounted the image 9. I repeated steps 5-8 for the other image (/etc/colinux-environ-image.ext2). I had to use another loop device, though (I just used /dev/loop1). 10. I made sure the the native image was mounted (used /dev/loop2 this time). 11. I removed the files from /etc and created symlinks for them onto the other versions in /bootenviron 12. I wrote up a pre-init script and put it into /sbin 13. I rebooted a bunch and tested a bunch.(always setting init=/sbin/pre-init) 14. I booted into Windows and then started up colinux a number of times and tested there as well (again, always setting init=/sbin/pre-init). By the way, I have attached my /sbin/pre-init script for anytone that wants to peruse it, or just try this method. Any thoughts? |