Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #56825 > unrolled thread

Relocating many homes in subfolders of a dedicated internal HDD

Back to article view | Back to alt.os.linux

Contents

  Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-13 20:47 +0200
    Re: Relocating many homes in subfolders of a dedicated internal HDD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-13 17:35 -0400
      Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-14 00:01 +0200
        Re: Relocating many homes in subfolders of a dedicated internal HDD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-13 19:28 -0400
          Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-13 19:23 -0500
        Re: Relocating many homes in subfolders of a dedicated internal HDD "Carlos E.R." <robin_listas@es.invalid> - 2019-06-14 10:29 +0200
      Re: Relocating many homes in subfolders of a dedicated internal HDD marrgol <marrgol@address.invalid> - 2019-06-14 02:13 +0200
        Re: Relocating many homes in subfolders of a dedicated internal HDD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-13 23:45 -0400
          Re: Relocating many homes in subfolders of a dedicated internal HDD Paul <nospam@needed.invalid> - 2019-06-14 07:34 -0400
            Re: Relocating many homes in subfolders of a dedicated internal HDD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-14 09:59 -0400
              Re: Relocating many homes in subfolders of a dedicated internal HDD "Carlos E.R." <robin_listas@es.invalid> - 2019-06-15 13:08 +0200
                Re: Relocating many homes in subfolders of a dedicated internal HDD Paul <nospam@needed.invalid> - 2019-06-15 11:58 -0400
                  Re: Relocating many homes in subfolders of a dedicated internal HDD "Carlos E.R." <robin_listas@es.invalid> - 2019-06-15 23:10 +0200
    Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-13 18:49 -0500
    Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 07:05 +0200
      Re: Relocating many homes in subfolders of a dedicated internal HDD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2019-06-14 04:17 -0400
        Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-14 17:41 +0200
          Re: Relocating many homes in subfolders of a dedicated internal HDD William Unruh <unruh@invalid.ca> - 2019-06-14 15:58 +0000
          Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 18:04 +0200
        Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 17:58 +0200
          Re: Relocating many homes in subfolders of a dedicated internal HDD Aragorn <thorongil@telenet.be> - 2019-06-14 18:36 +0200
            Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-14 12:01 -0500
            Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 19:18 +0200
              Re: Relocating many homes in subfolders of a dedicated internal HDD Aragorn <thorongil@telenet.be> - 2019-06-14 20:11 +0200
                Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 21:44 +0200
                Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-18 12:50 +0200
                  Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-18 21:50 +0200
                    Re: Relocating many homes in subfolders of a dedicated internal HDD Aragorn <thorongil@telenet.be> - 2019-06-19 13:10 +0200
                      Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-19 21:57 +0200
            Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-14 19:22 +0200
              Re: Relocating many homes in subfolders of a dedicated internal HDD Aragorn <thorongil@telenet.be> - 2019-06-14 20:02 +0200
      Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-14 17:36 +0200
        Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-14 10:50 -0500
        Re: Relocating many homes in subfolders of a dedicated internal HDD William Unruh <unruh@invalid.ca> - 2019-06-14 15:55 +0000
          Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-14 22:29 +0200
            Re: Relocating many homes in subfolders of a dedicated internal HDD William Unruh <unruh@invalid.ca> - 2019-06-14 20:52 +0000
              Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-15 02:07 +0200
                Re: Relocating many homes in subfolders of a dedicated internal HDD William Unruh <unruh@invalid.ca> - 2019-06-15 01:30 +0000
            Re: Relocating many homes in subfolders of a dedicated internal HDD Aragorn <thorongil@telenet.be> - 2019-06-15 08:59 +0200
              Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-17 19:43 +0200
    Re: Relocating many homes in subfolders of a dedicated internal HDD Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-15 19:47 +0200
      Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-17 02:05 +0200
        Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-16 20:23 -0500
        Re: Relocating many homes in subfolders of a dedicated internal HDD Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-18 13:52 +0200
          Re: Relocating many homes in subfolders of a dedicated internal HDD Soviet_Mario <SovietMario@CCCP.MIR> - 2019-06-18 18:36 +0200
            Re: Relocating many homes in subfolders of a dedicated internal HDD Bit Twister <BitTwister@mouse-potato.com> - 2019-06-18 12:04 -0500
            Re: Relocating many homes in subfolders of a dedicated internal HDD William Unruh <unruh@invalid.ca> - 2019-06-18 21:37 +0000
            Re: Relocating many homes in subfolders of a dedicated internal HDD Pascal Hambourg <pascal@plouf.fr.eu.org> - 2019-06-20 23:31 +0200
              Re: Relocating many homes in subfolders of a dedicated internal HDD "J.O. Aho" <user@example.net> - 2019-06-21 10:25 +0200

Page 1 of 3  [1] 2 3  Next page →

#56825 — Relocating many homes in subfolders of a dedicated internal HDD

Now I have some days off and I can retry an experiment that 
1 yr ago failed due to my unfamiliarity with grub feature 
and multi boot.

scenario : install 2 more OS to test on dedicated separate 
disks (each in just one boot+root partition and one for 
swap_#1).
I need to get a private copy of grub installed on its MBR, 
not interfering with other distros' copies elsewhere.
Is it necessary to phisically disconnect their hd drives ? 
Or else is the installer smart enough not to affect them ?

I'd want to leverage to f12 bios option (boot device manual 
selection) to make a choice.
Each OS should not even know of others' existence, 
preferably. Well not literally, the drive should be visible, 
I'm speaking just of boot process and periodical grub update 
which should only affect private copy


