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

Groups > linux.debian.user > #168527 > unrolled thread

Advice sought re HDD --> SSD migration

Back to article view | Back to linux.debian.user

Contents

  Advice sought re HDD --> SSD migration Mark Fletcher <mark27q1@gmail.com> - 2016-06-04 13:20 +0200
    Re: Advice sought re HDD --> SSD migration Dan Purgert <dan@djph.net> - 2016-06-04 14:40 +0200
      Re: Advice sought re HDD --> SSD migration Stefan Monnier <monnier@iro.umontreal.ca> - 2016-06-04 21:00 +0200
    Re: Advice sought re HDD --> SSD migration David Christensen <dpchrist@holgerdanske.com> - 2016-06-04 22:40 +0200
      Re: Advice sought re HDD --> SSD migration Mark Fletcher <mark27q1@gmail.com> - 2016-06-05 13:50 +0200
        Re: Advice sought re HDD --> SSD migration Felix Miata <mrmazda@earthlink.net> - 2016-06-05 14:40 +0200
          Re: Advice sought re HDD --> SSD migration Mark Fletcher <mark27q1@gmail.com> - 2016-06-05 15:20 +0200
            Re: Advice sought re HDD --> SSD migration <tomas@tuxteam.de> - 2016-06-05 15:50 +0200
          Re: Advice sought re HDD --> SSD migration David Wright <deblis@lionunicorn.co.uk> - 2016-06-05 16:10 +0200
            Re: Advice sought re HDD --> SSD migration Mark Fletcher <mark27q1@gmail.com> - 2016-06-05 17:00 +0200
        Re: Advice sought re HDD --> SSD migration David Christensen <dpchrist@holgerdanske.com> - 2016-06-06 00:30 +0200
          Re: Advice sought re HDD --> SSD migration Mark Fletcher <mark27q1@gmail.com> - 2016-06-09 16:20 +0200
            Re: Advice sought re HDD --> SSD migration David Wright <deblis@lionunicorn.co.uk> - 2016-06-09 20:40 +0200
            Re: Advice sought re HDD --> SSD migration Jonathan Dowland <jmtd@debian.org> - 2016-06-10 12:20 +0200
              Re: Advice sought re HDD --> SSD migration Mark Fletcher <mark27q1@gmail.com> - 2016-06-10 16:30 +0200
    Re: Advice sought re HDD --> SSD migration Jonathan Dowland <jmtd@debian.org> - 2016-06-10 12:30 +0200

#168527 — Advice sought re HDD --> SSD migration

[Multipart message — attachments visible in raw view] — view raw

Hi

I've recently decided to upgrade my main PC, running Debian Jessie, to use
SSDs instead of HDDs. Right now I am halfway through the process, having
done what I consider the easy part, and about to start the potentially more
difficult part.

The machine is a self-built circa 2009 machine with an Intel Core i7-920
processor, 24GB of RAM (originally built with 8GB and upgraded later) and
1.5TB of disk space originally spread over 2 HDDs -- 1 500GB disk which
contained the whole filesystem except /opt with multiple partitions, and 1
1TB disk which is mounted on /opt.

The 1TB disk contains a mysql database instance, and also houses 2 Windows
VirtualBox VMs for those few things I still need Windows for.  It's also
got a collection of videos and space for video transcoding work I do
sometimes.

The migration was easy for the /opt disk -- just install the SSD, partition
it, create an ext4 filesystem on it, mount it somewhere temporary, copy
everything over from the /opt harddisk, and modify fstab so that it
automounts the SSD going forward instead of the hard disk. I then rebooted
to make certain I was fully over to the SSD. The 1TB HDD is still inside
the machine but I plan to remove it when I open the box up again to add the
second SSD. I'll set up periodic TRIM as a next step.

I've got a feeling though that the main disk is going to be a bit more of a
challenge, and that is what I want advice about. I'm thinking I should boot
from a live image and effect the copy there so that the disk is not mounted
and in active use. Is that along the right lines or is there a better way?

