Can I install Slackware onto a drive then transfer that drive into another
system if I run through the normal setup like a new install. I'm thinking
it should work, just select the other drive as the install target and it
shouldn't touch the slack install already on the first drive right?

On Sun, 24 Sep 2006 19:21:51 -0400, Eugene Nine <no@spam.com> wrote:

>Can I install Slackware onto a drive then transfer that drive into another
>system if I run through the normal setup like a new install.

Yes, should be no problems.

Grant.

--
http://bugsplatter.mine.nu/

On 2006-09-24, Eugene Nine <no@spam.com> wrote:
> Can I install Slackware onto a drive then transfer that drive into another
> system if I run through the normal setup like a new install. I'm thinking
> it should work, just select the other drive as the install target and it
> shouldn't touch the slack install already on the first drive right?
>


installpkg(8):

-root /otherroot
Install using a location other than / (the default) as the root of
the filesystem to install on. In the example given, use /otherroot
instead. Setting the ROOT environment variable does the same thing.

In other words, yes. It should work fine. In fact, this is a handy way
to set up a "clean" build environment on your system that you can then
chroot into...

RW

--

http://rlworkman.net

Robby Workman :
> On 2006-09-24, Eugene Nine <no@spam.com> wrote:
>> Can I install Slackware onto a drive then transfer that drive into another
>> system if I run through the normal setup like a new install. I'm thinking
>> it should work, just select the other drive as the install target and it
>> shouldn't touch the slack install already on the first drive right?
>>
>
>
> installpkg(8):
>
> -root /otherroot
> Install using a location other than / (the default) as the root of
> the filesystem to install on. In the example given, use /otherroot
> instead. Setting the ROOT environment variable does the same thing.
>
> In other words, yes. It should work fine. In fact, this is a handy way
> to set up a "clean" build environment on your system that you can then
> chroot into...

Just a thought, would this work over NFS? Samba?

--
SEIZE LIBERTY

http://www.websterscafe.com

Handover Phist wrote:

>> installpkg(8):
>> -root /otherroot
>> ...
>
> Just a thought, would this work over NFS? Samba?

I don't see why not ...

--
----------------------------------------------------------------------
Sylvain Robitaille syl@alcor.concordia.ca

Systems and Network analyst Concordia University
Instructional & Information Technology Montreal, Quebec, Canada
----------------------------------------------------------------------

On 2006-09-25, Handover Phist <jason@jason.websterscafe.com> wrote:
> Robby Workman :
>>
>> installpkg(8):
>>
>> -root /otherroot
>> Install using a location other than / (the default) as the root of
>> the filesystem to install on. In the example given, use /otherroot
>> instead. Setting the ROOT environment variable does the same thing.
>>
>> In other words, yes. It should work fine. In fact, this is a handy way
>> to set up a "clean" build environment on your system that you can then
>> chroot into...
>
> Just a thought, would this work over NFS? Samba?