Meanwhile, as I have a big NEW and certified hdd (non ssd, a 
WD-red 2 TB), I'd also be willing to move the actual data of 
every HOME of any  distro, each in a separate subtree of 
"\homes" shared folder. I say shared as the device has to be 
mounted, but each distro will write in its own branch by 
default, letting me decide if not.

So this I think is not a home sharing, just DATA sharing : 
just home relocation in a shared drive.

I have thought of SYMLINKING.

So the question : is it there a question to associate every 
home/user of one distro with the specific corresponding 
subfolder on another drive ?

Is it possible ? safe ? What risks I should be aware of 
before trying ?

The disk is internal, and new, so mount errors are not a 
problem : I just need to make sure the device IS JUST 
MOUNTED, automatically, and with adequate privileges, before 
the SYMLINK is ever accessed (so maybe before /home is 
mounted itself)

Tnx for any response / suggestions

N.B. I dont want to share settings and config files, to the 
contrary I need to be sure no conflict can happen and every 
distribution (also on a per-user basis, even if I intend to 
have just one user each) has its private home, even if 
actual data is on another drive which is shared as a whole 
among distros (auto mounted in every one)



-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [next] | [standalone]

#56828

On Thu, 13 Jun 2019 14:47:42 -0400, Soviet_Mario <SovietMario@cccp.mir> wrote:

> Now I have some days off and I can retry an experiment that
> 1 yr ago failed due to my unfamiliarity with grub feature
> and multi boot.

It's easier to just snip the rest and post a summary rather then
reply to each part in line as I usually do.

First, do not share /home between installs. As different installs
will likely have different versions of programs installed, the files
in .config and similar sub directories within /home from one version
will not work with another version.

I do share data. I have a large partition on a 1TB spinning rust drive
for my data. In each installation, in the users home directory I delete
directories such as Documents and create a symlink to the Documents
directory in the large data partition for that user. As symlinks don't
care if the target exists (It's dangling if it doesn't exist), the
mount order doesn't matter, as long as both are mounted before anything
tries to access the Documents directory in that users home directory.
The various installs I have are on ssd drives.

Caveats do apply. Keep the user and the uid the same on all installs.
The user will be used within things like config files, and the uid will
be used for file ownership.

Keeping multiple installs separate used to be relatively easy by installing
grub-legacy to the partition containing the install, and using a boot
manager such as gag in the mbr of sda. grub-legacy is not supported any
more, and will not work with many newly formatted file systems due to
changes in inode sizes, etc.
http://gag.sourceforge.net/index.html

On drives that still use mbr style partition tables, grub2 can still be
used that way, but if the drive uses gpt partition tables grub2 requires
creating a bios boot partition that Grub will use to store its core image.
(type ef02, unformatted). Many distros no longer provide the option to
install grub2 to a partition to avoid confusion.

If the firmware for the computer is uefi (not running in bios compatibility
mode), then the uefi menu must be placed in a dedicated efi system
partition. Unfortunately that partition will be shared by all of the
installations, so beware.

So to keep multiple installs, ensure the system is either using bios
firmware, or for uefi firmware, that it is running in bios compatibility
mode, and that it is using mbr style partition tables, not gpt.
gpt partition tables are only needed for drives over 2TB, so stick to
drives that are 2TB or less. If you do have a larger drive, and use mbr
style partition tables, only 2TB will be usable.

When installing the distro, either select the partition to install
grub2 into (rather then a mbr), or skip that step and do it manually
after installation, which will likely require using chroot or
systemd-nspawn from a working installation, or from live iso.

Have fun keeping track of what's installed where when configuring gag.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#56830

Il 13/06/19 23:35, David W. Hodgins ha scritto:
> On Thu, 13 Jun 2019 14:47:42 -0400, Soviet_Mario 
> <SovietMario@cccp.mir> wrote:
> 
>> Now I have some days off and I can retry an experiment that
>> 1 yr ago failed due to my unfamiliarity with grub feature
>> and multi boot.
> 
> It's easier to just snip the rest and post a summary rather 
> then
> reply to each part in line as I usually do.

ok, as you prefer

> 
> First, do not share /home between installs. As different 
> installs

i underline I never wanted to share the /home-s but I have 
to share the partition in which they reside. I hope it's 
compliant with the rest ...

> will likely have different versions of programs installed, 
> the files
> in .config and similar sub directories within /home from one 
> version
> will not work with another version.

sure, ok with this point

> 
> I do share data. I have a large partition on a 1TB spinning 
> rust drive
> for my data. In each installation, in the users home 
> directory I delete
> directories such as Documents and create a symlink to the 
> Documents
> directory in the large data partition for that user. As 

but the config files and hidden files, stay in the same disk 
as the System and root, or is it possible to relocate in the 
same disk as Data, making the different just on a folder-basis ?

> symlinks don't
> care if the target exists (It's dangling if it doesn't 
> exist), the
> mount order doesn't matter, as long as both are mounted 
> before anything
> tries to access the Documents directory in that users home 
> directory.
> The various installs I have are on ssd drives.

okay

> 
> Caveats do apply. Keep the user and the uid the same on all 
> installs.

ah ! The username and usergroup you mean ? Pls confirm this 
.... It's annoying. I'd have preferred to be able to have 
different usernames.

> The user will be used within things like config files, and 
> the uid will
> be used for file ownership.
> 
> Keeping multiple installs separate used to be relatively 
> easy by installing
> grub-legacy to the partition containing the install, and 

perfect. I hope to be able to find proper options in the 
installers then

> using a boot
> manager such as gag in the mbr of sda. 

uhm ... sorry I miss this point, could you explain it 
differently ?

