Re: [Dorset] Loss of OS during upgrade
Hi Patrick,
> I would normally have reached for diff(1) for a direct comparision
> between two files, out of familiarity.
diff(1) will do for comparing binary files, but GNU diff's heuristic for
determining if the files are binary can be misled so instead of the
normal ‘Binary files foo and bar differ’ one gets confusing output.
$ wc foo bar
993 3069 27568 foo
993 3069 27568 bar
1986 6138 55136 total
$
$ diff foo bar
993c993
< abcdef
---
> abcdef
$
$ diff foo bar | sed -n l
993c993$
< abc\000def$
---$
> abc\adef$
$
$ cmp -l foo bar
27564 0 7
$
> Thanks for cluing me in to b2sum.
It has a nice -l option for when a shorter digest is required.
$ for n in {3..9}; do
> b2sum -l $((2**n)) done
2e -
b1fe -
1271cf25 -
e4a6a0577479b2b4 -
cae66941d9efbd404e4d88758ea67670 -
0e5751c026e543b2e8ab2eb06099daa1d1e5df47778f7787faab45cdf12fe3a8 -
786a02f742015903c6c6fd852552d272912f4740e15847618a86e217f71f5419d25e1031afee585313896444934eb04b903a685b1448b755d56f701afe9be2ce
-
$
--
Cheers, Ralph.
--
Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00
Check to whom you are replying
Meetings, mailing list, IRC, ... http://dorset.lug.org.uk
New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
On Sun, 27 Sep 2020 14:35:39 +0100, Ralph Corderoy wrote: > > Otherwise, you can verify the physical disc in the same way you > > would verify the ISO file. > > True, though I think I recall, back when CD and DVD burning was > common, you had to be careful the block device didn't return a few > more bytes than were in the ISO, e.g. the ISO was an odd number of > KiB and the block device added 1 KiB of zero bytes when reading it > back to make a whole 2 KiB block. Perhaps that wasn't with an ISO > but something else. Anyway, the point remains: if the digests > differ then the number of bytes consumed is of interest. A rather good point. I must have got lucky with the number of bytes, unless the behaviour of the block device has changed. Whoops! > When both are to hand then cmp(1) has the advantage of stopping as > soon as they deviate, rather than reading both to the end, and > indicating how far in that is for further investigation. I went for sha256sum because that's what you would have to use to compare against Mint 20's published checksums, but you are quite right that there is no point in calculating a digest if you are comparing the physical disc against a known-good ISO file. (And, for the example, I did have an ISO file.) I would normally have reached for diff(1) for a direct comparision between two files, out of familiarity. (When all you have is a hammer, etc.) But cmp(1) (new to me) is clearly a better tool for this job. cmp also solves the extra-bytes problem, because it will tell you "EOF on whatever.iso" if the physical disc is identical to the ISO except for having padding at the end. (Not to be confused with "EOF on /dev/cdrom", which would mean the physical disc was incomplete.) Thanks for cluing me in to b2sum. (I don't have it here, but it will probably come with my next OS upgrade.) Patrick -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
Hi Patrick, > Otherwise, you can verify the physical disc in the same way you > would verify the ISO file. True, though I think I recall, back when CD and DVD burning was common, you had to be careful the block device didn't return a few more bytes than were in the ISO, e.g. the ISO was an odd number of KiB and the block device added 1 KiB of zero bytes when reading it back to make a whole 2 KiB block. Perhaps that wasn't with an ISO but something else. Anyway, the point remains: if the digests differ then the number of bytes consumed is of interest. > For example, using the first disc on my pile of old discs: > > $ sha256sum -b Fedora-11-x86_64-Live-KDE.iso > 4fdf952afb0d27887639140f6921ff58ba74f8d633b14414b095eb54b55df405 > *Fedora-11-x86_64-Live-KDE.iso > > $ sha256sum -b /dev/cdrom > 4fdf952afb0d27887639140f6921ff58ba74f8d633b14414b095eb54b55df405 */dev/cdrom When both are to hand then cmp(1) has the advantage of stopping as soon as they deviate, rather than reading both to the end, and indicating how far in that is for further investigation. Also, seeing sha256sum remind me I've recently shifted to b2sum(1) when I need to quickly do that kind of thing as it runs faster than sha256sum here. Just in case you find it useful too for large files. -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
On Sun, 27 Sep 2020 11:12:38 +0100, Ralph Corderoy wrote: > Didn't common distros > add some option soon after the media boots to check the rest of > the media, e.g. read the DVD all the way through to the end of the > image? I believe that is true. Otherwise, you can verify the physical disc in the same way you would verify the ISO file. For example, using the first disc on my pile of old discs: $ sha256sum -b Fedora-11-x86_64-Live-KDE.iso 4fdf952afb0d27887639140f6921ff58ba74f8d633b14414b095eb54b55df405 *Fedora-11-x86_64-Live-KDE.iso $ sha256sum -b /dev/cdrom 4fdf952afb0d27887639140f6921ff58ba74f8d633b14414b095eb54b55df405 */dev/cdrom I have tended to burn optical media using K3B, which has a "Verify written data" option that does much the same thing immediately after writing the disc. Patrick -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
On Sunday, 27 September 2020 11:16:57 BST Terry Coles wrote:
> On Sunday, 27 September 2020 11:12:38 BST Ralph Corderoy wrote:
> > - An error copying it onto the bootable media. Didn't common distros
> >
> > add some option soon after the media boots to check the rest of the
> > media, e.g. read the DVD all the way through to the end of the image?
> > Does anyone here know? I haven't booted installation media in years.
> > I'd expect Mint to have it as a descendant of Debian.
>
> That's my recollection.
I had a thought. This is the last entry in grub.cfg on the Kubuntu 18.10
installation CD, which is the last one I downloaded.
}
menuentry "Check disc for defects" {
set gfxpayload=keep
linux /casper/vmlinuz integrity-check quiet splash ---
initrd /casper/initrd
}
--
Terry Coles
--
Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00
Check to whom you are replying
Meetings, mailing list, IRC, ... http://dorset.lug.org.uk
New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
On Sunday, 27 September 2020 11:12:38 BST Ralph Corderoy wrote: > - An error copying it onto the bootable media. Didn't common distros > add some option soon after the media boots to check the rest of the > media, e.g. read the DVD all the way through to the end of the image? > Does anyone here know? I haven't booted installation media in years. > I'd expect Mint to have it as a descendant of Debian. That's my recollection. -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
Hi Clive, > I tried to follow the last set, and failed (later found I'd made a > spelling mistake!!). That's where pasting the suggested commands instead of typing them helps. :-) > After many attempts to upgrade I've come to the conclusion that the > upgrade DVD is faulty, as that always failed. There's two possible points of failure. - A download error. https://www.linuxmint.com/edition.php?id=281 says AuthenticityDon't forget to verify your ISO and links to a page with instructions to check every byte of the downloaded *.iso file is correct. - An error copying it onto the bootable media. Didn't common distros add some option soon after the media boots to check the rest of the media, e.g. read the DVD all the way through to the end of the image? Does anyone here know? I haven't booted installation media in years. I'd expect Mint to have it as a descendant of Debian. -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
On 25/09/2020 10:58, C Wills wrote: > Hi All > Update on my problems when upgrading Mint 19.3 to Mint 20. > > Thank you all for your help, I tried most suggestions and finally, > yesterday, got everything working. > > Ralph: Thank you for all our suggestions and I tried to follow the > last set, and failed (later found I'd made a spelling mistake!!). > > I did manage to recover all my data files to the separate disk but did > not need them in the end (now stored safely, just in case). > > After many attempts to upgrade I've come to the conclusion that the > upgrade DVD is faulty, as that always failed. > During one recovery attempt (back to 19.3) it repartitioned the SDA > disc and added a EFI partition, as well as the OS (19.3). It replaced > sda1 & 2 with the efi (fat32) and OS partition(ext4), it deleted the > Swop but did not touch sda3 or 4. The efi/OD partitions ended up at > sad5&6, no sda2 or swop. > Don't understand why or how but it all works! > > I'll have to wait till I can get a 'proper' Mint 20 disc before trying > again. Must have tried 6 or 7 times to upgrade hence the thinking > it's a DVD copy problem as at no time did it get passed the loss of > efi problem; even after having a separate efi/fat32 partition. > Thanks again for all the help, it kept me trying! :-) Glad you got it back in working condition. I would suggest you try a package based upgrade - this is what they announced on linuxmint.com as working, as it has worked on three different computers for me. That might yield more success. Hamish signature.asc Description: OpenPGP digital signature -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
[Dorset] Loss of OS during upgrade
Hi All Update on my problems when upgrading Mint 19.3 to Mint 20. Thank you all for your help, I tried most suggestions and finally, yesterday, got everything working. Ralph: Thank you for all our suggestions and I tried to follow the last set, and failed (later found I'd made a spelling mistake!!). I did manage to recover all my data files to the separate disk but did not need them in the end (now stored safely, just in case). After many attempts to upgrade I've come to the conclusion that the upgrade DVD is faulty, as that always failed. During one recovery attempt (back to 19.3) it repartitioned the SDA disc and added a EFI partition, as well as the OS (19.3). It replaced sda1 & 2 with the efi (fat32) and OS partition(ext4), it deleted the Swop but did not touch sda3 or 4. The efi/OD partitions ended up at sad5&6, no sda2 or swop. Don't understand why or how but it all works! I'll have to wait till I can get a 'proper' Mint 20 disc before trying again. Must have tried 6 or 7 times to upgrade hence the thinking it's a DVD copy problem as at no time did it get passed the loss of efi problem; even after having a separate efi/fat32 partition. Thanks again for all the help, it kept me trying! :-) -- C A Wills -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
> Why don’t you all just create your own Better to stand on the shoulders of others. ‘The lyf so short, the craft so long to lerne’ ― Chaucer. -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
I have noticed that there is always something breaking within any distro. Why don’t you all just create your own and be done with all those that say.. read the fucking manual On 5 Sep 2020, 13:13 +0100, Ralph Corderoy , wrote: > Hi Clive, > > > ...as the laptop has 4 partitions: > > sda1=OS (Mint) system files > > sda2=swop > > sda3=Home > > sda4=odds area > ... > > From a 'live disk' would like to copy sda3 to another disk (USB 160Gb > > with 2 partitions - sdb1=NTFS and sdb2= Ext4 140Gb) > > /dev/sda3 was about 286G big, with 102 GiB used, so the contents should > fit in that 140 Gb USB. > > > How can I copy sda3 to sdb2 using a 'live disk' conserving all > > properties. > > I don't know of a GUI program so command-line it is! > > Before we start, it's worth making sure the USB drive is plugged into > the fastest USB port, if you have more than one and they're different > speeds. This is normally coloured blue. > > The live disk might have automatically mounted the sda3 and sdb2 > devices. To ensure they're not mounted run > > sudo umount /dev/sda3 /dev/sdb2 > > Now we're going to mount them where we want them to appear. > > Make a temporary directory to work in, and change the working directory > to it. > > mkdir /tmp/disk-copy > cd /tmp/disk-copy > > Make two directories, one for each of the filesystems we want to mount. > > mkdir source destination > > Mount the filesystems onto those directories. Make sure you get them > the right way around! > > sudo mount -o ro /dev/sda3 source > sudo mount /dev/sdb2 destination > > A peek inside should show recognisable contents. > > ls source destination > > Now copy the contents of the source directory into the destination > directory. The trailing slash on each of those directory names is > vital. (This is the rsync(1) program which Andrew mentioned.) > > sudo env RSYNC_ICONV=- rsync -PacivHAXxSsy source/ destination/ > > This will take a long time. It will print how it's going which may slow > things down a little more, but the USB will probably be the bottleneck > and I'm assuming you'd like the reassurrance it's doing something. > > That's assuming you want source/clive copied to destination/clive. If > you want it in a subdirectory on destination then ensure it exists and > alter the rsync command's destination argument. > > mkdir destination/home-2020-09-05 > sudo env RSYNC_ICONV=- rsync -PacivHAXxSsy source/ > destination/home-2020-09-05/ > > Again, note the trailing slash! > > Now, when the rsync finishes a copy should exist. But USB disk > interfaces can be contrary so I recommend double-checking by unmounting > the destination so Linux forgets all about its contents. > > sudo umount destination > > Unplugging the USB drive, presumably cutting its power supply. > Plugging it back in again, then mounting it, > > sudo mount /dev/sdb2 destination > > and then running the exact same copy command, whatever you ended up > with, a second time. Note, the cursor up and down keys move through > your recent history of shell commands to save typing it all again. > > sudo env RSYNC_ICONV=- rsync -PacivHAXxSsy source/ destination/ > > It won't take so long this time because reading is quicker than writing > and it will see the destination already has each file which it will read > all the way through generating a checksum as it goes which it then > compares to the source file's checksum. The checksums should match if > it's a good copy so it won't print anything for this file and move onto > the next. > > If the checksums differ then it will print a line as it updates the > copy. So after a long time of hopefully not printing anything, as that > shows the first copy was good, it will finish with a couple of summary > lines. > > You can then unmount both devices. > > sudo umount source destination > > Haven't tried any of that so if it deviates from what you expect then > probably best to halt and ask the list. You may want to save bits of > text from the live disk. A ‘pastebin’ is handy. > https://pastebin.centos.org/ is one example. Just paste your text into > the big box on the form, and bump the ‘Delete After’ up to ‘1 Day’ so > you've time to make use of it. On submitting the form it gives you a > URL like https://paste.centos.org/view/6de8067c which can be noted down > and re-entered on a different system to retrieve the text. > > You could paste the text of this email into it so you can copy-and-paste > out of the pastebin when booted from the live disk to replace the chance > of typos with pasteoes. :-) > > -- > Cheers, Ralph. > > -- > Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 > Check to whom you are replying > Meetings, mailing list, IRC, ... http://dorset.lug.org.uk > New thread, don't hijack: mailto:dorset@mailman.lug.org.uk -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
Hi Clive, > ...as the laptop has 4 partitions: > sda1=OS (Mint) system files > sda2=swop > sda3=Home > sda4=odds area ... > From a 'live disk' would like to copy sda3 to another disk (USB 160Gb > with 2 partitions - sdb1=NTFS and sdb2= Ext4 140Gb) /dev/sda3 was about 286G big, with 102 GiB used, so the contents should fit in that 140 Gb USB. > How can I copy sda3 to sdb2 using a 'live disk' conserving all > properties. I don't know of a GUI program so command-line it is! Before we start, it's worth making sure the USB drive is plugged into the fastest USB port, if you have more than one and they're different speeds. This is normally coloured blue. The live disk might have automatically mounted the sda3 and sdb2 devices. To ensure they're not mounted run sudo umount /dev/sda3 /dev/sdb2 Now we're going to mount them where we want them to appear. Make a temporary directory to work in, and change the working directory to it. mkdir /tmp/disk-copy cd/tmp/disk-copy Make two directories, one for each of the filesystems we want to mount. mkdir source destination Mount the filesystems onto those directories. Make sure you get them the right way around! sudo mount -o ro /dev/sda3 source sudo mount /dev/sdb2 destination A peek inside should show recognisable contents. ls source destination Now copy the contents of the source directory into the destination directory. The trailing slash on each of those directory names is vital. (This is the rsync(1) program which Andrew mentioned.) sudo env RSYNC_ICONV=- rsync -PacivHAXxSsy source/ destination/ This will take a long time. It will print how it's going which may slow things down a little more, but the USB will probably be the bottleneck and I'm assuming you'd like the reassurrance it's doing something. That's assuming you want source/clive copied to destination/clive. If you want it in a subdirectory on destination then ensure it exists and alter the rsync command's destination argument. mkdir destination/home-2020-09-05 sudo env RSYNC_ICONV=- rsync -PacivHAXxSsy source/ destination/home-2020-09-05/ Again, note the trailing slash! Now, when the rsync finishes a copy should exist. But USB disk interfaces can be contrary so I recommend double-checking by unmounting the destination so Linux forgets all about its contents. sudo umount destination Unplugging the USB drive, presumably cutting its power supply. Plugging it back in again, then mounting it, sudo mount /dev/sdb2 destination and then running the exact same copy command, whatever you ended up with, a second time. Note, the cursor up and down keys move through your recent history of shell commands to save typing it all again. sudo env RSYNC_ICONV=- rsync -PacivHAXxSsy source/ destination/ It won't take so long this time because reading is quicker than writing and it will see the destination already has each file which it will read all the way through generating a checksum as it goes which it then compares to the source file's checksum. The checksums should match if it's a good copy so it won't print anything for this file and move onto the next. If the checksums differ then it will print a line as it updates the copy. So after a long time of hopefully not printing anything, as that shows the first copy was good, it will finish with a couple of summary lines. You can then unmount both devices. sudo umount source destination Haven't tried any of that so if it deviates from what you expect then probably best to halt and ask the list. You may want to save bits of text from the live disk. A ‘pastebin’ is handy. https://pastebin.centos.org/ is one example. Just paste your text into the big box on the form, and bump the ‘Delete After’ up to ‘1 Day’ so you've time to make use of it. On submitting the form it gives you a URL like https://paste.centos.org/view/6de8067c which can be noted down and re-entered on a different system to retrieve the text. You could paste the text of this email into it so you can copy-and-paste out of the pastebin when booted from the live disk to replace the chance of typos with pasteoes. :-) -- Cheers, Ralph. -- Next meeting: Online, Jitsi, Tuesday, 2020-10-06 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
On 02/09/2020 17:19, C Wills wrote: From a 'live disk' would like to copy sda3 to another disk (USB 160Gb with 2 partitions - sdb1=NTFS and sdb2= Ext4 140Gb) before trying to re-install and ignoring the warnings!. BUT I can only copy sda3 to any /other/ location (sdb2) by becoming 'Root' and when I've done this before I've ended up with all Directories and files being 'Owned' by Root and lost 'my' ownership. How can I copy sda3 to sdb2 using a 'live disk' conserving all properties.. All programs I've got don't seems to allow this. I'm normally a GUI user not terminal user unless I have a command to copy exactly, any help please? Both cp and rsync have the option --archive (or -a) which sets a few other options, including preserving ownership. They both also have a --verbose (or -v) option, which you might want to use as well to see what's going on. cp -av /from/ /to/ -- Andrew. -- Next meeting: Online, Jitsi, Tuesday, 2020-09-01 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
Re: [Dorset] Loss of OS during upgrade
On 02/09/2020 17:19, C Wills wrote: > Interesting meeting last night especially about the keyboard settings, > found several things about the PC keyboard I was using and it's > additional keys. > > Sorry this is a long email. > Now to my problem: While trying to upgrade from Mint 19.3 to Mint 20 > problems arose which have stop me using the Laptop (I'm on our PC for > now). > Long story so cutting it short. During the upgrade I used the 'other' > option as the laptop has 4 partitions:- sda1= OS (Mint) system files, > sda2=swop, sda3=Home, sda4=odds area. > Previous upgrades I've reformatted sda1 and left all other 'as is' and > it's worked every time (till now). > Now sda1 is empty (no files to be seen), all others still OK. > Fault now says ' no UEFI file to be found' (or similar words) > With Ralphs help we have established that the BIOS does support UEFI > and it uses MBR(?) for Grub2. > > Can now only use a Live Disk to operate the Laptop. Gparted shows > partitions and confirms OS is empty. > > From a 'live disk' would like to copy sda3 to another disk (USB 160Gb > with 2 partitions - sdb1=NTFS and sdb2= Ext4 140Gb) before trying to > re-install and ignoring the warnings!. > BUT > I can only copy sda3 to any /other/ location (sdb2) by becoming 'Root' > and when I've done this before I've ended up with all Directories and > files being 'Owned' by Root and lost 'my' ownership. > > How can I copy sda3 to sdb2 using a 'live disk' conserving all > properties.. All programs I've got don't seems to allow this. I'm > normally a GUI user not terminal user unless I have a command to copy > exactly, any help please? > > PS Laptop works fine from the live DVD ISO's of both Mint versions. > Hello Clive, Do you have a backup you can restore before attempting to upgrade again? This would probably be the easiest option. I would also recommend using the "mintupgrade" tool, as suggested by the Mint team at https://linuxmint-user-guide.readthedocs.io/en/latest/upgrade-to-mint-20.html A long shot, but did you happen to have the 32-bit version of Linux Mint 19.3 installed? Hamish signature.asc Description: OpenPGP digital signature -- Next meeting: Online, Jitsi, Tuesday, 2020-09-01 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
[Dorset] Loss of OS during upgrade
Interesting meeting last night especially about the keyboard settings, found several things about the PC keyboard I was using and it's additional keys. Sorry this is a long email. Now to my problem: While trying to upgrade from Mint 19.3 to Mint 20 problems arose which have stop me using the Laptop (I'm on our PC for now). Long story so cutting it short. During the upgrade I used the 'other' option as the laptop has 4 partitions:- sda1= OS (Mint) system files, sda2=swop, sda3=Home, sda4=odds area. Previous upgrades I've reformatted sda1 and left all other 'as is' and it's worked every time (till now). Now sda1 is empty (no files to be seen), all others still OK. Fault now says ' no UEFI file to be found' (or similar words) With Ralphs help we have established that the BIOS does support UEFI and it uses MBR(?) for Grub2. Can now only use a Live Disk to operate the Laptop. Gparted shows partitions and confirms OS is empty. From a 'live disk' would like to copy sda3 to another disk (USB 160Gb with 2 partitions - sdb1=NTFS and sdb2= Ext4 140Gb) before trying to re-install and ignoring the warnings!. BUT I can only copy sda3 to any /other/ location (sdb2) by becoming 'Root' and when I've done this before I've ended up with all Directories and files being 'Owned' by Root and lost 'my' ownership. How can I copy sda3 to sdb2 using a 'live disk' conserving all properties.. All programs I've got don't seems to allow this. I'm normally a GUI user not terminal user unless I have a command to copy exactly, any help please? PS Laptop works fine from the live DVD ISO's of both Mint versions. -- *Clive Wills* /Supporting Linux & Open Source/ ** -- Next meeting: Online, Jitsi, Tuesday, 2020-09-01 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