The replacement SSD is 960GB where the original hard disk is 500GB. Would
you recommend a dd if=/dev/sda of=/dev/sdd (or whatever it turns out to
be), or a cp -r command like I used for the /opt disk, or some other way to
execute the migration?

One complication is when I originally partitioned the 500GB disk I may have
overdone it a bit. I've got separate partitions for /boot, /usr, /home,
/tmp, /var, swap space and the root partition. I now consider that I
overdid that and would ideally like to collapse /usr, /tmp and /var into
the (correpondingly bigger) root partition, ie not have separate partitions
for them and end up with root, /boot and /home (BIOS is too old for UEFI so
using MBR booting so /boot partition makes sense). But, if trying to do so
is going to make life significantly harder, I can accept not doing so --
but I do want to make full use of the available space on the new device so
the partitions will not be the same size as they were.

What other things should I be concerned about (for example the discussion
about ping using capabilities that was on this list a day or two back)? Oh,
and speaking of MBR, as I was a paragraph ago, anything I should watch out
for when trying to make the SSD bootable?

And anything else I should bear in mind when migrating to SSDs on a system
that was originally installed on HDDs?

The HDDs are about 7 years old now -- the 500GB one has been in the machine
since I built it, the 1TB is a replacement since its predecessor didn't
enjoy the 2011 earthquake (I live in Tokyo, Japan) and failed shortly
afterward. Hence my desire to migrate to newer hardware before they start
failing again -- plus the speed and quiet advantages -- I figure with this
upgrade plus adding a USB3 PCIe card I have a machine that's on par with
any I could buy today.

The SSDs are recently-bought SanDisk Ultra II 960GB devices, Japanese
model. I've already checked they have the latest firmware.

Thanks in advance for any advice.

Mark

[toc] | [next] | [standalone]

#168528

Mark Fletcher wrote:
> --001a114056c6ba860d053471e7cb
> Content-Type: text/plain; charset=UTF-8
>
> Hi
>
> I've recently decided to upgrade my main PC, running Debian Jessie, to use
> SSDs instead of HDDs. Right now I am halfway through the process, having
> done what I consider the easy part, and about to start the potentially
> more difficult part.
> [snip]
> I've got a feeling though that the main disk is going to be a bit more
> of a challenge, and that is what I want advice about. I'm thinking I
> should boot from a live image and effect the copy there so that the
> disk is not mounted and in active use. Is that along the right lines
> or is there a better way?
>
> The replacement SSD is 960GB where the original hard disk is 500GB. Would
> you recommend a dd if=/dev/sda of=/dev/sdd (or whatever it turns out to
> be), or a cp -r command like I used for the /opt disk, or some other
> way to execute the migration?

Treat it as a new PC.  Unplug the other drives, and use an install CD to
handle formatting and everything else (including base installation of
the OS).  Set up the drive however you want wrt partitions.

'dd' will at best get you a 500GB disk on your new 900G SSD.  and then
you'll have to fight with it (fdisk, etc.) in order to use the rest of
the space.

NB - you don't /have/ to mess with unplugging the drives, but I like
/dev/sda being my main drive, which probably wouldn't happen if you left
the other drives plugged in.  It's more of a "do things the way I want"
thing than anything else

Once the base system is installed (including any programs you use), plug
the other drives back in, and copy important stuff (e.g. your $HOME,
/etc, and anything else) from the 500G spinning rust drive to your main
SSD. 
>
> What other things should I be concerned about (for example the discussion
> about ping using capabilities that was on this list a day or two
> back)? Oh, and speaking of MBR, as I was a paragraph ago, anything I
> should watch out for when trying to make the SSD bootable?

Never not backup.  Other than that, I don't think there's much in the
way of "stuff to watch out for".

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| 

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

#168539

> 'dd' will at best get you a 500GB disk on your new 900G SSD.

Not at all.  You can easily use the remaining space afterwards.