> grub-legacy is not 
> supported any
> more, and will not work with many newly formatted file 
> systems due to
> changes in inode sizes, etc.
> http://gag.sourceforge.net/index.html


I'll look for gag.
As for grub legacy, I have Boot Repair Disk : is it able to 
install such grub ? I can't recall its options

> 
> On drives that still use mbr style partition tables, grub2 
> can still be
> used that way, but if the drive uses gpt partition tables 
> grub2 requires
> creating a bios boot partition that Grub will use to store 
> its core image.
> (type ef02, unformatted). Many distros no longer provide the 
> option to
> install grub2 to a partition to avoid confusion.

Mmm, I'll use MBR then, it's more than enough as the drive 
has just two partitions, one for swap and one for all the 
remaining

> 
> If the firmware for the computer is uefi (not running in 
> bios compatibility
> mode), then the uefi menu must be placed in a dedicated efi 
> system

It has, but I had to disable it. I'm reluctant to revert, 
fearing Debian would not boot. I must keep at least one 
thing working :)

> partition. Unfortunately that partition will be shared by 
> all of the
> installations, so beware.
> 
> So to keep multiple installs, ensure the system is either 
> using bios
> firmware, or for uefi firmware, that it is running in bios 
> compatibility
> mode, and that it is using mbr style partition tables, not gpt.

OK ... and if. Say : the current Debian might be GPT or MBR, 
but any further distro would have a MBR disk. Would it work ?

> gpt partition tables are only needed for drives over 2TB, so 
> stick to
> drives that are 2TB or less.

the DATA partition to be shared alone is such size, the true 
OS partition will be in 1 TB or 0,5 TB drives. All of them

>  If you do have a larger drive, 
> and use mbr
> style partition tables, only 2TB will be usable.
> 
> When installing the distro, either select the partition to 
> install
> grub2 into (rather then a mbr), or skip that step and do it 
> manually
> after installation, which will likely require using chroot or
> systemd-nspawn from a working installation, or from live iso.

mmmm, here the things are getting too tough for me I'm 
afraid. I can just rely on boot repair, but it uses OsProber 
which maybe scans every thing at the same time and make one 
single grub install with many boot options : the one thing 
just deluded me in the past, as in every grub update 
somewhere, the other distro become non bootable.
I don't know whether or not Boot Repair is able to 
selectively install a 1:1 matching grub version seeing just 
the OS I need at the given time

> 
> Have fun keeping track of what's installed where when 
> configuring gag.

I'm gonna make some research about gag. Never heard of :\

> 
> Regards, Dave Hodgins

I'll re-read your post later ... There are things I was not 
able to understand alas

> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#56831

On Thu, 13 Jun 2019 18:01:01 -0400, Soviet_Mario <SovietMario@cccp.mir> wrote:

> Il 13/06/19 23:35, David W. Hodgins ha scritto:
> i underline I never wanted to share the /home-s but I have
> to share the partition in which they reside. I hope it's
> compliant with the rest ...

I don't think it is. The directory name /home is hard coded in many
places, so each install's /home directory must be in different partitions.
I no longer put /home in it's own partition, but keep it in the same
partition as the / directory.

>> I do share data. I have a large partition on a 1TB spinning
>> rust drive
>> for my data. In each installation, in the users home
>> directory I delete
>> directories such as Documents and create a symlink to the
>> Documents
>> directory in the large data partition for that user. As
>
> but the config files and hidden files, stay in the same disk
> as the System and root, or is it possible to relocate in the
> same disk as Data, making the different just on a folder-basis ?

Keep them in different partitions, as above.

>> symlinks don't
>> care if the target exists (It's dangling if it doesn't
>> exist), the
>> mount order doesn't matter, as long as both are mounted
>> before anything
>> tries to access the Documents directory in that users home
>> directory.
>> The various installs I have are on ssd drives.
>
> okay
>
>>
>> Caveats do apply. Keep the user and the uid the same on all
>> installs.
>
> ah ! The username and usergroup you mean ? Pls confirm this
> .... It's annoying. I'd have preferred to be able to have
> different usernames.

Depending on the usage, the usernames may be different, but I advise
against it as it too is used in config files used by some programs.

>> The user will be used within things like config files, and
>> the uid will
>> be used for file ownership.
>>
>> Keeping multiple installs separate used to be relatively
>> easy by installing
>> grub-legacy to the partition containing the install, and
>
> perfect. I hope to be able to find proper options in the
> installers then
>
>> using a boot
>> manager such as gag in the mbr of sda.
>
> uhm ... sorry I miss this point, could you explain it
> differently ?

