[opensuse] Does gparted move file systems?
I have # fdisk -l /dev/sda WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion. Disk /dev/sda: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: gpt # Start End Size Type Name 1 34 3906250 1.9G EFI System primary 2 3907584 15624191 5.6G Microsoft basic primary 3 15624192 1953523711 924.1G Linux LVM primary Partition #1 is actually /boot /dev/sda1 on /boot type ext2 (rw,relatime,noacl) # df /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 1922400 341800 1482948 19% /boot What I'd like to do is shrink and move partition#1 so that it begins on block 8192. What I need assurance of is that gparted will preserve the file system when I do that so I still have an intact file system. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On June 27, 2015 7:23:02 AM PDT, Anton Aylward <opensuse@antonaylward.com> wrote:
I have
# fdisk -l /dev/sda WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: gpt
# Start End Size Type Name 1 34 3906250 1.9G EFI System primary 2 3907584 15624191 5.6G Microsoft basic primary 3 15624192 1953523711 924.1G Linux LVM primary
Partition #1 is actually /boot
/dev/sda1 on /boot type ext2 (rw,relatime,noacl)
# df /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 1922400 341800 1482948 19% /boot
What I'd like to do is shrink and move partition#1 so that it begins on block 8192.
What I need assurance of is that gparted will preserve the file system when I do that so I still have an intact file system.
I have moved entire partitions , lengthen partitions, shrunk partitions, all without having lost anything. I've used it on just about every type of file system except BTRFS. It's always a very nerve wracking adventure. I always take backups. It's never failed me. I always download the newest gpartd Bootable disk rather than using what came with opensuse. Just a Habit. Assurance you ask? Good chance of success with the move. Slim to zero chance of anyone giving you assurance. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sat, 27 Jun 2015 10:23:02 -0400 Anton Aylward <opensuse@antonaylward.com> пишет:
I have
# fdisk -l /dev/sda WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk label type: gpt
# Start End Size Type Name 1 34 3906250 1.9G EFI System primary 2 3907584 15624191 5.6G Microsoft basic primary 3 15624192 1953523711 924.1G Linux LVM primary
Partition #1 is actually /boot
/dev/sda1 on /boot type ext2 (rw,relatime,noacl)
# df /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 1922400 341800 1482948 19% /boot
What I'd like to do is shrink and move partition#1 so that it begins on block 8192.
What bootloader are you using and where is it installed?
What I need assurance of is that gparted will preserve the file system when I do that so I still have an intact file system.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-27 16:23, Anton Aylward wrote:
What I'd like to do is shrink and move partition#1 so that it begins on block 8192.
With such a small size, I wouldn't move. I would back it up, entirely, delete partition, recreate, format, copy back the files, and possibly, reinstall grub. Much faster and safer. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWO4GsACgkQja8UbcUWM1zp4AD/dG9y8si+OhBqDZfEcyI3F071 Suq16/KjwG+iaxQUmiEA/jtjK8vQdsfdR1289nYZShl7LsYxR8Ojlj/VkfHuDU8I =aU9c -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday, June 27, 2015 10:23:02 AM Anton Aylward wrote:
What I'd like to do is shrink and move partition#1 so that it begins on block 8192.
I recently did something similar on laptop (though non-EFI). The first partition was "/boot" (taken over from the Dell OEM partition). I wanted to enlarge it, so I tried to move everything down a little keeping the same sizes. Note that I had deleted all other linux partitions, prior to installing 13.2, so this was mainly a Windows move. Windows (Win7) complained, though it claimed to have repaired the problems. I then tried plan B: I restored the Windows partitions from an Acronis image backup that I made before starting. Windows was much happier. In your case, with a FAT partition, you are less likely to have problems. But take a backup first. In a reply, Carlos wrote:
With such a small size, I wouldn't move. I would back it up, entirely, delete partition, recreate, format, copy back the files, and possibly, reinstall grub.
Much faster and safer.
The problem is that UEFI booting menu is based on partition and file system UUID, and a backup-recreate-restore will change those. So the boot entries probably need to be recreated. My choice would be the move/shrink, with a re-create/restore alternative if something goes wrong. In case you have to regenerate the MVRAM entries for booting, it is possibly enough to get opensuse working. Then run grub2-mkconfig to regenerate the grub2-efi boot menu, which should have an entry to boot Windows. When you next boot Windows it will fix its own boot entry (and make that the default for booting). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/27/2015 02:34 PM, Neil Rickert wrote:
In your case, with a FAT partition, you are less likely to have problems.
Why do you think I have a FAT partition? I recall in my original message saying /dev/sda1 on /boot type ext2 (rw,relatime,noacl) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 27 Jun 2015 21:07, Anton Aylward <opensuse@...> wrote:
On 06/27/2015 02:34 PM, Neil Rickert wrote:
In your case, with a FAT partition, you are less likely to have problems.
Why do you think I have a FAT partition? I recall in my original message saying
/dev/sda1 on /boot type ext2 (rw,relatime,noacl)
(U)EFI boot partions are (V)FAT32 formatted. Just the partition-type-id is different from standard FAT. And yes, in case of EFI boot partions, shrink + move is much easier than delete and recreate. Stupid uuid. This reflects some ugly lessions from RL. Leaving an empty space (multiple of 4k) up to a full 1024kB = 1MB makes sense. That way no bootloader will shredder the first partition. (Also happend) - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/27/2015 03:20 PM, Yamaban wrote:
On Sat, 27 Jun 2015 21:07, Anton Aylward <opensuse@...> wrote:
On 06/27/2015 02:34 PM, Neil Rickert wrote:
In your case, with a FAT partition, you are less likely to have problems.
Why do you think I have a FAT partition? I recall in my original message saying
/dev/sda1 on /boot type ext2 (rw,relatime,noacl)
(U)EFI boot partions are (V)FAT32 formatted. Just the partition-type-id is different from standard FAT.
I'm quite certain that my partition containing /boot is ext2 formatted. # blkid /dev/sda1 /dev/sda1: LABEL="BOOT" UUID="f7e3ef67-a45c-4562-b404-5c48a2e3d2f2" TYPE="ext2" PTTYPE="dos" PARTLABEL="primary" PARTUUID="cebb3ec5-8cfe-4272-954e-04552ca5305c" Things I don't know. * why, even though it *IS* labelled "BOOT" its not so for "fdisk -l" * The difference betwewnn a UUID and PARTUUID * Why the PTTYPE says "dos" when this a "gpt" device as reported by fdisk -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 27 Jun 2015 21:55, Anton Aylward wrote:
On 06/27/2015 03:20 PM, Yamaban wrote:
On Sat, 27 Jun 2015 21:07, Anton Aylward wrote:
On 06/27/2015 02:34 PM, Neil Rickert wrote:
In your case, with a FAT partition, you are less likely to have problems.
Why do you think I have a FAT partition? I recall in my original message saying
/dev/sda1 on /boot type ext2 (rw,relatime,noacl)
(U)EFI boot partions are (V)FAT32 formatted. Just the partition-type-id is different from standard FAT.
I'm quite certain that my partition containing /boot is ext2 formatted.
# blkid /dev/sda1 /dev/sda1: LABEL="BOOT" UUID="f7e3ef67-a45c-4562-b404-5c48a2e3d2f2" TYPE="ext2" PTTYPE="dos" PARTLABEL="primary" PARTUUID="cebb3ec5-8cfe-4272-954e-04552ca5305c"
Things I don't know.
* why, even though it *IS* labelled "BOOT" its not so for "fdisk -l"
The label is stored inside the filesystem, fdisk does not look inside the content of the partition, and thus can not see the label.
* The difference betwewnn a UUID and PARTUUID
The PARTUUID is given/assigned by fdisk/parted at the time the partition is created. The UUID is the filesystem uuid, and is given/assigned by mkfs.xyz at the time the partition is formatted.
* Why the PTTYPE says "dos" when this a "gpt" device as reported by fdisk
PTTYPE is partition table type. Available are: * MBR only, old style, called "dos", limits are known (2TB) * GPT only, new style, called "gpt", some tools can't handle it. * GPT with "protective" MBR, this COULD be misdetected as mbr only if less than 15 partions are in use, and the tools aren't careful. Still, the sentence about space BEFORE the first partition still applies, no matter what type the first partition filesystem is. This one megabyte is NOT wasted. Just one bootloader fuck-up, and you will be happy about that space. (and have a still working first FS) - Yamaban. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-27 21:55, Anton Aylward wrote:
* why, even though it *IS* labelled "BOOT" its not so for "fdisk -l"
Because in fdisk you can edit the type; this is different than the label or the filesystem type. Linux does not use the partition type, it is informative. Those types were limited in MBR partitions to 255 types (a byte). Linux used types 82 and 83.
* The difference betwewnn a UUID and PARTUUID
The former is stored inside the partition. The later is stored in the partition table, /if/ it is GPT. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWPFP8ACgkQja8UbcUWM1xykQD+Ody9oiVIoOFkRoCs/GdKLky3 RuqHDkTpocQ5WdHNHngA/jn6eEPSpLC7pPUETqV2uWaW89gxiYYiqu35M/hJPtxe =DXzm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-27 21:07, Anton Aylward wrote:
On 06/27/2015 02:34 PM, Neil Rickert wrote:
In your case, with a FAT partition, you are less likely to have problems.
Why do you think I have a FAT partition?
Because in the partition layout it is marked as "EFI", and those are always FAT. It is the wrong type, your fault :-p Which also leads people in confusion giving you advice about UEFI entries, too. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWPE5sACgkQja8UbcUWM1y7rAD9E/zzB09ecxuN87Bu8s/i/9Tj G0b+eroiWn8flkze4q0A/3q9irYTASNtLlL8M+lGF5kl4AfjFLlXNqJpgxLnd3+X =NLY3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday, June 27, 2015 03:07:02 PM Anton Aylward wrote:
On 06/27/2015 02:34 PM, Neil Rickert wrote:
In your case, with a FAT partition, you are less likely to have problems.
Why do you think I have a FAT partition? I recall in my original message saying
That's because your output listed it as an EFI system partition. In your case, that's an installer bug (bug 934309). I suggest that you use "gdisk" to change the partition type code from EF00 to 8300. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-27 20:34, Neil Rickert wrote:
In a reply, Carlos wrote:
With such a small size, I wouldn't move. I would back it up, entirely, delete partition, recreate, format, copy back the files, and possibly, reinstall grub.
Much faster and safer.
The problem is that UEFI booting menu is based on partition and file system UUID, and a backup-recreate-restore will change those. So the boot entries probably need to be recreated.
Ok, right. There are two ways to sort that out: edit fstab and grub to reflect the new uuids (if used; I use labels instead). Or, edit the partition uuid to be the same as it was. It can be changed. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF0EAREIAAYFAlWPGFcACgkQja8UbcUWM1xvswD44ytqiOpzUBC7HkbapMa2GJsN hIgjCGA8ndi9+STEJQD/U0dFN34CUU1dwp1pAOff0/xFA6rCrAAVyBpU5IMkA9U= =UDBC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 В Sat, 27 Jun 2015 23:40:39 +0200 "Carlos E. R." <robin.listas@telefonica.net> пишет:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-06-27 20:34, Neil Rickert wrote:
In a reply, Carlos wrote:
With such a small size, I wouldn't move. I would back it up, entirely, delete partition, recreate, format, copy back the files, and possibly, reinstall grub.
Much faster and safer.
The problem is that UEFI booting menu is based on partition and file system UUID, and a backup-recreate-restore will change those. So the boot entries probably need to be recreated.
Ok, right.
There are two ways to sort that out: edit fstab and grub to reflect the new uuids (if used; I use labels instead). Or, edit the partition uuid to be the same as it was. It can be changed.
Neil spoke about UEFI menu, not fstab or grub. Partition signature is part of device path used by UEFI to access executable; in case of GPT partition signature is unique partition GUID that is expected to be unique for every single partition ever created (not to be confused with partition *type* GUID). Recreating partition changes GUID. It is possible to rewrite it using e.g. gdisk "c" command to restore to previous value - if you saved it before :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWPkaAACgkQR6LMutpd94w/wQCfQXTNhxcv54/GFfWG7q5coEvv KygAn1Vfnp+qUpjg98U76FN97G6fOCmF =dReQ -----END PGP SIGNATURE----- N�����r��y隊Z)z{.�ﮞ˛���m�)z{.��+�: �{Zr�az�'z��j)h���Ǿ� ޮ�^�ˬz��
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-28 08:18, Andrei Borzenkov wrote:
В Sat, 27 Jun 2015 23:40:39 +0200 "Carlos E. R." <> пишет:
Ok, right.
There are two ways to sort that out: edit fstab and grub to reflect the new uuids (if used; I use labels instead). Or, edit the partition uuid to be the same as it was. It can be changed.
Neil spoke about UEFI menu, not fstab or grub.
But not Anton, the OP. He has no UEFI system :-) He has a GPT partition table, yes, and there is a partition marked as EFI, but wrongly. It is ext2, mounted as /boot. But no UEFI. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWPzFUACgkQja8UbcUWM1wRzwD/WOprDgxI/Cdw/Pq/I/IvQVOA Bh3svXwQ7eksvoacEywBAJsSPcK+ZEif73NWMC+7x9g5EVw9TYiZzoZC5n40OGJx =G80P -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/28/2015 06:28 AM, Carlos E. R. wrote:
On 2015-06-28 08:18, Andrei Borzenkov wrote:
В Sat, 27 Jun 2015 23:40:39 +0200 "Carlos E. R." <> пишет:
Ok, right.
There are two ways to sort that out: edit fstab and grub to reflect the new uuids (if used; I use labels instead). Or, edit the partition uuid to be the same as it was. It can be changed.
Neil spoke about UEFI menu, not fstab or grub.
But not Anton, the OP. He has no UEFI system :-)
He has a GPT partition table, yes, and there is a partition marked as EFI, but wrongly. It is ext2, mounted as /boot. But no UEFI.
There are many entries in this thread that have me confused, so I am overwhelmingly glad you've got back to "look to the evidence". The "wrongly" has it and that has been a source of my confusion. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-06-28 14:56, Anton Aylward wrote:
On 06/28/2015 06:28 AM, Carlos E. R. wrote:
He has a GPT partition table, yes, and there is a partition marked as EFI, but wrongly. It is ext2, mounted as /boot. But no UEFI.
There are many entries in this thread that have me confused, so I am overwhelmingly glad you've got back to "look to the evidence".
The "wrongly" has it and that has been a source of my confusion.
That EFI mark is apparently a known installation bug. Neil posted the number. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWP8pIACgkQja8UbcUWM1yOogD9F2AnWF/xEp/thtuMAVNF+Q9L DvyTCz3meKA1z2SpXJcA/iTgt7Wf8Ph8gfea0za9WHHPqUaZMcVISsBHTpmn4XNZ =/ONn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
John Andersen -
Neil Rickert -
Yamaban