As for me, I indeed wouldn't use `dd` in your case.  Because instead,
I'd move to LVM.  I.e. setup an LVM volume group on your new disk, and
create logical volumes for / and /home (and maybe /boot as well since
Grub can now boot off of LVM, but I tend to keep my /boot partition
outside of LVM).

Then use `cp -a` (or `rsync`) to copy stuff from your old disk to the
new.  You can definitely do that while the system is up and running (no
need to boot with some other live image.  I've done that many times and
never had a problem), tho you probably do want to try and make sure that
it's sufficiently idle.  If you want to use `dd`, then indeed you should
make sure the source partition is not mounted (or is mounted read-only),
otherwise you could end up with a new filesystem that's too corrupted.


        Stefan

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

#168544

On 06/04/2016 04:11 AM, Mark Fletcher wrote:
> I've recently decided to upgrade my main PC, running Debian Jessie, to use
> SSDs instead of HDDs. ...
> The machine is a self-built circa 2009 machine with an Intel Core i7-920
> processor, 24GB of RAM ... 1 500GB disk which
> contained the whole filesystem except /opt with multiple partitions, and 1
> 1TB disk which is mounted on /opt.
...
> The migration was easy for the /opt disk -- just install the SSD, partition
> it, create an ext4 filesystem on it, mount it somewhere temporary, copy
> everything over from the /opt harddisk, and modify fstab ...
> I've got a feeling though that the main disk is going to be a bit more of a
> challenge, and that is what I want advice about. I'm thinking I should boot
> from a live image and effect the copy there so that the disk is not mounted
> and in active use. Is that along the right lines or is there a better way?
>
> The replacement SSD is 960GB where the original hard disk is 500GB. Would
> you recommend a dd if=/dev/sda of=/dev/sdd (or whatever it turns out to
> be), or a cp -r command like I used for the /opt disk, or some other way to
> execute the migration?
>
> One complication is when I originally partitioned the 500GB disk I may have
> overdone it a bit. I've got separate partitions for /boot, /usr, /home,
> /tmp, /var, swap space and the root partition. I now consider that I
> overdid that and would ideally like to collapse /usr, /tmp and /var into
> the (correpondingly bigger) root partition, ie not have separate partitions
> for them and end up with root, /boot and /home (BIOS is too old for UEFI so
> using MBR booting so /boot partition makes sense). But, if trying to do so
> is going to make life significantly harder, I can accept not doing so --
> but I do want to make full use of the available space on the new device so
> the partitions will not be the same size as they were.
>
> What other things should I be concerned about (for example the discussion
> about ping using capabilities that was on this list a day or two back)? Oh,
> and speaking of MBR, as I was a paragraph ago, anything I should watch out
> for when trying to make the SSD bootable?
>
> And anything else I should bear in mind when migrating to SSDs on a system
> that was originally installed on HDDs?
...
> The SSDs are recently-bought SanDisk Ultra II 960GB devices, ...

I assume you've implemented backup, restore, imaging, archiving, etc..


dd'ing the 500 GB onto the second SSD should work.


But, if it were my box:

1.  Buy a 16+ GB SSD to use as the i7-920 system drive, install and 
connect to motherboard SATA-0 port (dev/sda), and do a fresh install 
with MBR and three partitions -- ext4 boot, LUKS random key swap, and 
LUKS btrfs root.

2.  Install the two 960 GB SSD's.  Set up each with GPT partition table, 
one large partition, and LUKS.  Put RAID1 copy-on-write (COW) file 
system on top -- mdadm RAID1 plus btrfs, LVM RAID1 plus btrfs, btrfs 
with RAID1 (if supported), or ZFS on Linux (ZOL) mirror.

3.  If you choose ZOL, leave space on the system drive, add a fourth 
partition with LUKS, and use it for the L2ARC.

4. If you're going to use this as a headless SOHO file server, a USB 3.0 
flash drive could work as your system drive.  If you do this and also 
choose ZOL, it would be best to use another USB 3.0 flash drive for the 
L2ARC.