With grub-legacy, I'd install it's boot menu to the boot record of the
partition containing the / directory for that install. The gag boot loader
in the mbr of sda would allow me to select (once I'd configured it) which
partition to load the grub menu from.

On a disk using mbr style partition tables the first track of the disk
is reserved, with the first sector used for the bootstrap code, and the
main partition table with room for 4 primary partitions to be defined.

The first track of every partition is reserved, and also contains a 4 entry
partition table. Normally, the rest of the track is wasted space. That's
the space where grub2 can be installed.

For primary partitions other then the extended partition, the partition
table in it's first track is not used. The extended partition is one large
partition defined in the primary partition table. It's first track contains a partition table that defines the first logical partition, and as it's second partition table, the location of a track that contains a partition table for the next logical partition. It's by chaining together all of
the partition tables that the bios builds it's full partition table.

>> grub-legacy is not
>> supported any
>> more, and will not work with many newly formatted file
>> systems due to
>> changes in inode sizes, etc.
>> http://gag.sourceforge.net/index.html

> I'll look for gag.
> As for grub legacy, I have Boot Repair Disk : is it able to
> install such grub ? I can't recall its options

Depends on the version of the boot repair disk as to whether it works
with grub legacy, or grub2. Don't use grub legacy for any distros less
than a few years old. The ext4 default inode size changed, and grub legacy
will not work with it. I don't remember which error is shown, but trying
to boot grub legacy installed on a newly formatted partition will drop
to a grub error prompt, with no recovery that works other then overwriting
it with grub2.

>> On drives that still use mbr style partition tables, grub2
>> can still be
>> used that way, but if the drive uses gpt partition tables
>> grub2 requires
>> creating a bios boot partition that Grub will use to store
>> its core image.
>> (type ef02, unformatted). Many distros no longer provide the
>> option to
>> install grub2 to a partition to avoid confusion.

> Mmm, I'll use MBR then, it's more than enough as the drive
> has just two partitions, one for swap and one for all the
> remaining

If you're planning on putting multiple installs on that drive, I'd create
a partition for each install with the rest used for a swap and the data
partitions. Note. If you share swap, and you use hibernate to disk, you
must make sure that on the next boot you select the same partition to
boot from. Booting a different install with another installs hibernated
image in the swap will cause problems. :-)

Before I added several ssd drives, I had 6 installs on my 1TB drive with
32GB per install, 32GB for my swap (I have 16GB ram), and the rest for
the data partition. I now use the ssd drives for most things (the difference
in speed is incredible), and only use the spinning rust drive for bulky
things like videos, iso images, etc.

>> If the firmware for the computer is uefi (not running in
>> bios compatibility
>> mode), then the uefi menu must be placed in a dedicated efi
>> system

> It has, but I had to disable it. I'm reluctant to revert,
> fearing Debian would not boot. I must keep at least one
> thing working :)

I'm not clear from the above. Is the system booting in uefi mode or in
bios compatibility mode?

>> partition. Unfortunately that partition will be shared by
>> all of the
>> installations, so beware.
>>
>> So to keep multiple installs, ensure the system is either
>> using bios
>> firmware, or for uefi firmware, that it is running in bios
>> compatibility
>> mode, and that it is using mbr style partition tables, not gpt.
>
> OK ... and if. Say : the current Debian might be GPT or MBR,
> but any further distro would have a MBR disk. Would it work ?

The partition table of a drive either uses gpt or mbr style partition
tables. Changing from one to the other normally means wiping the entire
drive. Note, gpt partition tables include a fake mbr partition table
so that older software will not assume the drive is blank.

>> gpt partition tables are only needed for drives over 2TB, so
>> stick to
>> drives that are 2TB or less.
>
> the DATA partition to be shared alone is such size, the true
> OS partition will be in 1 TB or 0,5 TB drives. All of them
>
>>  If you do have a larger drive,
>> and use mbr
>> style partition tables, only 2TB will be usable.
>>
>> When installing the distro, either select the partition to
>> install
>> grub2 into (rather then a mbr), or skip that step and do it
>> manually
>> after installation, which will likely require using chroot or
>> systemd-nspawn from a working installation, or from live iso.
>
> mmmm, here the things are getting too tough for me I'm
> afraid. I can just rely on boot repair, but it uses OsProber
> which maybe scans every thing at the same time and make one
> single grub install with many boot options : the one thing
> just deluded me in the past, as in every grub update
> somewhere, the other distro become non bootable.
> I don't know whether or not Boot Repair is able to
> selectively install a 1:1 matching grub version seeing just
> the OS I need at the given time

I disable or remove os-prober. I don't want dozens of kernels all
mixed in each grub menu in a way that makes it very difficult to
figure out which entry is for which install. In my case, I have
both i586 and x86_64 installs of the same distro/release, so the
menu generated by os-prober is just not usable.

I'm the leader of the qa team for Mageia linux, hence the need for
multiple installs of multiple releases.

>> Have fun keeping track of what's installed where when
>> configuring gag.
> I'm gonna make some research about gag. Never heard of :\

There are other boot managers available. That's the only I've I've tried.

Make sure you have a very clear understanding of how partition tables,
boot records, etc., before you embark on a multi install system. Messing
up something in the partition tables can really make for a bad day. :-)
In the past, I've used used a live iso with dd and a hex editor to fix
accidentally broken partition chains. Really not fun, but you never forget
it. I haven't tried anything similar with a gpt formatted drive.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#56834

On Thu, 13 Jun 2019 19:28:51 -0400, David W. Hodgins wrote:
> On Thu, 13 Jun 2019 18:01:01 -0400, Soviet_Mario <SovietMario@cccp.mir> wrote:
>
>> Il 13/06/19 23:35, David W. Hodgins ha scritto:
>> i underline I never wanted to share the /home-s but I have
>> to share the partition in which they reside. I hope it's
>> compliant with the rest ...
>
> I don't think it is. The directory name /home is hard coded in many
> places, so each install's /home directory must be in different partitions.

Yep. Soviet_Mario is going to have something like an os partition with
something like /os/ubuntu23, /os/debianxx, /os/susexx

Then during suse custom install, pick /os/susexx and set mount point as /home.

