Besides the obvious, a need for the kernel built for that distro, is there any other decent reason to reboot to switch distros on the same box?

Ok, I run basically the same kernel in all my distros, with the exception of the kernel in Mandy which is the default kernel.

So with the exception of Mandy...

Will I run into a lot of problems if I just chroot into my other distro's (Slack and LFS) root environment and run things from there as if I had booted into it? I really can't think of any, but am not sure if I'd be missing services, or if it'd run into problems when probing modules or what...

Thanks for any ideas, thoughts or slams

Cool

You're talking about leaving one root and using another, including loading a new kernel?

I suppose that you could leave the remnants of the old kernel in memory, but how are you going to trigger the loading of the new kernel (and init)?


Or do I have this all wrong?


John

No, I am not nearly that good. I will be lucky to chroot

No, no kernel switching, and that's why I am wondering if I will have problems chrooting, even though the kernel that is loaded from the intitial root env, is basically identical to the new chrooted env.



Cool

And here I was impressed as all get out. No earthly idea as to why you would do this, but impressed as hell


Sounds like a great way of breaking things, but you could always reboot

But if your kernels are the same, then I would think that it would be fairly transparent. It should work...

Why would you want to do this?


John

More than the same kernel, the way they are config'd is more important, iianm.

May sound like "a great way of breaking things" but it's been a great way of fixing things for me.

I can't say I tried a whole lot of different things in chroot mode but I've compiled a few things, including kernels, and have no problems chrooting to different kernel version, including 2.5.xx.

If the kernel works, once loaded, it'll run whatever / you assign it, provided it could run it in native mode.
i.e. don't chroot into a xfs if the kernel doesn't support it or that kinda thing ...but you probably figured that much already.

Cool, thanks guys.

Pretty stupid really, but here's why:

I wish I had a better reason, and might someday, but for now... I ssh into my box from work. Sometimes I want to work in my other distro as I have other things setup on it for different use, such as multimedia editing, Office file manipulation, CD ripping, etc. So to work in 1 distro or the other, from work, instead of rebooting, I was hoping to just be able to chroot into the other distro's / directory and basically "reboot" without rebooting. So yeah, the kernels are very close to the same, with small differences that I think won't matter to me in my ssh'd chrooted env.

I will be giving it a go later on tonight and post back with the success rate.

Thanks again both you!

Cool

Sounds like fun, keep me posted


John

It worked wonderfully. Not even a complaint that "couldn't stat blah blah from /lib/modules/" or anything.

Thanks!

Cool

Neat, I'm going to have to play with that.

And I especially like the "I ssh into my box from work" part.

Quake via telnet?


John

ha ha ha ha,

I am still trying to figure out how to "startx" and have it popup on my desktop here at work, yet be from my box at home so I can work as if I were home.

Doing all this from cygwin on win2k, so it's not too easy. I do have wmaker installed though, and that's pretty cool cause I can feel like I am on linux

Cool

In fact, I'll post this here, and then head over to the screenshot thread and post it there, it's win2k running cygwin, running wmaker:
ftp://masterc.no-ip.org/pics/screenshots/cygwmaker.jpg



Cool

I've done it with my old Agenda PDA, which was cool. I don't know about doing it with cygwin though...


John

xhost +
vi /etc/ssh/ssh_config

Host *
ForwardX11 yes
:wq

Remove any iptables rule blocking X.

ssh mybox
startx &

wait... wait... wait...


note: This is *way* insecure. Read up on xhost and set it for your work machine('s gateway). Leaving it in the condition I've described above will open you up to any vunerabilities in X, in addition to letting people suck your bandwidth by loading up the X logon and attempting brute attacks on it.

[edit]
Running X over a Wide area network (the internet) is a desperately bad thing to do... X is a 'chatty' protocol and will do things like send the position of your remote desktop's mouse cursor to your home machine, even if the mouse hasn't moved. It's slow... *very* slow. Nasty nasty protocol.. great for local machines, horrible for remote machines.

Consider running vncserver instead :P
[/edit]

Slick.

Thanks Slick I've ran vncserver before, the problem I ran into was it opens up twm instead of *my* desktop. I was cool with the speed, not horribly bad (although it was definitely not even close to the speed of localhost), but just not the desktop I wish to be using.

I think I'll just stick with ssh'ing for now, the main thing I was thinking about using remote X for was to watch a movie or something from home, but that wouldn't work (too slow). The 2k at work doesn't allow installation of anything, so alot of videos won't play because they cannot download/install codecs. The rest of what I do via ssh from my work is done in the command line anyway.

Thanks again for that up there, it's just another thing to impress the winLusers at work with

Cool

SSH allows a secure tunnel of the X protocol via the SSL. This
makes running X across the network no less secure than running
ssh. If your client and server are set up correctly, you don't have
to use xhost at all.
I can ssh in to work, type "xv &" as my first command and have
xv pop up on my home machine. No problems, not insecure (well,
compared with ssh anyway).

(I suppose I should also point out the lines necessary in your
client/server setup for a unix machine. . .)

for client:
/etc/ssh(2)/ssh_config:
(man ssh_config)

for server:
/etc/ssh(2)/sshd_config
N.B. The "X11DisplayOffset 10" changes your DISPLAY
variable to be offset (duh) from the default by 10 (in this case).
This prevents interference with real X servers. . .
(man sshd_config)