David

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

#168567

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jun 5, 2016 at 5:34 AM David Christensen <dpchrist@holgerdanske.com>
wrote:

> On 06/04/2016 04:11 AM, Mark Fletcher wrote:
>
> I assume you've implemented backup, restore, imaging, archiving, etc..
>
>
> dd'ing the 500 GB onto the second SSD should work.
>
>
> But, if it were my box:
>
> 1.  Buy a 16+ GB SSD to use as the i7-920 system drive, install and
> connect to motherboard SATA-0 port (dev/sda), and do a fresh install
> with MBR and three partitions -- ext4 boot, LUKS random key swap, and
> LUKS btrfs root.
>
> 2.  Install the two 960 GB SSD's.  Set up each with GPT partition table,
> one large partition, and LUKS.  Put RAID1 copy-on-write (COW) file
> system on top -- mdadm RAID1 plus btrfs, LVM RAID1 plus btrfs, btrfs
> with RAID1 (if supported), or ZFS on Linux (ZOL) mirror.
>
> 3.  If you choose ZOL, leave space on the system drive, add a fourth
> partition with LUKS, and use it for the L2ARC.
>
> 4. If you're going to use this as a headless SOHO file server, a USB 3.0
> flash drive could work as your system drive.  If you do this and also
> choose ZOL, it would be best to use another USB 3.0 flash drive for the
> L2ARC.
>
>
Thanks all for the comments. So I have one vote for fresh install, one vote
for copy, and one vote for do something completely different and turn the
box into something else because.. RAID. I think.

The box is my main desktop system, and yes it would p*ss me off something
chronic if it went down for any length of time, but it wouldn't be
critical, no revenue loss etc. So backups are good enough. My critical,
revenue-affecting machines are all outside my home. So I don't think I'll
bother going RAID at this time. Also if I understand correctly, this option
would end up reducing my available space from 1.5TB in HDD land to 1TB (or
960GB) in SSD land, which is also a disadvantage.

The LVM idea is useful, and may allow me to put the extra space on the
first disk to good use by potentially combining it with space from the
second disk. I will look into that. Could do that even if I were doing a
fresh install. Thanks for that idea!

I am then faced with the choice of the "Fresh install to new SSD followed
by copy" option or the "cp -a" option. I assume I'd need to have not booted
from the main disk in the latter case because if I had, for example, /dev
would contain  ton of stuff I don't want to / can't copy, ditto /proc etc.
In other words it would be harder to separate what is actually on the old
disk as opposed to in the Linux file system. Whereas if the disk was
mounted somewhere like /mnt copying what is actually on the disk becomes
easier.

I think both these options have one potential pitfall, which is file
ownership after the copy over of stuff I want to salvage from the outgoing
HDD. If I do a fresh install, no guarantee that user IDs will be the same
on the new system as I of course don't remember now what order I installed
stuff in. My regular user ID created during install will no doubt get the
same ID (although even that is not guaranteed as this machine started life
as etch, if I remember rightly, then was upgraded to squeeze, then to
wheezy, and finally to Jessie). And I don't remember exactly when I
installed, for example, mysql in relation to other stuff. So I could have
some fun and games copying stuff over from the old disk to the new from
that perspective. Any clever ploys to deal with that? I suppose avoid the
install and copy from new to old having booted from old is one way, but
then how do I copy only what's actually on the disk eg avoid virtual
filesystems?

The big advantage of the fresh install though is that the install will take
care of grub which is a plus. I could do that manually but would be afraid
of effing it up.

Hmmmm, much to ponder. Thanks all for your thoughts.

Mark

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

#168569

Mark Fletcher composed on 2016-06-05 11:40 (UTC):