>
> With grub-legacy, I'd install it's boot menu to the boot record of the
> partition containing the / directory for that install. The gag boot loader
> in the mbr of sda would allow me to select (once I'd configured it) which
> partition to load the grub menu from.

grub-legacy is no longer supported. If Soviet_Mario is using it, he
should set GPT on the new drive, create/format needed partitions and
rsync current install onto new drive. Then do same for old drive,
rsync everything back, and install grub2 as boot loader.

> I disable or remove os-prober. I don't want dozens of kernels all
> mixed in each grub menu in a way that makes it very difficult to
> figure out which entry is for which install. In my case, I have
> both i586 and x86_64 installs of the same distro/release, so the
> menu generated by os-prober is just not usable.

Absolutely true. Best solution there is write your own grub script
to make a menu you like. I wrote my own to use labels as menu
selections and let os-prober add its stuff later in the menu.

[toc] | [prev] | [next] | [standalone]

#56840

On 14/06/2019 00.01, Soviet_Mario wrote:
> Il 13/06/19 23:35, David W. Hodgins ha scritto:


>> Caveats do apply. Keep the user and the uid the same on all installs.
> 
> ah ! The username and usergroup you mean ? Pls confirm this .... It's
> annoying. I'd have preferred to be able to have different usernames.

The name doesn't matter. The UID *number* must be the same.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#56833

On 2019-06-13 at 23:35, David W. Hodgins wrote:
> If you do have a larger drive, and use mbr
> style partition tables, only 2TB will be usable.

Not quite true and it would be a waste.  You can set up a loop device
with an offset to access the part above 2TB.  You can treat it as
another “disk” and partition it MBR-style too.


-- 
mrg

[toc] | [prev] | [next] | [standalone]

#56838

On Thu, 13 Jun 2019 20:13:13 -0400, marrgol <marrgol@address.invalid> wrote:

> On 2019-06-13 at 23:35, David W. Hodgins wrote:
>> If you do have a larger drive, and use mbr
>> style partition tables, only 2TB will be usable.

> Not quite true and it would be a waste.  You can set up a loop device
> with an offset to access the part above 2TB.  You can treat it as
> another “disk” and partition it MBR-style too.

Interesting idea. Not one I'd heard of before. Thanks

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#56842

David W. Hodgins wrote:
> On Thu, 13 Jun 2019 20:13:13 -0400, marrgol <marrgol@address.invalid> 
> wrote:
> 
>> On 2019-06-13 at 23:35, David W. Hodgins wrote:
>>> If you do have a larger drive, and use mbr
>>> style partition tables, only 2TB will be usable.
> 
>> Not quite true and it would be a waste.  You can set up a loop device
>> with an offset to access the part above 2TB.  You can treat it as
>> another “disk” and partition it MBR-style too.
> 
> Interesting idea. Not one I'd heard of before. Thanks
> 
> Regards, Dave Hodgins
> 

That's how you can gain access to an NTFS partition
above 2TB created by Acronis Capacity Manager.

The only problem I found with the idea, is that the
mount only had a performance of 10MB/sec. It's a bit
slow for some reason. That's one of the reasons
I gave up on the idea as an interworking mechanism.

    Paul

[toc] | [prev] | [next] | [standalone]

#56843

On Fri, 14 Jun 2019 07:34:06 -0400, Paul <nospam@needed.invalid> wrote:

> David W. Hodgins wrote:
>> On Thu, 13 Jun 2019 20:13:13 -0400, marrgol <marrgol@address.invalid>
>> wrote:
>>> On 2019-06-13 at 23:35, David W. Hodgins wrote:
>>>> If you do have a larger drive, and use mbr
>>>> style partition tables, only 2TB will be usable.

>>> Not quite true and it would be a waste.  You can set up a loop device
>>> with an offset to access the part above 2TB.  You can treat it as
>>> another “disk” and partition it MBR-style too.

>> Interesting idea. Not one I'd heard of before. Thanks

> That's how you can gain access to an NTFS partition
> above 2TB created by Acronis Capacity Manager.
>
> The only problem I found with the idea, is that the
> mount only had a performance of 10MB/sec. It's a bit
> slow for some reason. That's one of the reasons
> I gave up on the idea as an interworking mechanism.

That would most likely come from failing to align on a 4KB boundary,
as most of the drives over 2TB use 4k physical sectors instead of 512
bytes. When a write doesn't align, the 4k write is translated by the
drives slow firmware into two physical reads, application of the changes,
and then two physical writes. Reading is not affected, but writing is
drastically slower. The worst I've seen are with the drives that have a
512 byte logical sector size, and a 4kb physical size. Those are also
the drives where this would be needed since the mbr will still be based
on 512 byte sectors instead of 4KB ones.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#56874

On 14/06/2019 15.59, David W. Hodgins wrote:
> On Fri, 14 Jun 2019 07:34:06 -0400, Paul <nospam@needed.invalid> wrote:


>> The only problem I found with the idea, is that the
>> mount only had a performance of 10MB/sec. It's a bit
>> slow for some reason. That's one of the reasons
>> I gave up on the idea as an interworking mechanism.
> 
> That would most likely come from failing to align on a 4KB boundary,
> as most of the drives over 2TB use 4k physical sectors instead of 512
> bytes. When a write doesn't align, the 4k write is translated by the
> drives slow firmware into two physical reads, application of the changes,
> and then two physical writes. Reading is not affected, but writing is
> drastically slower. The worst I've seen are with the drives that have a
> 512 byte logical sector size, and a 4kb physical size. Those are also
> the drives where this would be needed since the mbr will still be based
> on 512 byte sectors instead of 4KB ones.

All my disks are that way:

Telcontar:~ # lsblk --output NAME,PHY-SEC,LOG-SEC
NAME          PHY-SEC LOG-SEC

sda              4096     512

sdb              4096     512

sdc              4096     512

sdd              4096     512

and this one is ssd:

sde               512     512

Telcontar:~ #



-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#56887

Carlos E.R. wrote:
> On 14/06/2019 15.59, David W. Hodgins wrote:
>> On Fri, 14 Jun 2019 07:34:06 -0400, Paul <nospam@needed.invalid> wrote:
> 
> 
>>> The only problem I found with the idea, is that the
>>> mount only had a performance of 10MB/sec. It's a bit
>>> slow for some reason. That's one of the reasons
>>> I gave up on the idea as an interworking mechanism.
>> That would most likely come from failing to align on a 4KB boundary,
>> as most of the drives over 2TB use 4k physical sectors instead of 512
>> bytes. When a write doesn't align, the 4k write is translated by the
>> drives slow firmware into two physical reads, application of the changes,
>> and then two physical writes. Reading is not affected, but writing is
>> drastically slower. The worst I've seen are with the drives that have a
>> 512 byte logical sector size, and a 4kb physical size. Those are also
>> the drives where this would be needed since the mbr will still be based
>> on 512 byte sectors instead of 4KB ones.
> 
> All my disks are that way:
> 
> Telcontar:~ # lsblk --output NAME,PHY-SEC,LOG-SEC
> NAME          PHY-SEC LOG-SEC
> 
> sda              4096     512
> 
> sdb              4096     512
> 
> sdc              4096     512
> 
> sdd              4096     512
> 
> and this one is ssd:
> 
> sde               512     512
> 
> Telcontar:~ #

I have quite a few hard drives that are 512 512.

Because I specifically search for those when
buying disk drives.

At one time, I think WDC Black fit that description.
Then it shifted to WDC RE drives. The last drive
I bought with that characteristic, was WDC 4TB Gold.
The larger drives, like WDC 6TB Gold, would be
4096 512. The 1/2/4TB Gold are probably 512 512.

You could say my collection of drives then, bucks
the trend. I do have a number of drives that are
512e (a bunch of 500GB Seagate scratch drives), but a lot
of the others are good ones. And the experiment using
a >2TB offset loopback mount, would have been on a
3TB or 4TB drive.

Besides, a sequential access rate of 10MB/sec is way
too low, to blame on alignment.

At the time I did that experiment, I was at a loss to
come up with a plausible explanation. It didn't make
a lot of sense. When Acronis Capacity Manager was
running the show, the "high" partition had normal
speed (maybe 100MB/sec because it's closer to the
hub). The WDC drives aren't always speed champs,
and usually trail Seagate on sequential speed.

    Paul

[toc] | [prev] | [next] | [standalone]

#56894

On 15/06/2019 17.58, Paul wrote:
> At the time I did that experiment, I was at a loss to
> come up with a plausible explanation. It didn't make
> a lot of sense. When Acronis Capacity Manager was
> running the show, the "high" partition had normal
> speed (maybe 100MB/sec because it's closer to the
> hub). The WDC drives aren't always speed champs,
> and usually trail Seagate on sequential speed.

Once I did an experiment to find out the area where a disk was faster,
and it was about 1/3 of the way. Not the rim, nor the hub (noticeably
so). Possibly because of the sector size adjustment with the radius
offsetting the surface speed difference.

On a new disk I created many partitions of the same size, and then did
hdparm -tT on them, and tabulated the result. Another experiment is to
create a filesystem on each of them, and time small/medium/big file
write. With different filesystem types.

Another experiment would be to try different models. I use Seagates.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#56832

On Thu, 13 Jun 2019 20:47:42 +0200, Soviet_Mario wrote:
> Now I have some days off and I can retry an experiment that
> 1 yr ago failed due to my unfamiliarity with grub feature
> and multi boot.
>
> scenario : install 2 more OS to test on dedicated separate
> disks (each in just one boot+root partition and one for
> swap_#1).

It is possible to have separate OS on each drive and/or on same
drive, each in separate partitions.

> I need to get a private copy of grub installed on its MBR,
> not interfering with other distros' copies elsewhere.

Why make it complex. You need one boot loader, let's call it production.
That is the one which is used when you power up the system.

You decide, to install another Linux OS. You make the same kind of install
as the production boot loader install. That wipes production and installs
new OS grub2 but it adds production OS selection. You pick it, have
grub scan all drives/partitions, to build new grub.cfg. You then run
the grub install command which replaces new OS with production grub boot.


> Is it necessary to phisically disconnect their hd drives ?
> Or else is the installer smart enough not to affect them ?

Only if installer has a custom install partition mode.
That is where you indicate where you want / and any other partitions
mounted.

> I'd want to leverage to f12 bios option (boot device manual
> selection) to make a choice.

I can not help there. I like the KISS principle. All drives have
GPT partition tables, formatted ext4. Each install gets about 40 gig /
each with /home in /. All data sharing is in separate partitions.

In your suggested setup/requirement, you have limited your system to
just two installs.  :(



> Each OS should not even know of others' existence,
> preferably. Well not literally, the drive should be visible,

That is a simple /etc/fstab entry in each OS /etc/fstab.


> I'm speaking just of boot process and periodical grub update
> which should only affect private copy

In my setup, last install/grub update can overwrite /dev/sda. Not a
problem for me. I boot the production OS, run grub to re-install
it as the master "production" boot loader.

> Meanwhile, as I have a big NEW and certified hdd (non ssd, a
> WD-red 2 TB), I'd also be willing to move the actual data of
> every HOME of any  distro, each in a separate subtree of
> "\homes" shared folder.

Go ahead, but seems overly complex to me. Each OS / can be the needed
size plus room for large update download, say 20 gig, and 20 gig for
/home users. Any data sharing for each user is in another partition.

In my setup that is /accounts for
    $ ls -al /accounts | wc -l
    29
users, yet I am the only biological unit between the keyboard and chair.

Some linked file examples with a little re-formatting of ls -al
lrwxrwxrwx  1 bittwister bittwister     34 May 26 11:21
 .bash_history -> /accounts/bittwister/.bash_history
 .bash_logout -> /accounts/bittwister/.bash_logout
 .bash_profile -> /accounts/bittwister/.bash_profile
 .bashrc -> /accounts/bittwister/.bashrc
 local -> /accounts/bittwister/local
 mail -> /accounts/bittwister/mail
 .thunderbird -> /accounts/bittwister/.thunderbird
 .VirtualBox -> /vmguest/vm


> I say shared as the device has to be
> mounted, but each distro will write in its own branch by
> default, letting me decide if not.

Snippet from my
  $ wc -l < /etc/fstab
  33
line fstab

$ cat /etc/fstab
LABEL=cauldron / ext4 relatime,acl 1 1
LABEL=cauldron_bkup /cauldron_bkup ext4 users,noauto,relatime,acl 1 2
LABEL=accounts /accounts ext4 relatime,acl 1 2
LABEL=local /local ext4 relatime,acl 1 2
LABEL=misc /misc ext4 relatime,acl 1 2
PARTLABEL=swap swap swap defaults 0 0
LABEL=mga6 /mga6 ext4 users,noauto,relatime,acl 1 2
LABEL=mga4 /mga4 ext4 users,noauto,relatime,acl 1 2
LABEL=mga5 /mga5 ext4 users,noauto,relatime,acl 1 2
LABEL=vmguest /vmguest ext4 relatime,acl 1 2

> So this I think is not a home sharing, just DATA sharing :
> just home relocation in a shared drive.

Not me. /home is in / for each install. I have a install_links
script to read /accounts/$USER and each file/directory found is
created as a soft link back to /accounts/$USER.

> I have thought of SYMLINKING.

Yes.


> So the question : is it there a question to associate every
> home/user of one distro with the specific corresponding
> subfolder on another drive ?

Yes, see above examples. Currently I have
    $ ls -ald * | grep /accounts | wc -l
    78
links of files and directories in $HOME.

> Is it possible ? safe ? What risks I should be aware of
> before trying ?

User's UID/GID values have to the same in all installs.
Same thing for any groups you created for data sharing.

What I do is first account created is "normal". That account is
not modified. After boot, I create "junk". make small changes, then
use it for root access to proceed with adding users and /etc/fstab,...
changes.

Those user's UID/GID can be whatever assigned by the system.
All other users/groups UID/GID are 15xx. Examples:
  $ id normal
  uid=1000(normal) gid=1000(normal)

  $ id junk
  uid=1001(junk) gid=1001(junk)

  $ id $USER
  uid=1500(bittwister) gid=1500(bittwister)

  $ id browser
  uid=1508(browser) gid=1508(browser)

> N.B. I dont want to share settings and config files,

With /home in /, that is not a problem.

> to the
> contrary I need to be sure no conflict can happen and every
> distribution (also on a per-user basis, even if I intend to
> have just one user each) has its private home,

Works for me.

> even if
> actual data is on another drive which is shared as a whole
> among distros (auto mounted in every one)

If talking about /home for each OS, then you increase chances of
one OS screwing up the other.

Have you thought about upgrades and backups?

For example. I use four partitions for my "Production" install.
One is backup, the other three partitions are for previous, current,
and next install of OS. That way I can compare previous and current /
for changes. and next is for testing that the next release is good
enough for production use.

[toc] | [prev] | [next] | [standalone]

#56835

On 13/06/2019 20.47, Soviet_Mario wrote:

> I'd want to leverage to f12 bios option (boot device manual selection) 
> to make a choice.

Should work well, but you may up with a huge list of boot options on 
each individual grub installer as many distributions has setup a script 
to find other installed OS:es on the machine.


> Meanwhile, as I have a big NEW and certified hdd (non ssd, a WD-red 2 
> TB), I'd also be willing to move the actual data of every HOME of any  
> distro, each in a separate subtree of "\homes" shared folder.

I would avoid using a samba share, it's slower and do not support 
everything that is expected from a Linux file system.

NFS would be a lot better.

Issue you can have with network file systems is that all the lock files 
can exhaust the IO. So you want to keep the writes and reads to a 
minimum, so avoid using google chrome, chromium, firefox and so on.


> I have thought of SYMLINKING.

Why? Never thought of using the correct path instead when you mount the 
directory?


-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#56839

On Fri, 14 Jun 2019 01:05:52 -0400, J.O. Aho <user@example.net> wrote:

> On 13/06/2019 20.47, Soviet_Mario wrote:
>> I have thought of SYMLINKING.

> Why? Never thought of using the correct path instead when you mount the
> directory?

There are many applications that default to using ~/Downloads or other
subdirectories in /home/$USER. It's easier to use a short script once
after each installation, that replaces those directories with the symlinks
to the directories in the data mounted file system, than to remember to change the locations in every one of those applications, on every install.

In my case I have an i586 and an x86_64 installation of each supported
release of Mageia linux, and the in development release.

Currently that's 4 installations, but at times I have 6. I have other
partitions used during the iso testing, but those are only for testing
the installers, not for normal usage.

Regards, Dave Hodgins

-- 
Change dwhodgins@nomail.afraid.org to davidwhodgins@teksavvy.com for
email replies.

[toc] | [prev] | [next] | [standalone]

#56845

Il 14/06/19 10:17, David W. Hodgins ha scritto:
> On Fri, 14 Jun 2019 01:05:52 -0400, J.O. Aho 
> <user@example.net> wrote:
> 
>> On 13/06/2019 20.47, Soviet_Mario wrote:
>>> I have thought of SYMLINKING.
> 
>> Why? Never thought of using the correct path instead when 
>> you mount the
>> directory?
> 
> There are many applications that default to using 
> ~/Downloads or other
> subdirectories in /home/$USER.

that's why I was looking for a way of redirecting the 
toplevel home/user as a whole, rather than every item it 
contains ...

But I didn't understand what J,O,Aho intended

> It's easier to use a short 

well, it's easier FOR YOU :)

> script once
> after each installation, that replaces those directories 
> with the symlinks

what's wrong in symlinking the container itself as a whole, 
and how is it done ?

> to the directories in the data mounted file system, than to 
> remember to change the locations in every one of those 
> applications, on every install.

a doubt : before changing the mount point, I should manually 
clone the home/user content to transfer to new location, 
correct ?

Tnx


> 
> In my case I have an i586 and an x86_64 installation of each 
> supported
> release of Mageia linux, and the in development release.
> 
> Currently that's 4 installations, but at times I have 6. I 
> have other
> partitions used during the iso testing, but those are only 
> for testing
> the installers, not for normal usage.
> 
> Regards, Dave Hodgins
> 


-- 
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
Soviet_Mario - (aka Gatto_Vizzato)

[toc] | [prev] | [next] | [standalone]

#56848

On 2019-06-14, Soviet_Mario <SovietMario@CCCP.MIR> wrote:
> Il 14/06/19 10:17, David W. Hodgins ha scritto:
>> On Fri, 14 Jun 2019 01:05:52 -0400, J.O. Aho 
>> <user@example.net> wrote:
>> 
>>> On 13/06/2019 20.47, Soviet_Mario wrote:
>>>> I have thought of SYMLINKING.
>> 
>>> Why? Never thought of using the correct path instead when 
>>> you mount the
>>> directory?
>> 
>> There are many applications that default to using 
>> ~/Downloads or other
>> subdirectories in /home/$USER.
>
> that's why I was looking for a way of redirecting the 
> toplevel home/user as a whole, rather than every item it 
> contains ...

No idea what that is supposed to mean.
If you want to mount /home/user somewhere else, do so. /home is not
sacred. 
I have /home as a symlink to /local/home, where /local is a separate
partition, so when I reinstall I do not mess up /home.

>
> But I didn't understand what J,O,Aho intended
>
>> It's easier to use a short 
>
> well, it's easier FOR YOU :)
>
>> script once
>> after each installation, that replaces those directories 
>> with the symlinks
>
> what's wrong in symlinking the container itself as a whole, 
> and how is it done ?

No idea what that means. 

>
>> to the directories in the data mounted file system, than to 
>> remember to change the locations in every one of those 
>> applications, on every install.
>
> a doubt : before changing the mount point, I should manually 
> clone the home/user content to transfer to new location, 
> correct ?

No idea what you are asking. 

>
> Tnx
>
>
>> 
>> In my case I have an i586 and an x86_64 installation of each 
>> supported
>> release of Mageia linux, and the in development release.
>> 
>> Currently that's 4 installations, but at times I have 6. I 
>> have other
>> partitions used during the iso testing, but those are only 
>> for testing
>> the installers, not for normal usage.
>> 
>> Regards, Dave Hodgins
>> 
>
>

[toc] | [prev] | [next] | [standalone]

#56850

On 14/06/2019 17.41, Soviet_Mario wrote:
> Il 14/06/19 10:17, David W. Hodgins ha scritto:
>> On Fri, 14 Jun 2019 01:05:52 -0400, J.O. Aho <user@example.net> wrote:
>>
>>> On 13/06/2019 20.47, Soviet_Mario wrote:
>>>> I have thought of SYMLINKING.
>>
>>> Why? Never thought of using the correct path instead when you mount the
>>> directory?
>>
>> There are many applications that default to using ~/Downloads or other
>> subdirectories in /home/$USER.
> 
> that's why I was looking for a way of redirecting the toplevel home/user 
> as a whole, rather than every item it contains ...
> 
> But I didn't understand what J,O,Aho intended

Use bind mount to mount /home instead of using a symlink, or if it's a 
remote storage, then nfs has the capability to mount a subdirectory as 
/home, this to avoid locking if the source is missing which you can get 
if you are using symlinks.


-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#56849

On 14/06/2019 10.17, David W. Hodgins wrote:
> On Fri, 14 Jun 2019 01:05:52 -0400, J.O. Aho <user@example.net> wrote:
> 
>> On 13/06/2019 20.47, Soviet_Mario wrote:
>>> I have thought of SYMLINKING.
> 
>> Why? Never thought of using the correct path instead when you mount the
>> directory?
> 
> There are many applications that default to using ~/Downloads or other
> subdirectories in /home/$USER. It's easier to use a short script once
> after each installation, that replaces those directories with the symlinks
> to the directories in the data mounted file system, than to remember to 
> change the locations in every one of those applications, on every install.

Why not use bind mount the directory you want to be home? The more 
proper way of doing things.

/your/local/disk/subfolder    /home               none    bind 0 0

or

remotemachine:/path/to/share   /home/   nfs4    defaults,noatime  0  0

bind mounts will fail if the source is missing, symlink can cause random 
locks


-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.os.linux

csiph-web