Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #275135 > unrolled thread
| Started by | Hans <hans.ullrich@loop.de> |
|---|---|
| First post | 2024-12-02 17:50 +0100 |
| Last post | 2024-12-03 05:50 +0100 |
| Articles | 20 on this page of 108 — 28 participants |
Back to article view | Back to linux.debian.user
From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 17:50 +0100
Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-02 18:00 +0100
Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 18:10 +0100
Re: From SSD to NVME Bret Busby <bret@busby.net> - 2024-12-02 18:50 +0100
Re: *****SPAM***** Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 20:30 +0100
Re: From SSD to NVME Andy Smith <andy@strugglers.net> - 2024-12-02 21:30 +0100
Re: From SSD to NVME basti <mailinglist@unix-solution.de> - 2024-12-02 19:40 +0100
Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 20:20 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 00:20 +0100
Re: From SSD to NVME eben@gmx.us - 2024-12-05 15:50 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 16:10 +0100
Re: From SSD to NVME eben@gmx.us - 2024-12-05 17:00 +0100
Re: From SSD to NVME Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-05 17:20 +0100
Re: From SSD to NVME Dan Ritter <dsr@randomstring.org> - 2024-12-05 18:00 +0100
Re: From SSD to NVME Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-05 18:20 +0100
Re: From SSD to NVME Chris Green <cl@isbd.net> - 2024-12-05 18:50 +0100
Re: From SSD to NVME Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-05 20:50 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 21:00 +0100
Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-05 20:30 +0100
MBR to GPT + UEFI (was: From SSD to NVME) Jeffrey Walton <noloader@gmail.com> - 2024-12-05 20:40 +0100
Re: From SSD to NVME "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-05 21:10 +0100
Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-05 21:30 +0100
Re: From SSD to NVME David Wright <deblis@lionunicorn.co.uk> - 2024-12-05 22:20 +0100
Re: From SSD to NVME "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-05 23:10 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 23:40 +0100
Re: From SSD to NVME Charles Curley <charlescurley@charlescurley.com> - 2024-12-05 23:40 +0100
Re: From SSD to NVME "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-06 19:20 +0100
Re: From SSD to NVME Charles Curley <charlescurley@charlescurley.com> - 2024-12-06 20:00 +0100
Re: From SSD to NVME David Wright <deblis@lionunicorn.co.uk> - 2024-12-06 01:50 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 21:20 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-05 22:20 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-05 22:30 +0100
Re: From SSD to NVME Nicolas George <george@nsup.org> - 2024-12-05 22:30 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-05 22:40 +0100
Re: From SSD to NVME Nicolas George <george@nsup.org> - 2024-12-05 23:10 +0100
Re: From SSD to NVME David Wright <deblis@lionunicorn.co.uk> - 2024-12-05 22:20 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 19:10 +0100
Re: From SSD to NVME eben@gmx.us - 2024-12-05 22:10 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 23:30 +0100
Re: From SSD to NVME eben@gmx.us - 2024-12-06 00:10 +0100
Re: From SSD to NVME Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-12-11 09:00 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-11 14:20 +0100
Re: From SSD to NVME Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-12-12 22:20 +0100
Re: From SSD to NVME Dan Ritter <dsr@randomstring.org> - 2024-12-11 14:30 +0100
Re: From SSD to NVME Anssi Saari <anssi.saari@debian-user.mail.kapsi.fi> - 2024-12-12 20:20 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-02 19:50 +0100
Re: From SSD to NVME Bruno Schneider <boschneider@gmail.com> - 2024-12-02 19:50 +0100
Re: From SSD to NVME Erwan David <erwan@rail.eu.org> - 2024-12-02 20:20 +0100
Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 20:30 +0100
Re: From SSD to NVME Andy Smith <andy@strugglers.net> - 2024-12-02 21:20 +0100
Re: From SSD to NVME Hans <hans.ullrich@loop.de> - 2024-12-02 21:50 +0100
Re: From SSD to NVME Andy Smith <andy@strugglers.net> - 2024-12-02 22:30 +0100
Re: From SSD to NVME <tomas@tuxteam.de> - 2024-12-03 06:40 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-02 21:40 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 16:50 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-05 18:30 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 19:20 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-05 20:20 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 21:00 +0100
Re: From SSD to NVME Felix Miata <mrmazda@earthlink.net> - 2024-12-05 22:20 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 23:00 +0100
Re: From SSD to NVME - oops! Felix Miata <mrmazda@stanis.net> - 2024-12-06 00:00 +0100
Re: From SSD to NVME - oops! Max Nikulin <manikulin@gmail.com> - 2024-12-06 04:40 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-06 00:00 +0100
Re: From SSD to NVME Jeffrey Walton <noloader@gmail.com> - 2024-12-06 04:20 +0100
Re: From SSD to NVME "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-02 20:50 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 03:00 +0100
Re: From SSD to NVME "Andrew M.A. Cater" <amacater@einval.com> - 2024-12-03 10:00 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 12:10 +0100
Re: From SSD to NVME <tomas@tuxteam.de> - 2024-12-03 12:40 +0100
Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-03 13:20 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 13:40 +0100
Re: From SSD to NVME Nicolas George <george@nsup.org> - 2024-12-03 14:00 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 14:10 +0100
Re: From SSD to NVME Nicolas George <george@nsup.org> - 2024-12-03 14:30 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 15:30 +0100
Re: From SSD to NVME Nicolas George <george@nsup.org> - 2024-12-03 16:00 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 15:50 +0100
Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-03 20:40 +0100
Re: From SSD to NVME Andy Smith <andy@strugglers.net> - 2024-12-03 20:50 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 21:40 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 22:20 +0100
Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-03 22:30 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 23:00 +0100
Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-03 23:10 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 23:20 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 22:40 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 23:00 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 23:20 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 23:30 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 23:50 +0100
Re: From SSD to NVME Timothy M Butterworth <timothy.m.butterworth@gmail.com> - 2024-12-04 02:40 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-04 05:20 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-04 13:10 +0100
Re: From SSD to NVME Joe <joe@jretrading.com> - 2024-12-04 16:00 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-04 19:00 +0100
Re: From SSD to NVME Jeffrey Walton <noloader@gmail.com> - 2024-12-04 07:20 +0100
Re: From SSD to NVME gene heskett <gheskett@shentel.net> - 2024-12-05 01:10 +0100
Re: From SSD to NVME Greg Wooledge <greg@wooledge.org> - 2024-12-05 01:40 +0100
Re: From SSD to NVME gene heskett <gheskett@shentel.net> - 2024-12-05 03:00 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 15:30 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 15:50 +0100
Re: From SSD to NVME Felix Miata <mrmazda@stanis.net> - 2024-12-03 16:10 +0100
Re: From SSD to NVME pocket@homemail.com - 2024-12-03 16:30 +0100
Re: From SSD to NVME Michael Stone <mstone@debian.org> - 2024-12-05 00:00 +0100
Re: From SSD to NVME Steve McIntyre <steve@einval.com> - 2024-12-03 22:20 +0100
Re: From SSD to NVME Max Nikulin <manikulin@gmail.com> - 2024-12-03 04:10 +0100
Re: From SSD to NVME David Christensen <dpchrist@holgerdanske.com> - 2024-12-03 05:50 +0100
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | "Andrew M.A. Cater" <amacater@einval.com> |
|---|---|
| Date | 2024-12-05 21:10 +0100 |
| Message-ID | <JQqkF-dZoI-1@gated-at.bofh.it> |
| In reply to | #275297 |
On Thu, Dec 05, 2024 at 08:24:05PM +0100, Hans wrote: > Hi folks, > > as promised I send you my experiences with cloning to NVME. > > So, today I got my new notebook. As I never used UEFI, I disabled UEFI in BIOS > (my first mistake!), then cloned everything to the new drive. > > Firts reboot worked well, no problems. But then I realized, that if you want > NVME mode, you MUST use native UEFI in BIOS settings. > > However, doing so, neither Debian nor Windows will boot. Of course: There is > no EFI partition on my harddrive, as I never needed one (still). > If you still have the drive you cloned from set it aside. If you need dual boot, set UEFi up as the mode to boot into in firmware. Use the Microsoft tools to create a Windows .iso file Install Windows from a .iso file. Use Windows drive tools to shrink Windows on the drive to make some space. Then use something like gparted to move the Windows to the end of the drive. Install Debian on the first half of the drive: allow os-prober to find the Windows partition. Then you've got dual boot. This is the routine I've been through a couple of times with a refurbished laptop where the vendor has installed Windows in legacy MBR mode. Then copy your data across from the drive you set aside. It's a huge pain but it's actually worth it IMHO. All the very best, as ever, Andy (amacater@debian.org) > Now I am hasseling with the drive, as I want NVME-mode of course, because it > is faster. And of course, I do not want to reinstall everything! > > I saw some documentations, how to get EFI on the drive, but it looks, you need > a seperate partition with FAT to get EFI on, right? > > However, I saw also the possibility to get EFI on my seperate /boot partition. > > What can I do? I would like to keep the existing partitions. However, I could > shrink them. At the moment, my drive looks at this: > > primary partition Windows-boot ntfs > primary partition Windows ntfs > primary partition /boot /dev/sda3 ext4 > extended partition /dev/sda4 > logical partition /dev/sda5 swap > logical partition /dev/sda6 / ext4 > logical partition /dev/sda7 encrypted home > logical partition /dev/sda8 encrypted usr > logical partition /dev/sda9 encrypted var > logical partition /dev/sda10 encrypted data > > So I could shrinken some partitions and create a new logical one. > > Other option would be, delete "swap" partition and make a new "EFI" partition. > > What do you think, might be the best way? > > Some better ideas? > > Thanks for reading this. > > Best regards > > Hans > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Hans <hans.ullrich@loop.de> |
|---|---|
| Date | 2024-12-05 21:30 +0100 |
| Message-ID | <JQqE1-dZvv-1@gated-at.bofh.it> |
| In reply to | #275302 |
Aargh! I just discovered, the seller did not send the notebook as ordered. I ordered with NVME and he sent with a SATA SSD (checked the SSD, and yes, it has TWO nicks, which should be one (for NVME). Tomorrow I will contact the seller and maybe return the notebook. However, I will keep you informed! There were a lot of verry good hints from you in the last days. This helped very much, especially for understanding. Can not enough say thank you for it. We will see, what happens the next days. Good, that I have a backup. Backup is always a good thing, always. Best Hans
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-12-05 22:20 +0100 |
| Message-ID | <JQrqp-e01a-1@gated-at.bofh.it> |
| In reply to | #275302 |
On Thu 05 Dec 2024 at 20:01:29 (+0000), Andrew M.A. Cater wrote: > Use the Microsoft tools to create a Windows .iso file > > Install Windows from a .iso file. Use Windows drive tools to shrink Windows > on the drive to make some space. > > Then use something like gparted to move the Windows to the end of the drive. Do you mean specifically the end of the drive, or just at one end or the other? Reasoning? Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | "Andrew M.A. Cater" <amacater@einval.com> |
|---|---|
| Date | 2024-12-05 23:10 +0100 |
| Message-ID | <JQscN-e0Bw-3@gated-at.bofh.it> |
| In reply to | #275309 |
On Thu, Dec 05, 2024 at 03:15:36PM -0600, David Wright wrote: > On Thu 05 Dec 2024 at 20:01:29 (+0000), Andrew M.A. Cater wrote: > > > Use the Microsoft tools to create a Windows .iso file > > > > Install Windows from a .iso file. Use Windows drive tools to shrink Windows > > on the drive to make some space. > > > > Then use something like gparted to move the Windows to the end of the drive. > > Do you mean specifically the end of the drive, > or just at one end or the other? Reasoning? > 1. Install Windows to the whole drive - it's what Windows does :) 2. Use gparted to move Windows (maybe apart from the EFI partition) to the end of the drive - move the blank space to the front of the drive after the EFI partiton. 3. Install Debian in the blank space. You might be able to do it all with one EFI partition. I think I found it easier to put Windows on first - because it's fussy, then install Debian but I may have done it both ways round in the past. Installing Windows second is definitely harder if I recall correctly. Andy (amacater@debian.org) > Cheers, > David. >
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2024-12-05 23:40 +0100 |
| Message-ID | <JQsFP-e0OD-3@gated-at.bofh.it> |
| In reply to | #275315 |
On Thu, Dec 05, 2024 at 10:03:52PM +0000, Andrew M.A. Cater wrote: >2. Use gparted to move Windows (maybe apart from the EFI partition) to the > end of the drive - move the blank space to the front of the drive after > the EFI partiton. I don't understand this step--why are you moving windows? Linux doesn't care where it is on the disk, so you should be able to just shrink the windows partition and continue from there. > You might be able to do it all with one EFI partition. You generally can have multiple boot entries, each with its own path to a bootloader (.efi file) on the EFI partition. In some cases a (buggy) system will only boot from /EFI/BOOT/BOOTX64.EFI but that's rare these days.
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2024-12-05 23:40 +0100 |
| Message-ID | <JQsFP-e0OD-5@gated-at.bofh.it> |
| In reply to | #275315 |
On Thu, 5 Dec 2024 22:03:52 +0000 "Andrew M.A. Cater" <amacater@einval.com> wrote: > 2. Use gparted to move Windows (maybe apart from the EFI partition) > to the end of the drive - move the blank space to the front of the > drive after the EFI partiton. OK, my curiosity is up. Why make a point of moving the Windows partition to the end of the drive? -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | "Andrew M.A. Cater" <amacater@einval.com> |
|---|---|
| Date | 2024-12-06 19:20 +0100 |
| Message-ID | <JQL5L-efFs-13@gated-at.bofh.it> |
| In reply to | #275319 |
On Thu, Dec 05, 2024 at 03:32:10PM -0700, Charles Curley wrote: > On Thu, 5 Dec 2024 22:03:52 +0000 > "Andrew M.A. Cater" <amacater@einval.com> wrote: > > > 2. Use gparted to move Windows (maybe apart from the EFI partition) > > to the end of the drive - move the blank space to the front of the > > drive after the EFI partiton. > > OK, my curiosity is up. Why make a point of moving the Windows > partition to the end of the drive? > I seem to remember that it's significantly difficult to forecast the likely size you'll want for a Windows system to allow room for updates. I sized it at something like 70G and moved it to the end of the drive so that it didn't try to expand further into what Windows might regard as free space. (70G does allow room for a few Windows updates, all of which are larger than you think). I then used Debian to fill the blank space and re-used Microsoft's EFI partition. It's a while ago: I think since then I've virtualised Windows 11 on a kvm VM. All best, as ever, Andy (amacater@debian.org) > -- > Does anybody read signatures any more? > > https://charlescurley.com > https://charlescurley.com/blog/ >
[toc] | [prev] | [next] | [standalone]
| From | Charles Curley <charlescurley@charlescurley.com> |
|---|---|
| Date | 2024-12-06 20:00 +0100 |
| Message-ID | <JQLIt-efT8-25@gated-at.bofh.it> |
| In reply to | #275348 |
On Fri, 6 Dec 2024 18:18:27 +0000 "Andrew M.A. Cater" <amacater@einval.com> wrote: > > > > OK, my curiosity is up. Why make a point of moving the Windows > > partition to the end of the drive? > > > > I seem to remember that it's significantly difficult to forecast the > likely size you'll want for a Windows system to allow room for > updates. I sized it at something like 70G and moved it to the end of > the drive so that it didn't try to expand further into what Windows > might regard as free space. (70G does allow room for a few Windows > updates, all of which are larger than you think). Ah, that suggests that you leave room on your mass storage for later expansion of either Windows, Linux, or something completely unexpected. I don't, so I didn't consider the possibility. Thank you. > > I then used Debian to fill the blank space and re-used Microsoft's > EFI partition. That's pretty much what I do. > > It's a while ago: I think since then I've virtualised Windows 11 on a > kvm VM. Ah. The only reason I keep Windows around is that some computers come with an infestation of it. As long as I've paid for a license and have the mass storage to spare I'll keep it around. Thank you. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-12-06 01:50 +0100 |
| Message-ID | <JQuHD-e2bk-7@gated-at.bofh.it> |
| In reply to | #275315 |
On Thu 05 Dec 2024 at 22:03:52 (+0000), Andrew M.A. Cater wrote: > On Thu, Dec 05, 2024 at 03:15:36PM -0600, David Wright wrote: > > On Thu 05 Dec 2024 at 20:01:29 (+0000), Andrew M.A. Cater wrote: > > > > > Use the Microsoft tools to create a Windows .iso file > > > > > > Install Windows from a .iso file. Use Windows drive tools to shrink Windows > > > on the drive to make some space. > > > > > > Then use something like gparted to move the Windows to the end of the drive. > > > > Do you mean specifically the end of the drive, > > or just at one end or the other? Reasoning? > > > > 1. Install Windows to the whole drive - it's what Windows does :) > 2. Use gparted to move Windows (maybe apart from the EFI partition) to the > end of the drive - move the blank space to the front of the drive after > the EFI partiton. > 3. Install Debian in the blank space. Last time I installed Debian on a Windows computer, I used W's own Disk Manager to defragment, optimise, and shrink the main Windows partition, which meant it was at the /start/ of the free space. (W's DM for peace of mind of the system's owner.) I may be repeating this fairly soon, and am interested about the difference between W at the start and W at the end of the drive, particular now it's solid state rather than a spinning disc. > You might be able to do it all with one EFI partition. I think I found it > easier to put Windows on first - because it's fussy, then install Debian > but I may have done it both ways round in the past. Installing Windows > second is definitely harder if I recall correctly. Yes, I'm used to Microsoft first, then Debian. In the days of MSDOS, this was essential on some of my disks, because DOS had to choose its preferred disk geometry, or it wouldn't work at all. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2024-12-05 21:20 +0100 |
| Message-ID | <JQqul-dZs7-1@gated-at.bofh.it> |
| In reply to | #275297 |
On Thu, Dec 05, 2024 at 08:24:05PM +0100, Hans wrote: >What can I do? I would like to keep the existing partitions. However, I could >shrink them. At the moment, my drive looks at this: > >primary partition Windows-boot ntfs >primary partition Windows ntfs >primary partition /boot /dev/sda3 ext4 >extended partition /dev/sda4 >logical partition /dev/sda5 swap >logical partition /dev/sda6 / ext4 >logical partition /dev/sda7 encrypted home >logical partition /dev/sda8 encrypted usr >logical partition /dev/sda9 encrypted var >logical partition /dev/sda10 encrypted data You can't just dd the disks if you have an old style dos partition table, you need to create a GPT partition table on the new drive, then dd the individual partitions. I'm unaware of a tool that would automated this, though one may exist. You don't need a separate /boot for the scenario above, and you could turn partition 3 into the EFI partition (moving the stuff currently in /boot into /boot on the / drive.) This is technically straightforward, but there are a lot of fiddly bits, and I have no idea whether windows would still work. If you had just linux and a couple of partitions it would be much easier. Honestly, you're in partition hell and I'd start over with fewer. (Though it is possible to keep this structure.) Maybe use a windows disk migration tool to copy the windows stuff to the new drive, then create a new empty encrypted / + boot + EFI, sync the current / to it, then sync the other partitions to new /. There are several ways to solve this problem but none automated or simple. When you first talked about migrating I kinda assumed a typical install with a small number of linux partitions, not this. :-)
[toc] | [prev] | [next] | [standalone]
| From | pocket@homemail.com |
|---|---|
| Date | 2024-12-05 22:20 +0100 |
| Message-ID | <JQrqp-e01a-5@gated-at.bofh.it> |
| In reply to | #275297 |
> Sent: Thursday, December 05, 2024 at 2:24 PM > From: "Hans" <hans.ullrich@loop.de> > To: debian-user@lists.debian.org > Subject: Re: From SSD to NVME > > Hi folks, > > as promised I send you my experiences with cloning to NVME. > > So, today I got my new notebook. As I never used UEFI, I disabled UEFI in BIOS > (my first mistake!), then cloned everything to the new drive. > > Firts reboot worked well, no problems. But then I realized, that if you want > NVME mode, you MUST use native UEFI in BIOS settings. > > However, doing so, neither Debian nor Windows will boot. Of course: There is > no EFI partition on my harddrive, as I never needed one (still). > > Now I am hasseling with the drive, as I want NVME-mode of course, because it > is faster. And of course, I do not want to reinstall everything! > > I saw some documentations, how to get EFI on the drive, but it looks, you need > a seperate partition with FAT to get EFI on, right? > > However, I saw also the possibility to get EFI on my seperate /boot partition. > > What can I do? I would like to keep the existing partitions. However, I could > shrink them. At the moment, my drive looks at this: > > primary partition Windows-boot ntfs > primary partition Windows ntfs > primary partition /boot /dev/sda3 ext4 > extended partition /dev/sda4 > logical partition /dev/sda5 swap > logical partition /dev/sda6 / ext4 > logical partition /dev/sda7 encrypted home > logical partition /dev/sda8 encrypted usr > logical partition /dev/sda9 encrypted var > logical partition /dev/sda10 encrypted data > > So I could shrinken some partitions and create a new logical one. > > Other option would be, delete "swap" partition and make a new "EFI" partition. > > What do you think, might be the best way? > > Some better ideas? > > Thanks for reading this. > > Best regards > > Hans > Well it looks like you have a big job ahead of you. Shrinking the swap partition is the easy way to get some room as you can create a swap file to take its place. The real issue is that the efi partition if I recall correctly has to be a primary partition. Can you go to GPT istead of MSDOS MBR?
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@stanis.net> |
|---|---|
| Date | 2024-12-05 22:30 +0100 |
| Message-ID | <JQrA5-e04Z-1@gated-at.bofh.it> |
| In reply to | #275306 |
pocket composed on 2024-12-05 22:17 (UTC+0100): > The real issue is that the efi partition if I recall correctly has to be a primary partition. The ESP filesystem must be on a GPT partition. GPT is compatible with legacy/BIOS booting, but not the other way around. It exists because UEFI requires it. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2024-12-05 22:30 +0100 |
| Message-ID | <JQrA5-e04Z-29@gated-at.bofh.it> |
| In reply to | #275310 |
Felix Miata (12024-12-05): > The ESP filesystem must be on a GPT partition. Not always. Regards, -- Nicolas George
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@stanis.net> |
|---|---|
| Date | 2024-12-05 22:40 +0100 |
| Message-ID | <JQrJL-e081-9@gated-at.bofh.it> |
| In reply to | #275312 |
Nicolas George composed on 2024-12-05 22:28 (UTC+0100): > Felix Miata: >> The ESP filesystem must be on a GPT partition. > Not always. Where else is possible? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2024-12-05 23:10 +0100 |
| Message-ID | <JQscO-e0Bw-11@gated-at.bofh.it> |
| In reply to | #275313 |
Felix Miata (12024-12-05): > Where else is possible? Depends on the firmware, of course. If you try to put a GPT on the drive of a Lenovo Miix 3-1030, it will not boot. Regards, -- Nicolas George
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2024-12-05 22:20 +0100 |
| Message-ID | <JQrqp-e01a-9@gated-at.bofh.it> |
| In reply to | #275297 |
On Thu 05 Dec 2024 at 20:24:05 (+0100), Hans wrote: > So, today I got my new notebook. As I never used UEFI, I disabled UEFI in BIOS > (my first mistake!), then cloned everything to the new drive. Why did you stick with MBR partitioning rather than GPT? > Now I am hasseling with the drive, as I want NVME-mode of course, because it > is faster. And of course, I do not want to reinstall everything! It might be a good thing that you are starting over. > I saw some documentations, how to get EFI on the drive, but it looks, you need > a seperate partition with FAT to get EFI on, right? > > However, I saw also the possibility to get EFI on my seperate /boot partition. With an ESP, you wouldn't need a separate /boot partition. > What can I do? I would like to keep the existing partitions. However, I could > shrink them. At the moment, my drive looks at this: > > primary partition Windows-boot ntfs > primary partition Windows ntfs > primary partition /boot /dev/sda3 ext4 > extended partition /dev/sda4 > logical partition /dev/sda5 swap > logical partition /dev/sda6 / ext4 > logical partition /dev/sda7 encrypted home > logical partition /dev/sda8 encrypted usr > logical partition /dev/sda9 encrypted var > logical partition /dev/sda10 encrypted data Why do you want so many separate partitions on a notebook? > What do you think, might be the best way? > > Some better ideas? I see that Andrew posted a summary of how you could proceed. Others might do the same. But there were so many pitfalls in your first attempt, would it not be sensible for you to post, in a little more detail, how you intend to build the next machine, invite criticism, and then refine your plan, rather than just going for the "big reveal" in a few days time. Personally, my biggest worry would be dealing with Windows. But I don't know what resources you have for that. Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2024-12-05 19:10 +0100 |
| Message-ID | <JQosx-dYbt-7@gated-at.bofh.it> |
| In reply to | #275286 |
On Thu, Dec 05, 2024 at 10:55:48AM -0500, eben@gmx.us wrote: >How do I tell how many lanes a given drive uses (preferably before purchase)? It would be buried in the technical docs. I've only seen 4x drives (but I'm sure there may be some cheaper drives with fewer). On the motherboard side it's common to see 2 lanes in some slots for the simple reason that there are a limited number of lanes from the CPU--most people would rather have a slower-connected drive than none at all. Having 2 lanes may not even be a limitation: 2 PCIe v3 lanes are the same speed as 4 v2 lanes. The bandwith to the drive is rarely a bottleneck, especially at the desktop level. For best results plug your drive into the motherboard slot with the largest number of the highest version lanes. A lower version drive can be used in a higher version slot with no penalty, and a higher version drive can be used in a lower version slot but will run each lane at the lower speed and will have half the theoretical performance, or less. E.g.: my motherboard has something like 4x v5 + 4x v4 + 2x v4 + 4x v3. Let's say I have 2 v4 drives and 1 v3 drive. If I put one v4 drive in the 4x v5 slot, one in the 4x v4 slot, and the v3 drive in the 4x v3 slot, all the drives will operate at their peak efficiency. If I put a 4x v4 drive in the 2x v4 or 4x v3 slot, it will operate at the same lower level (half the peak bandwidth). Also, if I put the v3 drive in the 2x v4 slot it will only be able to use half of its bandwidth, because it will only run at 2x v3 (as it is a v3 drive). Bottom line, it's worth checking the motherboard documentation if you have multiple M.2 slots, but only because it costs nothing to do so. >Yeah, I probably wouldn't be able to tell. It's just geek points. I was >thinking it might matter when xferring gigabyte+ files to the media server, >but then the bottleneck would either be the CPU encrypting the SSH data, or >the network itself. Yes. Also not many drives can sustain a multi-gigabyte write rate anyway, and if you're just talking bursts most situations won't differentiate between moving 200MB in .1s vs 1s as the write is generally buffered by the OS. So where the peak speed matters on the desktop is mostly in very large reads with no writing, which just don't happen much. Basically game startup, but the game itself is probably not written to depend on 16GB/s because most people wouldn't be able to run it. Once you're beyond the 600MB/s of SATA into any NVMe you've hit the point of diminishing returns. >Is one kind more long-lived than the other? Not due specifically to the interface. At the same price point you'll probably have similar longevity, though sata drives are moving in the direction of less bang for the buck because there aren't many new ones being developed and the sales volume is going NVMe.
[toc] | [prev] | [next] | [standalone]
| From | eben@gmx.us |
|---|---|
| Date | 2024-12-05 22:10 +0100 |
| Message-ID | <JQrgJ-dZXW-3@gated-at.bofh.it> |
| In reply to | #275294 |
On 12/5/24 13:07, Michael Stone wrote: > On Thu, Dec 05, 2024 at 10:55:48AM -0500, eben@gmx.us wrote: >> How do I tell how many lanes a given drive uses (preferably before purchase)? > > It would be buried in the technical docs. I've only seen 4x drives (but I'm > sure there may be some cheaper drives with fewer). On the motherboard side > it's common to see 2 lanes in some slots for the simple reason that there > are a limited number of lanes from the CPU--most people would rather have a > slower-connected drive than none at all. To find out if the motherboard imposed any limitations, I checked the manual. I found these tables, which I can't see the implications of: M2D_32G M.2 connector +-------------+---------+---------+---------+---------+---------+---------+ |\ Connector | SATA3_0 | SATA3_1 | SATA3_2 | SATA3_3 | SATA3_4 | SATA3_5 | + \----------\+---------+---------+---------+---------+---------+---------+ | Type of SSD | SATA_Express | SATA_Express | - | +-------------+---------+---------+---------+---------+---------+---------+ | SATA SSD | OK | OK | OK | X | OK | OK | +-------------+---------+---------+---------+---------+---------+---------+ | | OK | OK | - | +-------------+---------+---------+---------+---------+---------+---------+ | PCIe x4 SSD | X | X | X | X | OK | OK | +-------------+---------+---------+---------+---------+---------+---------+ | | OK (note) | X | - | +-------------+---------+---------+---------+---------+---------+---------+ | PCIe x2 SSD | OK | OK | X | X | OK | OK | +-------------+---------+---------+---------+---------+---------+---------+ | | OK | X | - | +-------------+---------+---------+---------+---------+---------+---------+ Note: The PCIe x4 SSD runs at x2 speed. M2A_32G M.2 connector +-------------+---------+---------+---------+---------+---------+---------+ |\ Connector | SATA3_0 | SATA3_1 | SATA3_2 | SATA3_3 | SATA3_4 | SATA3_5 | + \----------\+---------+---------+---------+---------+---------+---------+ | Type of SSD | SATA_Express | SATA_Express | - | +-------------+---------+---------+---------+---------+---------+---------+ | SATA SSD | no | OK | OK | X | OK | OK | +-------------+---------+---------+---------+---------+---------+---------+ | | OK | OK | - | +-------------+---------+---------+---------+---------+---------+---------+ | PCIe x4 SSD | OK | OK | OK | OK | OK | OK | +-------------+---------+---------+---------+---------+---------+---------+ | | OK | OK | - | +-------------+---------+---------+---------+---------+---------+---------+ | PCIe x2 SSD | OK | OK | OK | OK | OK | OK | +-------------+---------+---------+---------+---------+---------+---------+ | | OK | OK | - | +-------------+---------+---------+---------+---------+---------+---------+ Yes, the tables were in that order. Not sure why. In the book "OK" and "X" were a checkmark and a times-X respectively, but they're hard to type. In each table, the even-numbered rows were darker grey, so I guess they go together. It gets confusing when they try to re-use the table's structure for (mostly) unrelated data. I don't know why they didn't just make the tables two columns wider and half as tall. On a side note, what are SATA Express ports good for? They're narrower than standard SATA ports. Anyhow it looks like M2A_32G is more capable in general, but there are weird restrictions everywhere. Also it looks like there's a way to assign what's in the M.2 slot to another SATA port, and I need to find out how that's done, if I should acquire another M.2 drive. > E.g.: my motherboard has something like 4x v5 + 4x v4 + 2x v4 + 4x v3. Let's > say I have 2 v4 drives and 1 v3 drive. If I put one v4 drive in the 4x v5 > slot, one in the 4x v4 slot, and the v3 drive in the 4x v3 slot, all the > drives will operate at their peak efficiency. If I put a 4x v4 drive in the > 2x v4 or 4x v3 slot, it will operate at the same lower level (half the peak > bandwidth). Also, if I put the v3 drive in the 2x v4 slot it will only be > able to use half of its bandwidth, because it will only run at 2x v3 (as it > is a v3 drive). Bottom line, it's worth checking the motherboard > documentation if you have multiple M.2 slots, but only because it costs > nothing to do so. Man, I need to play with some better gear. This is almost entirely academic. >> Is one kind more long-lived than the other? > > Not due specifically to the interface. At the same price point you'll > probably have similar longevity, though sata drives are moving in the > direction of less bang for the buck because there aren't many new ones being > developed and the sales volume is going NVMe. Right, I've already had to go from 1T spinning-rust drives to 2T, not because I was running out of room, but because the selection of 1T drives was so paltry. Generally I don't mind things being slow (I'm used to dealing with slow computers), but money is in short supply and cool hardware costs money. So I'm more of a trailing-edge consumer.
[toc] | [prev] | [next] | [standalone]
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2024-12-05 23:30 +0100 |
| Message-ID | <JQswa-e0L2-7@gated-at.bofh.it> |
| In reply to | #275305 |
On Thu, Dec 05, 2024 at 04:06:17PM -0500, eben@gmx.us wrote: >To find out if the motherboard imposed any limitations, I checked the >manual. I found these tables, which I can't see the implications of: > >M2D_32G M.2 connector >+-------------+---------+---------+---------+---------+---------+---------+ >|\ Connector | SATA3_0 | SATA3_1 | SATA3_2 | SATA3_3 | SATA3_4 | SATA3_5 | >+ \----------\+---------+---------+---------+---------+---------+---------+ >| Type of SSD | SATA_Express | SATA_Express | - | Ah, SATA express (SATAe). That's a dead standard that never actually got implemented in a drive (as far as I know) but was included on motherboards for some time before it was clear that M.2 won and SATAe was a dead end. SATAe had the ability to use two SATA ports and an additonal connector to provide two PCIe lanes for a drive, so a single connector would have attached to one of the little ports as well as the two SATA ports beside it. Certain SATA channels on these motherboards were shared between the SATA ports and the M.2 SATA pins, and PCIe lanes were shared between some of the M.2 PCIe pins and the SATAe PCIe pins *and* some of the SATA contollers. The table is trying to explain which combinations won't work. E.g., if you use a SATA M.2 drive in M2D_32G you can't also attach a SATA drive to SATA3_3 or a SATAe drive to SATA3_2/3 (not that such a drive exists), and if use a PCIe x4 SSD in M2D_32G you can't use SATA3_0/1/2/3, and if you use the SATAe associated with SATA3_0/1 you drop the speed of M2D_32G to x2 instead of x4. You can ignore the dark lines because SATAe doesn't exist. If you only plug SATA disks into SATA3_4/5 you can do anything with the two M.2 connectors. If you want more than two SATA disks you can put an NVMe drive into M2A_32G and nothing in M2D_32G and use any SATA port. Or you can use SATA3_0/1 with two NVMe drives but that will drop M2D_32G NVMe to x2 speed. If you use SATA3_0 you can't put a SATA M.2 drive into M2A_32G and if you use SATA3_3 you can't put a SATA M.2 drive into M2D_32G. Simple, right? :-D Most desktop motherboards have some sort of limitations/sharing like this because there are only so many PCIe lanes from the CPU, but they vary in how well they communicate the information.
[toc] | [prev] | [next] | [standalone]
| From | eben@gmx.us |
|---|---|
| Date | 2024-12-06 00:10 +0100 |
| Message-ID | <JQt8R-e1i5-7@gated-at.bofh.it> |
| In reply to | #275317 |
On 12/5/24 17:26, Michael Stone wrote: > On Thu, Dec 05, 2024 at 04:06:17PM -0500, eben@gmx.us wrote: >> To find out if the motherboard imposed any limitations, I checked the >> manual. I found these tables, which I can't see the implications of: >> >> M2D_32G M.2 connector >> +-------------+---------+---------+---------+---------+---------+---------+ >> |\ Connector | SATA3_0 | SATA3_1 | SATA3_2 | SATA3_3 | SATA3_4 | SATA3_5 | >> | \----------\+---------+---------+---------+---------+---------+---------+ >> | Type of SSD | SATA_Express | SATA_Express | - | > > Ah, SATA express (SATAe). That's a dead standard that never actually got > implemented in a drive (as far as I know) but was included on > motherboards for some time before it was clear that M.2 won and SATAe > was a dead end. > The table is trying to explain which combinations won't work. > You can ignore the dark lines because SATAe doesn't exist. Good that makes things simpler. Maybe I can find a way to disable it in the BIOS. I got a PCIe SATA card. Right now I'm using 1/4 of it for an optical drive, but if I should acquire an SSD that disables an important SATA port, the card may become more useful. > Simple, right? :-D Yeah, I see myself doing a logic puzzle and losing quite a bit of hair if I add an SSD. > Most desktop motherboards have some sort of limitations/sharing like this > because there are only so many PCIe lanes from the CPU, but they vary in > how well they communicate the information.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | linux.debian.user
csiph-web