> I think both these options have one potential pitfall, which is file
> ownership after the copy over of stuff I want to salvage from the outgoing
> HDD. If I do a fresh install, no guarantee that user IDs will be the same
> on the new system as I of course don't remember now what order I installed
> stuff in. My regular user ID created during install will no doubt get the
> same ID (although even that is not guaranteed as this machine started life
> as etch, if I remember rightly, then was upgraded to squeeze, then to
> wheezy, and finally to Jessie). And I don't remember exactly when I
> installed, for example, mysql in relation to other stuff. So I could have
> some fun and games copying stuff over from the old disk to the new from
> that perspective. Any clever ploys to deal with that?

Before you start, print /etc/passwd and /etc/group. :-)

When forced to create a user during installation, I create user x with passwd 
x, and the first thing I do on first boot is login as root and delete user x. 
I then install mc and do my "tidy up" before creating the group(s) I want and 
then use a script to create users, followed by setting users' initial passwds.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

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

#168571

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jun 5, 2016 at 9:31 PM Felix Miata <mrmazda@earthlink.net> wrote:


> Before you start, print /etc/passwd and /etc/group. :-)
>
> When forced to create a user during installation, I create user x with
> passwd
> x, and the first thing I do on first boot is login as root and delete user
> x.
> I then install mc and do my "tidy up" before creating the group(s) I want
> and
> then use a script to create users, followed by setting users' initial
> passwds.
>
>
/etc/passwd and /etc/group are still the last word in identities in these
latter days of password shadowing and gawd alone knows what else?

(My own research suggests the answer is YES for what users are on the
system and NO for passwords. I'm not doing anything funky like using LDAP
or anything for passwords, just what comes out of the box when you install
Debian)

Mark

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

#168572

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Jun 05, 2016 at 01:13:18PM +0000, Mark Fletcher wrote:
> On Sun, Jun 5, 2016 at 9:31 PM Felix Miata <mrmazda@earthlink.net> wrote:
> 
> 
> > Before you start, print /etc/passwd and /etc/group. :-)

[...]

> /etc/passwd and /etc/group are still the last word in identities in these
> latter days of password shadowing and gawd alone knows what else?
> 
> (My own research suggests the answer is YES for what users are on the
> system and NO for passwords. I'm not doing anything funky like using LDAP
> or anything for passwords, just what comes out of the box when you install
> Debian)

Yes, usually the encrypted passwords are in /etc/shadow (and in its dark
sister /etc/shadow-. Typically, if the password field in passwd is 'x',
the real thing is in shadow.

The gory details in 'man 5 shadow'

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAldUK/IACgkQBcgs9XrR2kYvvQCfQ0xK99STqUu2IXG07Ywvlmy0
un4An2dAkEN1dKbdRxt4skYG/pph4Y72
=XuLf
-----END PGP SIGNATURE-----

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

#168575

On Sun 05 Jun 2016 at 08:30:38 (-0400), Felix Miata wrote:
> Mark Fletcher composed on 2016-06-05 11:40 (UTC):
> 
> >I think both these options have one potential pitfall, which is file
> >ownership after the copy over of stuff I want to salvage from the outgoing
> >HDD. If I do a fresh install, no guarantee that user IDs will be the same
> >on the new system as I of course don't remember now what order I installed
> >stuff in. My regular user ID created during install will no doubt get the
> >same ID (although even that is not guaranteed as this machine started life
> >as etch, if I remember rightly, then was upgraded to squeeze, then to
> >wheezy, and finally to Jessie). And I don't remember exactly when I
> >installed, for example, mysql in relation to other stuff. So I could have
> >some fun and games copying stuff over from the old disk to the new from
> >that perspective. Any clever ploys to deal with that?
> 
> Before you start, print /etc/passwd and /etc/group. :-)
> 
> When forced to create a user during installation, I create user x
> with passwd x, and the first thing I do on first boot is login as
> root and delete user x. I then install mc and do my "tidy up" before
> creating the group(s) I want and then use a script to create users,
> followed by setting users' initial passwds.

I think users and their passwords are the least of the problem.
A fresh install of jessie sets up about 30 system users before
the admin ($UID=1000) gets a look-in. So you can end up with your
email system being owned by statd.messagebus instead of
Debian-exim.Debian-exim for example.