Depending on what you mean by that, yes, it will. So far as the OS is
concerned, a mountpoint is a mountpoint in this context. For example, if
/mnt/nfs is an NFS share mounted from another box, and you have proper
write permissions as root, then:
installpkg -root /mnt/nfs $PKG_REPO/*/*.tgz
should work just fine.

RW

--

http://rlworkman.net

Handover Phist <jason@jason.websterscafe.com> wrote:
>> installpkg(8):
>>
>> -root /otherroot
>> Install using a location other than /

> Just a thought, would this work over NFS? Samba?

I can see no problem with NFS if root has enough permissions, but a Samba
share might not be aware of unix permissions and different unix users.
With smbfs you have an option (username) to connect as a single user only.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc8(at)uthyres.com Examples of addresses which go to spammers:
root@variousus.net root@localhost

On Mon, 25 Sep 2006, Robby Workman wrote:

> On 2006-09-24, Eugene Nine <no@spam.com> wrote:
>> Can I install Slackware onto a drive then transfer that drive into another
>> system if I run through the normal setup like a new install. I'm thinking
>> it should work, just select the other drive as the install target and it
>> shouldn't touch the slack install already on the first drive right?
>>
>
> installpkg(8):
>
> -root /otherroot
> Install using a location other than / (the default) as the root of
> the filesystem to install on. In the example given, use /otherroot
> instead. Setting the ROOT environment variable does the same thing.
>
> In other words, yes. It should work fine. In fact, this is a handy way
> to set up a "clean" build environment on your system that you can then
> chroot into...
>
> RW

ummmmmmmmm, as i read the question, Eugene Nine wants to run
setup, not installpkg. eg., given a working slackbox with hda,
add fresh disk as hdb, boot to installer (cdrom), setup to hdb,
remove disk hdb, transport disk to some other box, add disk as
hda, boot and run slackware.

if so, answer is still yes, except that /etc/fstab would need to
be edited, s/hdb/hda. links for /dev/cdrom and /dev/modem might
also need tweaking, no bfd.


--
William Hunt, Portland Oregon USA

William Hunt wrote:

> On Mon, 25 Sep 2006, Robby Workman wrote:
>
>> On 2006-09-24, Eugene Nine <no@spam.com> wrote:
>>> Can I install Slackware onto a drive then transfer that drive into
>>> another
>>> system if I run through the normal setup like a new install. I'm
>>> thinking it should work, just select the other drive as the install
>>> target and it shouldn't touch the slack install already on the first
>>> drive right?
>>>
>>
>> installpkg(8):
>>
>> -root /otherroot
>> Install using a location other than / (the default) as the root of
>> the filesystem to install on. In the example given, use /otherroot
>> instead. Setting the ROOT environment variable does the same thing.
>>
>> In other words, yes. It should work fine. In fact, this is a handy way
>> to set up a "clean" build environment on your system that you can then
>> chroot into...
>>
>> RW
>
> ummmmmmmmm, as i read the question, Eugene Nine wants to run
> setup, not installpkg. eg., given a working slackbox with hda,
> add fresh disk as hdb, boot to installer (cdrom), setup to hdb,
> remove disk hdb, transport disk to some other box, add disk as
> hda, boot and run slackware.
>
> if so, answer is still yes, except that /etc/fstab would need to
> be edited, s/hdb/hda. links for /dev/cdrom and /dev/modem might
> also need tweaking, no bfd.
>
>
Would I even need to boot from the CD, can I just mount the CD and run setup
selecting the target of /dev/sda1 (drive in an USB enclosure) and have
setup install lilo and everything.

On Mon, 25 Sep 2006, Eugene Nine wrote:
> William Hunt wrote:
>> On Mon, 25 Sep 2006, Robby Workman wrote:
>>> On 2006-09-24, Eugene Nine <no@spam.com> wrote:
>>>> Can I install Slackware onto a drive then transfer that drive into
>>>> another
>>>> system if I run through the normal setup like a new install. I'm
>>>> thinking it should work, just select the other drive as the install
>>>> target and it shouldn't touch the slack install already on the first
>>>> drive right?
>>>
>>> installpkg(8):
[...]
>> ummmmmmmmm, as i read the question, Eugene Nine wants to run
>> setup, not installpkg. eg., given a working slackbox with hda,
>> add fresh disk as hdb, boot to installer (cdrom), setup to hdb,
>> remove disk hdb, transport disk to some other box, add disk as
>> hda, boot and run slackware.
>>
>> if so, answer is still yes, except that /etc/fstab would need to
>> be edited, s/hdb/hda. links for /dev/cdrom and /dev/modem might
>> also need tweaking, no bfd.
>>
> Would I even need to boot from the CD, can I just mount the CD and run setup
> selecting the target of /dev/sda1 (drive in an USB enclosure) and have
> setup install lilo and everything.

hmmmm. to be safe, boot from cd. Is there any good reason not to?
There is probably a simple method, to do it from a running system as
you ask, but i've never tried to do that ...

Note that the fstab edit mentioned above must be done -before- you
boot off the USB drive, and -must- match whatver whatever dev the USB
drive ends up as. I -think- this can be simplified using volume labels,
idunno, never tried - look for an excellant write-up on volume labels
in fstab posted here a few weeks back ...


--
William Hunt, Portland Oregon USA