You can diagnose the extent of the problem with a command like:

# find / -mount -not -group 0 -exec ls -ld {} \; -o -not -user 0 -exec ls -ld {} \; | less

but fixing it is probably a matter of    for ... chown ...

Cheers,
David.

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

#168582

[Multipart message — attachments visible in raw view] — view raw

On Sun, Jun 5, 2016 at 11:06 PM David Wright <deblis@lionunicorn.co.uk>
wrote:

> On Sun 05 Jun 2016 at 08:30:38 (-0400), Felix Miata wrote:
> > Mark Fletcher composed on 2016-06-05 11:40 (UTC):
> >
>
>
> I think users and their passwords are the least of the problem.
> A fresh install of jessie sets up about 30 system users before
> the admin ($UID=1000) gets a look-in. So you can end up with your
> email system being owned by statd.messagebus instead of
> Debian-exim.Debian-exim for example.
>
> You can diagnose the extent of the problem with a command like:
>
> # find / -mount -not -group 0 -exec ls -ld {} \; -o -not -user 0 -exec ls
> -ld {} \; | less
>
> but fixing it is probably a matter of    for ... chown ...
>
> Cheers,
> David.
>
>
Yes, that is exactly what I was thinking, since all those system users are,
in the end, users. It was those I had in mind. This computer only happens
to have one human user, me.  I am, indeed, the least of my worries :-)

Mark

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

#168602

On 06/05/2016 04:40 AM, Mark Fletcher wrote:
> ... if I understand correctly, [the SSD 960 GB RAID1] option would
> end up reducing my available space from 1.5TB in HDD land to 1TB (or
>  960GB) in SSD land, which is also a disadvantage.

A large SSD RAID is great for multimedia editor scratch files,
databases, web server content, etc..  But, it is a waste for bulk data. 
  You could use the 500 GB and 1 TB drives for bulk data now, and then 
migrate to large HDD's/ RAID later.


> ... Any clever ploys to deal with [changing UID's and GID's after a
> fresh install]?

For users, I track usernames, UID's, and GID's, and refer to that when 
creating accounts.


For services, I restore and chown -R if needed (I don't run many 
services, and the Debian project seems to have kept service UID's/GID's 
fairly stable over the years).


David

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

#168741

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jun 6, 2016 at 7:24 AM David Christensen <dpchrist@holgerdanske.com>
wrote:

> On 06/05/2016 04:40 AM, Mark Fletcher wrote:
>
>
> > ... Any clever ploys to deal with [changing UID's and GID's after a
> > fresh install]?
>
> For users, I track usernames, UID's, and GID's, and refer to that when
> creating accounts.
>
>
> For services, I restore and chown -R if needed (I don't run many
> services, and the Debian project seems to have kept service UID's/GID's
> fairly stable over the years).
>
>
> David
>
>
>
In the end I successfully completed this. I removed the 1TB hard disk which
I had already migrated, moved the replacement SSD to where it had been, and
plugged in the other SSD which was to replace the 500GB main hard disk.
Booted as normal, and the trick was to mount the hard disk
(/dev/sda1,sd5,sda6,sda8 and sda9 ) to separate places on the filesystem.

So I created mount points under mnt for newroot, newhome, oldroot, oldusr,
oldvar, oldhome, mounted the partitions of the hard disk in those mounts,
(in addition to where they were mounted as part of the boot process, eg /,
/tmp, /usr etc) and the partitions of the new SSD (which I first had to
make) in newroot and newhome. Then it was fairly simple cp -a jobs to copy
everything over from there. Doing it that way, I copied what was on the
disk surface but didn't inadvertently grab anything that was actually in a
virtual file system.

I tried to be clever and use GPT partitions on the first SSD, thus proving
I wasn't in fact clever when I tried to install grub and found I needed to
have a "BIOS boot partition" (whatever that is) and didn't. So rather than
eff around unnecessarily with getting MBR boot to work on a GPT partition I
used parted to wipe the label and go back to a "msdos" partition scheme,
recreated the partitions and the file systems, and copied everything a
second time.

Then, install grub to the SSD using grub-install
--boot-directory=/mnt/newroot/boot /dev/sdc and then a grub-mkconfig -o
/mnt/newroot/boot/grub/grub.cfg.

Then reboot, and tell the BIOS setup to boot from the SSD first not the
hard disk. That fired up grub and I was able to select the SSD-installed
Linux. That booted successfully and that's what I'm using to write this.

Because I worked that way I had no file ownership problems, but I did
notice messed up permissions on the directories under / that had previously
been mount points, eg /usr, /tmp etc. Although /var was OK. For example
/usr was world writable which VirtualBox was none too impressed with.
Easily fixed, but I don't know why it happened.

Just one thing I wasn't sure about -- what should the permissions of the
/media directory be?

Apart from fixing that, what's left to do is to disconnect and remove the
500GB hard disk, move the SSD to the hard disk's SATA port so it is
/dev/sda, modify grub.cfg to reflect the move and to remove the hard-disk
boot menu items which grub-mkconfig, trying to be helpful, generated.

But I'm basically there apart from my question above about the permissions
of /media.

Thanks all for the advice -- was very helpful.

Mark

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

#168749

On Thu 09 Jun 2016 at 14:13:58 (+0000), Mark Fletcher wrote:
> Just one thing I wasn't sure about -- what should the permissions of the
> /media directory be?

drwxr-xr-x  75 root root   4096 Jul 10  2015 media/

I make the mountpoints within:
drwx------ 2 root root 4096 May  5  2014 cdrom0/
which makes users unable to enter them when it would be futile.

Cheers,
David.

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

#168794

On Thu, Jun 09, 2016 at 02:13:58PM +0000, Mark Fletcher wrote:
> Apart from fixing that, what's left to do is to disconnect and remove the
> 500GB hard disk, move the SSD to the hard disk's SATA port so it is
> /dev/sda

Where do you depend upon it being /dev/sda? I'd strongly recommend using
filesystem labels (change an existing ext2,3,4 filesystem label with e2label,
other FS have similar tools) and UUIDs for identifying drives/partitions in
config files. In /etc/fstab, you can use LABEL=foo or UUID=xxxxx where you
would normally use a path to the device; elsewhere (e.g. systemd units) you can
use a path such as /dev/disk/by-label/foo or /dev/disk/by-uuid/xxxxx.

Try to use non-ambiguous labels. If there's any chance of you mixing drives
from this machine and another, I would put e.g. the hostname into the label
(so your /boot is somehostname_boot and should you put this drive in another
machine to read it in the future, it won't clash with that machine's boot
partition label. Assuming you use different hostnames :))

> modify grub.cfg to reflect the move and to remove the hard-disk
> boot menu items which grub-mkconfig, trying to be helpful, generated.

Unless you have customized your grub config, they should automatically disappear
after you've removed those drives and re-ran update-grub2. It should also be
working off UUIDs rather than device names like /dev/sda too, mind...

> But I'm basically there apart from my question above about the permissions
> of /media.

mine is just

drwxr-xr-x 5 root root 4096 May  5 17:09 /media

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

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

#168800

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jun 10, 2016 at 7:14 PM Jonathan Dowland <jmtd@debian.org> wrote:

> On Thu, Jun 09, 2016 at 02:13:58PM +0000, Mark Fletcher wrote:
> > Apart from fixing that, what's left to do is to disconnect and remove the
> > 500GB hard disk, move the SSD to the hard disk's SATA port so it is
> > /dev/sda
>
> Where do you depend upon it being /dev/sda? I'd strongly recommend using
> filesystem labels (change an existing ext2,3,4 filesystem label with
> e2label,
> other FS have similar tools) and UUIDs for identifying drives/partitions in
> config files. In /etc/fstab, you can use LABEL=foo or UUID=xxxxx where you
> would normally use a path to the device; elsewhere (e.g. systemd units)
> you can
> use a path such as /dev/disk/by-label/foo or /dev/disk/by-uuid/xxxxx.
>
>
Don't recall suggesting I depend on it being /dev/sda. In fact right now it
is /dev/sdc and everything seems to be working. UUIDs all the way here.

I just like to keep things neat and tidy -- two disks, the main one I boot
from and a second with a big data space -- sda and sdb, makes sense to me.
And I'm clearly not the only one who feels that way as one of the earliest
replies on this thread made the same point.


> Try to use non-ambiguous labels. If there's any chance of you mixing drives
> from this machine and another


There isn't, but I can see in some people's cases there might be.


> > modify grub.cfg to reflect the move and to remove the hard-disk
> > boot menu items which grub-mkconfig, trying to be helpful, generated.
>
> Unless you have customized your grub config, they should automatically
> disappear
> after you've removed those drives and re-ran update-grub2. It should also
> be
> working off UUIDs rather than device names like /dev/sda too, mind...
>
> Um, not sure I understand that. To my thinking, I'll need to have updated
grub.cfg _before_ shutting down to remove the hard disk, since after
removing it I won't be able to boot since I'll have moved the SSD and it
won't be on the SATA port the grub.cfg is expecting.... Oh hang on, your
point is that it should be identified by UUID... Will need to check, maybe
it is, that will be good -- but I think I remember seeing something like
(hd2,msdos1) or something in the grub config generated by grub-mkconfig and
that won't be true any more after I swap connectors on the SSD. So I was
thinking I'd need to modify that, then shut down to physically remove the
HDD and move the SSD, then bring it back up, and if I've messed up the grub
config it will be time to boot from a live thumb drive to fix it...

> But I'm basically there apart from my question above about the permissions
> > of /media.
>
> mine is just
>
> drwxr-xr-x 5 root root 4096 May  5 17:09 /media
>
> Thanks to you, and to David Wright, for this info. Appreciate it. And it
makes sense. I was worried about needing suid bits or some other magic, but
seems not.

Thanks again for all the advice on this, list!

Mark

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

#168795

On Sat, Jun 04, 2016 at 11:11:37AM +0000, Mark Fletcher wrote:
> I've got a feeling though that the main disk is going to be a bit more of a
> challenge, and that is what I want advice about. I'm thinking I should boot
> from a live image and effect the copy there so that the disk is not mounted
> and in active use. Is that along the right lines or is there a better way?

I would suggest doing that, yes.

> The replacement SSD is 960GB where the original hard disk is 500GB. Would
> you recommend a dd if=/dev/sda of=/dev/sdd (or whatever it turns out to
> be), or a cp -r command like I used for the /opt disk, or some other way to
> execute the migration?

I'd go with rsync (-va), run repeatedly until it makes no further changes.

I think doing it at the file level - from a live environment - means the new
(larger) filesystem can make different decisions as to where the files are
located on the underlying device (and the underlying device, doing its own
wear levelling, can do too).

If you do a dd, you're "forcing" all the files to be allocated into a subset
of the new drive capacity, which might not be the most optimal spread.

This is all muddied somewhat by the SSD layer of indirection, which might
make the above completely moot.

> One complication is when I originally partitioned the 500GB disk I may have
> overdone it a bit. I've got separate partitions for /boot, /usr, /home,
> /tmp, /var, swap space and the root partition. I now consider that I
> overdid that and would ideally like to collapse /usr, /tmp and /var into
> the (correpondingly bigger) root partition, ie not have separate partitions
> for them and end up with root, /boot and /home (BIOS is too old for UEFI so
> using MBR booting so /boot partition makes sense).

Perfect. Mount the separate filesystems in the right place for your live
environment (say root at /src, usr at /src/usr etc) and the rsync will
consolidate them for you.

The only other two things I would suggest are

 * if you don't have a regular backup regime, make a backup. Get a proper
   backup routine once you've finished.
 * Use LVM on the destination device.


-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web