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 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Michael Stone <mstone@debian.org> |
|---|---|
| Date | 2024-12-05 23:00 +0100 |
| Message-ID | <JQs37-e0h6-1@gated-at.bofh.it> |
| In reply to | #275308 |
On Thu, Dec 05, 2024 at 04:16:53PM -0500, Felix Miata wrote: >At least one does. I provided URL to the one I use, for some definition of >"automated", upthread @2024-12-05 12:24 (UTC-0500) in reply to your post 102 >minutes earlier. :) Automated means something along the lines of "make this mbr disk into a working gpt disk at the push of a button". I dont see that your tool does that, but I'm also not interested in digging through the documentation in any detail.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@stanis.net> |
|---|---|
| Date | 2024-12-06 00:00 +0100 |
| Subject | Re: From SSD to NVME - oops! |
| Message-ID | <JQsZc-e0Yo-29@gated-at.bofh.it> |
| In reply to | #275314 |
Felix Miata composed on 2024-12-05 17:52 (UTC-0500): > Michael Stone composed on 2024-12-05 16:51 (UTC-0500): >> On Thu, Dec 05, 2024 at 16:16:53 -0500, Felix Miata wrote: >>>At least one does. I provided URL to the one I use, for some definition of >>>"automated", upthread @2024-12-05 12:24 (UTC-0500) in reply to your post 102 >>>minutes earlier. :) >> Automated means something along the lines of "make this mbr disk into a >> working gpt disk at the push of a button". I dont see that your tool > It's not "my" tool. I've only been a user of it, to the exclusion of all other > partitioning tools, for over two decades. >> does that, but I'm also not interested in digging through the >> documentation in any detail. > Here ya go (Pastebinit on Bookworm refuses to accept images.): > https://paste.opensuse.org/a556a79e8015 > expires in 7 days, shows DFSee menu open for "Convert an MBR disk to GPT". Oops. My mistake. Table conversion, yes, but apparently not also keeping the existing partitions ready to use. -- 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 | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2024-12-06 04:40 +0100 |
| Subject | Re: From SSD to NVME - oops! |
| Message-ID | <JQxm9-e40L-9@gated-at.bofh.it> |
| In reply to | #275320 |
On 06/12/2024 05:58, Felix Miata wrote: > Felix Miata composed on 2024-12-05 17:52 (UTC-0500): > >> Here ya go (Pastebinit on Bookworm refuses to accept images.): >> https://paste.opensuse.org/a556a79e8015 >> expires in 7 days, shows DFSee menu open for "Convert an MBR disk to GPT". > > Oops. My mistake. Table conversion, yes, but apparently not also keeping the > existing partitions ready to use. sgdisk has the "--mbrtogpt" conversion option. Its docs recommend against hybrid MBR+GPT trick considering it as a workaround for some idiosyncrasy of older Apple devices.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@stanis.net> |
|---|---|
| Date | 2024-12-06 00:00 +0100 |
| Message-ID | <JQsZc-e0Yo-31@gated-at.bofh.it> |
| In reply to | #275314 |
Michael Stone composed on 2024-12-05 16:51 (UTC-0500): > On Thu, Dec 05, 2024 at 16:16:53 -0500, Felix Miata wrote: >>At least one does. I provided URL to the one I use, for some definition of >>"automated", upthread @2024-12-05 12:24 (UTC-0500) in reply to your post 102 >>minutes earlier. :) > Automated means something along the lines of "make this mbr disk into a > working gpt disk at the push of a button". I dont see that your tool It's not "my" tool. I've only been a user of it, to the exclusion of all other partitioning tools, for over two decades. > does that, but I'm also not interested in digging through the > documentation in any detail. Here ya go (Pastebinit on Bookworm refuses to accept images.): https://paste.opensuse.org/a556a79e8015 expires in 7 days, shows DFSee menu open for "Convert an MBR disk to GPT". -- 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 | Jeffrey Walton <noloader@gmail.com> |
|---|---|
| Date | 2024-12-06 04:20 +0100 |
| Message-ID | <JQx2N-e3TZ-1@gated-at.bofh.it> |
| In reply to | #275321 |
On Thu, Dec 5, 2024 at 8:57 PM Felix Miata <mrmazda@stanis.net> wrote: > > Michael Stone composed on 2024-12-05 16:51 (UTC-0500): > > > On Thu, Dec 05, 2024 at 16:16:53 -0500, Felix Miata wrote: > > >>At least one does. I provided URL to the one I use, for some definition of > >>"automated", upthread @2024-12-05 12:24 (UTC-0500) in reply to your post 102 > >>minutes earlier. :) > > > Automated means something along the lines of "make this mbr disk into a > > working gpt disk at the push of a button". I dont see that your tool > > It's not "my" tool. I've only been a user of it, to the exclusion of all other > partitioning tools, for over two decades. It looks like there are several tools to do the job. I just realized mbr2gpt was a good term to search for. Even Microsoft has one: <https://learn.microsoft.com/en-us/windows/deployment/mbr-to-gpt>. > > does that, but I'm also not interested in digging through the > > documentation in any detail. > > Here ya go (Pastebinit on Bookworm refuses to accept images.): > https://paste.opensuse.org/a556a79e8015 > expires in 7 days, shows DFSee menu open for "Convert an MBR disk to GPT". Jeff
[toc] | [prev] | [next] | [standalone]
| From | "Andrew M.A. Cater" <amacater@einval.com> |
|---|---|
| Date | 2024-12-02 20:50 +0100 |
| Message-ID | <JPkAF-dhgh-9@gated-at.bofh.it> |
| In reply to | #275135 |
On Mon, Dec 02, 2024 at 05:49:18PM +0100, Hans wrote: > Hi folks, > > as my old notebook died, I ntend to buy a new notebook. > The old one has got a SSD drive, the new one an NVME. > > I want to clone the whole system 1 to 1 to the new NVME. > It might be easier to produce a clean new install and then just rsync data from the SSD drive to the appropriate directories on the NVME. > In my /etc/fstab I am using UUID entries instead of /dev/sdX. > The new one then would have /dev/nvme* as entries (that is clear), but if I am > using only UUID, the question: > > Will the UUID change at clone, even when the partitions are not changed in a > bit of size? IMHO the UUID will not change, but I am not quite sure. > I'm fairly sure this was brought up just about at the end of last month. > When cloning from SSD to SSD this is working, but I have no experience when > cloning from SSD to NVME. > Hoping to keep partition sizes etc. identical across drives is hard so it does seem easier to just copy data from one drive to the other. > Thanks for a short feedback. > All the very best, as ever, Andy (amacater@debian.org) > Best > > Hans > > > >
[toc] | [prev] | [next] | [standalone]
| From | pocket@homemail.com |
|---|---|
| Date | 2024-12-03 03:00 +0100 |
| Message-ID | <JPqmJ-dkI3-1@gated-at.bofh.it> |
| In reply to | #275152 |
> Sent: Monday, December 02, 2024 at 2:40 PM > From: "Andrew M.A. Cater" <amacater@einval.com> > To: debian-user@lists.debian.org > Subject: Re: From SSD to NVME > > On Mon, Dec 02, 2024 at 05:49:18PM +0100, Hans wrote: > > Hi folks, > > > > as my old notebook died, I ntend to buy a new notebook. > > The old one has got a SSD drive, the new one an NVME. > > > > I want to clone the whole system 1 to 1 to the new NVME. > > > > It might be easier to produce a clean new install and then just rsync > data from the SSD drive to the appropriate directories on the NVME. No it is better that everything comes over all at one time > > > > In my /etc/fstab I am using UUID entries instead of /dev/sdX. > > The new one then would have /dev/nvme* as entries (that is clear), but if I am > > using only UUID, the question: > > > > Will the UUID change at clone, even when the partitions are not changed in a > > bit of size? IMHO the UUID will not change, but I am not quite sure. > > > > I'm fairly sure this was brought up just about at the end of last month. It depends upon if you created a partition table, partitions and filesystems on the drive. I create the drive layout on the drive then rsync the old drive to the new drive. Then I fixup the PARTUUID in the /etc/fstab and boot loader. If I am using Archlinux or my own custom build os I have a blank /etc/fstab and /etc/hosts cat /etc/fstab # Static information about the filesystems. # See fstab(5) for details. # <file system> <dir> <type> <options> <dump> <pass> cat /etc/hosts # Static table lookup for hostnames. # See hosts(5) for details. [alarm@alarm ~]$ blkid /dev/nvme0n1p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="5A88-04BC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="b2c58878-01" /dev/nvme0n1p2: LABEL="rootfs" UUID="5170097f-f1f6-42d8-a2ff-8938cbdfa7be" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b2c58878-02" > > > When cloning from SSD to SSD this is working, but I have no experience when > > cloning from SSD to NVME. > > > > Hoping to keep partition sizes etc. identical across drives is hard so it > does seem easier to just copy data from one drive to the other. dd is your friend https://www.howtoforge.com/linux-dd-command-clone-disk-practical-example/ https://thelinuxcode.com/clone-disk-using-dd-linux/ $ ls -l /dev/nvme0* crw------- 1 root root 245, 0 Dec 2 16:14 /dev/nvme0 brw-rw---- 1 root disk 259, 0 Dec 2 16:14 /dev/nvme0n1 brw-rw---- 1 root disk 259, 1 Dec 2 16:14 /dev/nvme0n1p1 brw-rw---- 1 root disk 259, 2 Dec 2 16:14 /dev/nvme0n1p2 https://wiki.archlinux.org/title/Solid_state_drive/NVMe https://www.linuxoperatingsystem.net/nvme-command-line-in-linux-a-deep-guide-for-beginners-and-advanced-users/ https://superuser.com/questions/1449499/why-does-linux-list-nvme-drives-as-dev-nvme0-instead-of-dev-sda -- Hindi madali ang maging ako
[toc] | [prev] | [next] | [standalone]
| From | "Andrew M.A. Cater" <amacater@einval.com> |
|---|---|
| Date | 2024-12-03 10:00 +0100 |
| Message-ID | <JPwVb-dpQr-3@gated-at.bofh.it> |
| In reply to | #275165 |
On Tue, Dec 03, 2024 at 02:55:07AM +0100, pocket@homemail.com wrote: > > > > It might be easier to produce a clean new install and then just rsync > > data from the SSD drive to the appropriate directories on the NVME. > > No it is better that everything comes over all at one time > As someone else has put it elsewhere in the thread: new laptop means new drivers, potentially moving from legacy MBR to UEFI ... easier in many ways to put a clean install of Debian on from new media to start with (also wiping out whatever was there before if it came preinstalled with Windows or whatever). > > > > I'm fairly sure this was brought up just about at the end of last month. > > It depends upon if you created a partition table, partitions and filesystems on the drive. > > I create the drive layout on the drive then rsync the old drive to the new drive. > Then I fixup the PARTUUID in the /etc/fstab and boot loader. > If I am using Archlinux or my own custom build os I have a blank /etc/fstab and /etc/hosts > There's more than one way to do it: if you absolutely know what partition sizes you want, maybe - LVM and one partition is a fairly sensible starting point because partitions will grow and shrink, for example. > cat /etc/fstab > # Static information about the filesystems. > # See fstab(5) for details. > > # <file system> <dir> <type> <options> <dump> <pass> > > cat /etc/hosts > # Static table lookup for hostnames. > # See hosts(5) for details. > > [alarm@alarm ~]$ blkid > /dev/nvme0n1p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="5A88-04BC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="b2c58878-01" > /dev/nvme0n1p2: LABEL="rootfs" UUID="5170097f-f1f6-42d8-a2ff-8938cbdfa7be" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b2c58878-02" > > > > > Hoping to keep partition sizes etc. identical across drives is hard so it > > does seem easier to just copy data from one drive to the other. > > dd is your friend > > https://www.howtoforge.com/linux-dd-command-clone-disk-practical-example/ > https://thelinuxcode.com/clone-disk-using-dd-linux/ > dd is your friend if you know _exactly_ what you are doing :) > As ever, the right way is what works for your requirements: sometimes people need something straightforward to get them started. Making work for yourself at the outset needs to be justified by saving time later on, perhaps. All the very best, as ever, Andy (amacater@debian.org) > -- > Hindi madali ang maging ako >
[toc] | [prev] | [next] | [standalone]
| From | pocket@homemail.com |
|---|---|
| Date | 2024-12-03 12:10 +0100 |
| Message-ID | <JPyWZ-drfy-23@gated-at.bofh.it> |
| In reply to | #275175 |
> Sent: Tuesday, December 03, 2024 at 3:52 AM > From: "Andrew M.A. Cater" <amacater@einval.com> > To: debian-user@lists.debian.org > Subject: Re: From SSD to NVME > > On Tue, Dec 03, 2024 at 02:55:07AM +0100, pocket@homemail.com wrote: > > > > > > > It might be easier to produce a clean new install and then just rsync > > > data from the SSD drive to the appropriate directories on the NVME. > > > > No it is better that everything comes over all at one time > > > > As someone else has put it elsewhere in the thread: new laptop means > new drivers, potentially moving from legacy MBR to UEFI ... easier in > many ways to put a clean install of Debian on from new media to start > with (also wiping out whatever was there before if it came preinstalled > with Windows or whatever). None to little of that is relevant. The "drivers" are part of the kernel, it is not 1995 anymore. I go from MBR to GPT to UEFI all the time. Is it nice to think that debian still has the microsoft mindset? A "clean" install is not really required on a modern linux system. Linux is not microsoft windows. When people state the above it really just shows they don't understand Linux. > > > > > > > I'm fairly sure this was brought up just about at the end of last month. > > > > It depends upon if you created a partition table, partitions and filesystems on the drive. > > > > I create the drive layout on the drive then rsync the old drive to the new drive. > > Then I fixup the PARTUUID in the /etc/fstab and boot loader. > > If I am using Archlinux or my own custom build os I have a blank /etc/fstab and /etc/hosts > > > There's more than one way to do it: if you absolutely know what partition > sizes you want, maybe - LVM and one partition is a fairly sensible starting > point because partitions will grow and shrink, for example. Nonsense, using/building distributions and running Linux since 1995, partitions don't grow and shrink. They are static. That is an outdated concept. I have "cloned" my last 15 installs from a USB drive to another drive. Starting from an old image on a USB drive that I don't recall how old it is to a new sdcard/HDD/SDD/NVME drive then updated using the package manager and never had an issue. debian is the only distribution that I have used that has a problem doing that. I have on occasion installed from a package manager (not dpkg/apt) to a systemd nspawn container then copied that to a new drive properly prepared of course. Put the drive into a new machine and boot and done. It just works. It is not rocket science nor brain surgery and it is not hard at all to do. The only time it seems to be an issue is when using debian. Using Archlinux for instance you can (and I have) use an install image years old and simply do an update and you are done. It is all up to date. Rolling releases is how it is done. Knowing how Linux boots and works is a help. I don't know every concept behind linux but I do know how to build a system from scratch (building all the packages myself as in cross compiling from AMD64 to ARM) and then get it to boot. Tedious but not really difficult/hard. [alarm@alarm ~]$ ls -l / lrwxrwxrwx 1 root root 7 Nov 25 19:15 bin -> usr/bin drwxr-xr-x 3 root root 4096 Dec 31 1969 boot drwxr-xr-x 17 root root 3980 Dec 2 10:38 dev drwxr-xr-x 52 root root 4096 Dec 2 20:58 etc drwxr-xr-x 3 root root 4096 Aug 19 03:43 home lrwxrwxrwx 1 root root 7 Nov 25 19:15 lib -> usr/lib drwx------ 2 root root 16384 May 15 2024 lost+found drwxr-xr-x 2 root root 4096 Sep 14 12:01 mnt drwxr-xr-x 2 root root 4096 Apr 7 2024 opt dr-xr-xr-x 247 root root 0 Dec 31 1969 proc drwxr-x--- 6 root root 4096 Dec 2 13:06 root drwxr-xr-x 22 root root 640 Dec 2 10:38 run lrwxrwxrwx 1 root root 7 Nov 25 19:15 sbin -> usr/bin drwxr-xr-x 36 root alarm 4096 Nov 29 12:42 srv dr-xr-xr-x 12 root root 0 Dec 31 1969 sys drwxrwxrwt 13 root root 260 Dec 3 00:00 tmp drwxr-xr-x 8 root root 4096 Dec 2 20:58 usr drwxr-xr-x 13 root root 4096 Nov 30 17:21 var Notice sbin is a symlink to /usr/bin > > > cat /etc/fstab > > # Static information about the filesystems. > > # See fstab(5) for details. > > > > # <file system> <dir> <type> <options> <dump> <pass> > > > > cat /etc/hosts > > # Static table lookup for hostnames. > > # See hosts(5) for details. > > > > [alarm@alarm ~]$ blkid > > /dev/nvme0n1p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="5A88-04BC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="b2c58878-01" > > /dev/nvme0n1p2: LABEL="rootfs" UUID="5170097f-f1f6-42d8-a2ff-8938cbdfa7be" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b2c58878-02" > > > > > > > > Hoping to keep partition sizes etc. identical across drives is hard so it > > > does seem easier to just copy data from one drive to the other. > > > > dd is your friend > > > > https://www.howtoforge.com/linux-dd-command-clone-disk-practical-example/ > > https://thelinuxcode.com/clone-disk-using-dd-linux/ > > > > dd is your friend if you know _exactly_ what you are doing :) No you just need to pay attention and follow directions, no voodoo required. > > > > > As ever, the right way is what works for your requirements: sometimes > people need something straightforward to get them started. Making > work for yourself at the outset needs to be justified by saving time > later on, perhaps. Your standard disclaimer. A "new" install is a new install. How Linux boots and runs is well known. DDG is your friend. > > All the very best, as ever, Not really > > Andy > (amacater@debian.org) > -- Hindi madali ang maging ako
[toc] | [prev] | [next] | [standalone]
| From | <tomas@tuxteam.de> |
|---|---|
| Date | 2024-12-03 12:40 +0100 |
| Message-ID | <JPzq2-drrO-3@gated-at.bofh.it> |
| In reply to | #275180 |
[Multipart message — attachments visible in raw view] — view raw
On Tue, Dec 03, 2024 at 12:01:15PM +0100, pocket@homemail.com wrote: [...] > When people state the above it really just shows they don't understand Linux. I'd guess Andrew Cater understands Linux better than you and me taken together, but hey. He's been contributing to Debian since (at least) late 1990s. Disagreeing is OK. Disparaging is... risky. Cheers -- t
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-12-03 13:20 +0100 |
| Message-ID | <JPA2J-drSV-3@gated-at.bofh.it> |
| In reply to | #275180 |
On Tue, Dec 03, 2024 at 12:01:15 +0100, pocket@homemail.com wrote: > [alarm@alarm ~]$ ls -l / > lrwxrwxrwx 1 root root 7 Nov 25 19:15 bin -> usr/bin > drwxr-xr-x 3 root root 4096 Dec 31 1969 boot > drwxr-xr-x 17 root root 3980 Dec 2 10:38 dev > drwxr-xr-x 52 root root 4096 Dec 2 20:58 etc > drwxr-xr-x 3 root root 4096 Aug 19 03:43 home > lrwxrwxrwx 1 root root 7 Nov 25 19:15 lib -> usr/lib > drwx------ 2 root root 16384 May 15 2024 lost+found > drwxr-xr-x 2 root root 4096 Sep 14 12:01 mnt > drwxr-xr-x 2 root root 4096 Apr 7 2024 opt > dr-xr-xr-x 247 root root 0 Dec 31 1969 proc > drwxr-x--- 6 root root 4096 Dec 2 13:06 root > drwxr-xr-x 22 root root 640 Dec 2 10:38 run > lrwxrwxrwx 1 root root 7 Nov 25 19:15 sbin -> usr/bin > drwxr-xr-x 36 root alarm 4096 Nov 29 12:42 srv > dr-xr-xr-x 12 root root 0 Dec 31 1969 sys > drwxrwxrwt 13 root root 260 Dec 3 00:00 tmp > drwxr-xr-x 8 root root 4096 Dec 2 20:58 usr > drwxr-xr-x 13 root root 4096 Nov 30 17:21 var > > Notice sbin is a symlink to /usr/bin That's not how Debian 12 has it. hobbit:~$ ls -ld /sbin /bin lrwxrwxrwx 1 root root 7 Feb 17 2024 /bin -> usr/bin/ lrwxrwxrwx 1 root root 8 Feb 17 2024 /sbin -> usr/sbin/ If Trixie has done an "sbin merge", it's news to me.
[toc] | [prev] | [next] | [standalone]
| From | pocket@homemail.com |
|---|---|
| Date | 2024-12-03 13:40 +0100 |
| Message-ID | <JPAm5-ds1R-1@gated-at.bofh.it> |
| In reply to | #275183 |
> Sent: Tuesday, December 03, 2024 at 7:15 AM > From: "Greg Wooledge" <greg@wooledge.org> > To: debian-user@lists.debian.org > Subject: Re: From SSD to NVME > > On Tue, Dec 03, 2024 at 12:01:15 +0100, pocket@homemail.com wrote: > > [alarm@alarm ~]$ ls -l / > > lrwxrwxrwx 1 root root 7 Nov 25 19:15 bin -> usr/bin > > drwxr-xr-x 3 root root 4096 Dec 31 1969 boot > > drwxr-xr-x 17 root root 3980 Dec 2 10:38 dev > > drwxr-xr-x 52 root root 4096 Dec 2 20:58 etc > > drwxr-xr-x 3 root root 4096 Aug 19 03:43 home > > lrwxrwxrwx 1 root root 7 Nov 25 19:15 lib -> usr/lib > > drwx------ 2 root root 16384 May 15 2024 lost+found > > drwxr-xr-x 2 root root 4096 Sep 14 12:01 mnt > > drwxr-xr-x 2 root root 4096 Apr 7 2024 opt > > dr-xr-xr-x 247 root root 0 Dec 31 1969 proc > > drwxr-x--- 6 root root 4096 Dec 2 13:06 root > > drwxr-xr-x 22 root root 640 Dec 2 10:38 run > > lrwxrwxrwx 1 root root 7 Nov 25 19:15 sbin -> usr/bin > > drwxr-xr-x 36 root alarm 4096 Nov 29 12:42 srv > > dr-xr-xr-x 12 root root 0 Dec 31 1969 sys > > drwxrwxrwt 13 root root 260 Dec 3 00:00 tmp > > drwxr-xr-x 8 root root 4096 Dec 2 20:58 usr > > drwxr-xr-x 13 root root 4096 Nov 30 17:21 var > > > > Notice sbin is a symlink to /usr/bin > > That's not how Debian 12 has it. > > hobbit:~$ ls -ld /sbin /bin > lrwxrwxrwx 1 root root 7 Feb 17 2024 /bin -> usr/bin/ > lrwxrwxrwx 1 root root 8 Feb 17 2024 /sbin -> usr/sbin/ > > If Trixie has done an "sbin merge", it's news to me. I get it. The above was from an Arch linux server, I do the same on my custom distribution/OS. Why hasn't debian done so? /sbin and /usr/sbin should be sym linked to /usr/bin. In fact on a debian system I make it so........ -- Hindi madali ang maging ako
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2024-12-03 14:00 +0100 |
| Message-ID | <JPAFs-ds8r-9@gated-at.bofh.it> |
| In reply to | #275184 |
pocket@homemail.com (12024-12-03): > Why hasn't debian done so? Because polluting the completion namespace with commands useful once in a blue moon for administrators is a stupid idea. Regards, -- Nicolas George
[toc] | [prev] | [next] | [standalone]
| From | pocket@homemail.com |
|---|---|
| Date | 2024-12-03 14:10 +0100 |
| Message-ID | <JPAP7-dsr5-3@gated-at.bofh.it> |
| In reply to | #275186 |
> Sent: Tuesday, December 03, 2024 at 7:50 AM > From: "Nicolas George" <george@nsup.org> > To: debian-user@lists.debian.org > Subject: Re: From SSD to NVME > > pocket@homemail.com (12024-12-03): > > Why hasn't debian done so? > > Because polluting the completion namespace with commands useful once in > a blue moon for administrators is a stupid idea. What namespace would that be, it's just a filesystem. How so? It doesn't pollute anything. Nothing prevents a user from running anything that is in /sbin or /usr/sbin, except permissions. I am sure the script kiddies won't find any binaries in /sbin /usr/sbin, as they are off limits to a "normal user"..........................
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2024-12-03 14:30 +0100 |
| Message-ID | <JPB8t-dsxI-1@gated-at.bofh.it> |
| In reply to | #275187 |
pocket@homemail.com (12024-12-03): > What namespace would that be I just said it: the namespace for completion. -- Nicolas George
[toc] | [prev] | [next] | [standalone]
| From | pocket@homemail.com |
|---|---|
| Date | 2024-12-03 15:30 +0100 |
| Message-ID | <JPC4x-dt6c-1@gated-at.bofh.it> |
| In reply to | #275188 |
> Sent: Tuesday, December 03, 2024 at 8:22 AM > From: "Nicolas George" <george@nsup.org> > To: debian-user@lists.debian.org > Subject: Re: From SSD to NVME > > pocket@homemail.com (12024-12-03): > > What namespace would that be > > I just said it: the namespace for completion. > > -- > Nicolas George > > [alarm@alarm ~]$ pacman -Q|grep bash bash 5.2.037-1 dpkg -l|grep bash ii bash 5.2.15-2+b7 arm64 GNU Bourne Again SHell How did that happen?
[toc] | [prev] | [next] | [standalone]
| From | Nicolas George <george@nsup.org> |
|---|---|
| Date | 2024-12-03 16:00 +0100 |
| Message-ID | <JPCxz-dtho-27@gated-at.bofh.it> |
| In reply to | #275190 |
pocket@homemail.com (12024-12-03): > [alarm@alarm ~]$ pacman -Q|grep bash > bash 5.2.037-1 > > dpkg -l|grep bash > ii bash 5.2.15-2+b7 arm64 GNU Bourne Again SHell > > How did that happen? I do not know, but unless you start making sense I will just stop answering to you. -- Nicolas George
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@stanis.net> |
|---|---|
| Date | 2024-12-03 15:50 +0100 |
| Message-ID | <JPCnT-dtdC-5@gated-at.bofh.it> |
| In reply to | #275183 |
Greg Wooledge composed on 2024-12-03 07:15 (UTC-0500): > On Tue, Dec 03, 2024 at 12:01:15 +0100, pocket wrote: >> [alarm@alarm ~]$ ls -l / >> lrwxrwxrwx 1 root root 7 Nov 25 19:15 bin -> usr/bin >> drwxr-xr-x 3 root root 4096 Dec 31 1969 boot >> drwxr-xr-x 17 root root 3980 Dec 2 10:38 dev >> drwxr-xr-x 52 root root 4096 Dec 2 20:58 etc >> drwxr-xr-x 3 root root 4096 Aug 19 03:43 home >> lrwxrwxrwx 1 root root 7 Nov 25 19:15 lib -> usr/lib >> drwx------ 2 root root 16384 May 15 2024 lost+found >> drwxr-xr-x 2 root root 4096 Sep 14 12:01 mnt >> drwxr-xr-x 2 root root 4096 Apr 7 2024 opt >> dr-xr-xr-x 247 root root 0 Dec 31 1969 proc >> drwxr-x--- 6 root root 4096 Dec 2 13:06 root >> drwxr-xr-x 22 root root 640 Dec 2 10:38 run >> lrwxrwxrwx 1 root root 7 Nov 25 19:15 sbin -> usr/bin >> drwxr-xr-x 36 root alarm 4096 Nov 29 12:42 srv >> dr-xr-xr-x 12 root root 0 Dec 31 1969 sys >> drwxrwxrwt 13 root root 260 Dec 3 00:00 tmp >> drwxr-xr-x 8 root root 4096 Dec 2 20:58 usr >> drwxr-xr-x 13 root root 4096 Nov 30 17:21 var >> Notice sbin is a symlink to /usr/bin > That's not how Debian 12 has it. > hobbit:~$ ls -ld /sbin /bin > lrwxrwxrwx 1 root root 7 Feb 17 2024 /bin -> usr/bin/ > lrwxrwxrwx 1 root root 8 Feb 17 2024 /sbin -> usr/sbin/ > If Trixie has done an "sbin merge", it's news to me. Bookworm looks to be one of the last of the Mohicans: # grep RETT /etc/os-release PRETTY_NAME="Debian GNU/Linux trixie/sid" # ls -gGh / total 186K lrwxrwxrwx 1 7 Oct 16 2022 bin -> usr/bin drwxr-xr-x 4 5.0K Dec 2 18:29 boot drwxr-xr-x 18 3.8K Dec 3 09:25 dev drwxr-xr-x 110 10K Dec 2 18:28 etc drwxr-xr-x 14 4.0K Dec 1 20:35 home lrwxrwxrwx 1 29 Dec 2 18:28 initrd.img -> boot/initrd.img-6.11.10-amd64 lrwxrwxrwx 1 29 Dec 2 18:28 initrd.img.old -> boot/initrd.img-6.10.12-amd64 lrwxrwxrwx 1 7 Oct 16 2022 lib -> usr/lib lrwxrwxrwx 1 9 Oct 16 2022 lib64 -> usr/lib64 drwx------ 2 12K Jun 24 2018 lost+found drwxr-xr-x 4 1.0K Feb 13 2020 media drwxr-xr-x 2 1.0K Jun 24 2018 mnt drwxr-xr-x 3 1.0K Jun 24 2018 opt dr-xr-xr-x 246 0 Dec 3 04:25 proc drwx------ 17 5.0K Dec 3 09:26 root drwxr-xr-x 22 680 Dec 3 09:25 run lrwxrwxrwx 1 8 Oct 16 2022 sbin -> usr/sbin drwxr-xr-x 2 1.0K Jun 24 2018 srv dr-xr-xr-x 13 0 Dec 3 04:25 sys drwxrwxrwt 9 180 Dec 3 09:26 tmp drwxr-xr-x 12 1.0K Sep 21 2023 usr drwxr-xr-x 11 1.0K Dec 16 2023 var lrwxrwxrwx 1 26 Dec 2 18:28 vmlinuz -> boot/vmlinuz-6.11.10-amd64 lrwxrwxrwx 1 26 Dec 2 18:28 vmlinuz.old -> boot/vmlinuz-6.10.12-amd64 # # grep RETT /etc/os-release PRETTY_NAME="Ubuntu 24.04.1 LTS" # ls -gGh / total 187K lrwxrwxrwx 1 7 Dec 8 2023 bin -> usr/bin drwxr-xr-x 2 1.0K Feb 26 2024 bin.usr-is-merged drwxrwxr-x 4 3.0K Dec 2 22:28 boot drwxr-xr-x 18 4.7K Dec 3 09:34 dev drwxr-xr-x 125 9.0K Dec 2 22:26 etc drwxr-xr-x 14 4.0K Dec 1 20:35 home lrwxrwxrwx 1 32 Dec 2 22:26 initrd.img -> boot/initrd.img-6.8.0-49-generic lrwxrwxrwx 1 32 Dec 2 22:26 initrd.img.old -> boot/initrd.img-6.8.0-45-generic drwxr-xr-x 2 1.0K Jan 22 2019 kicc lrwxrwxrwx 1 7 Dec 8 2023 lib -> usr/lib lrwxrwxrwx 1 9 Dec 8 2023 lib64 -> usr/lib64 drwxr-xr-x 2 1.0K Feb 26 2024 lib.usr-is-merged drwx------ 2 12K Jun 25 2018 lost+found drwxr-xr-x 2 1.0K Jun 26 2018 media drwxr-xr-x 2 1.0K Jun 26 2018 mnt drwxr-xr-x 3 1.0K Jun 26 2018 opt dr-xr-xr-x 260 0 Dec 3 04:34 proc drwxrwxr-x 6 136K Dec 2 22:31 pub drwx------ 19 4.0K Dec 3 09:35 root drwxr-xr-x 22 740 Dec 3 09:35 run lrwxrwxrwx 1 8 Dec 8 2023 sbin -> usr/sbin drwxr-xr-x 2 1.0K Feb 2 2024 sbin.usr-is-merged drwxr-xr-x 2 1.0K Jun 26 2018 srv dr-xr-xr-x 13 0 Dec 3 04:34 sys drwxrwxrwt 8 1.0K Dec 3 09:34 tmp drwxr-xr-x 12 1.0K Dec 8 2023 usr drwxr-xr-x 11 1.0K Mar 20 2024 var lrwxrwxrwx 1 29 Dec 2 22:26 vmlinuz -> boot/vmlinuz-6.8.0-49-generic lrwxrwxrwx 1 29 Dec 2 22:26 vmlinuz.old -> boot/vmlinuz-6.8.0-45-generic # # grep RETT /etc/os-release PRETTY_NAME="KDE neon 6.2" root@ab250:~# ls -gGh / total 187K lrwxrwxrwx 1 7 Jun 2 2024 bin -> usr/bin drwxr-xr-x 2 1.0K Mar 31 2024 bin.usr-is-merged drwxrwxr-x 3 1.0K Oct 10 15:11 boot drwxr-xr-x 19 4.7K Dec 3 09:37 dev drwxr-xr-x 135 10K Dec 2 19:01 etc drwxr-xr-x 14 4.0K Dec 1 20:35 home lrwxrwxrwx 1 32 Oct 10 15:09 initrd.img -> boot/initrd.img-6.8.0-45-generic lrwxrwxrwx 1 32 Oct 10 15:09 initrd.img.old -> boot/initrd.img-6.8.0-38-generic drwxr-xr-x 2 1.0K Jan 22 2019 kicc lrwxrwxrwx 1 7 Jun 2 2024 lib -> usr/lib lrwxrwxrwx 1 9 Jun 2 2024 lib32 -> usr/lib32 lrwxrwxrwx 1 9 Jun 2 2024 lib64 -> usr/lib64 drwxr-xr-x 2 1.0K Apr 7 2024 lib.usr-is-merged lrwxrwxrwx 1 10 Jun 2 2024 libx32 -> usr/libx32 drwx------ 2 12K Jun 25 2018 lost+found drwxr-xr-x 2 1.0K Jun 26 2018 media drwxr-xr-x 2 1.0K Jun 26 2018 mnt drwxr-xr-x 3 1.0K Jun 26 2018 opt dr-xr-xr-x 259 0 Dec 3 04:37 proc drwx------ 18 4.0K Dec 3 09:37 root drwxr-xr-x 27 880 Dec 3 09:37 run lrwxrwxrwx 1 8 Jun 2 2024 sbin -> usr/sbin drwxr-xr-x 2 1.0K Aug 20 2022 sbin.usr-is-merged drwxr-xr-x 2 1.0K Jun 26 2018 srv dr-xr-xr-x 13 0 Dec 3 04:37 sys drwxrwxrwt 8 1.0K Dec 3 09:37 tmp drwxr-xr-x 14 1.0K Jun 2 2024 usr drwxr-xr-x 11 1.0K Jul 22 20:45 var lrwxrwxrwx 1 29 Oct 10 15:09 vmlinuz -> boot/vmlinuz-6.8.0-45-generic lrwxrwxrwx 1 29 Oct 10 15:09 vmlinuz.old -> boot/vmlinuz-6.8.0-38-generic drwx------ 2 1.0K Oct 10 17:51 x-large # # grep RETT /etc/os-release PRETTY_NAME="openSUSE Tumbleweed" # ls -gGh / total 236K lrwxrwxrwx 1 7 Sep 25 15:10 bin -> usr/bin dr-xr-xr-x 4 16K Dec 2 03:00 boot drwxr-xr-x 17 4.5K Dec 3 09:39 dev drwxr-xr-x 102 12K Dec 2 03:03 etc drwxr-xr-x 14 4.0K Dec 1 20:35 home lrwxrwxrwx 1 7 Sep 25 15:10 lib -> usr/lib lrwxrwxrwx 1 9 Sep 25 15:10 lib64 -> usr/lib64 drwx------ 2 16K Jun 20 2018 lost+found dr-xr-xr-x 2 4.0K Jun 21 2018 mnt dr-xr-xr-x 3 4.0K Jun 9 2021 opt dr-xr-xr-x 224 0 Dec 3 04:39 proc drwxrwxr-x 6 136K Dec 2 22:31 pub drwx------ 21 12K Dec 2 03:18 root drwxr-xr-x 28 660 Dec 3 09:39 run lrwxrwxrwx 1 8 Sep 25 15:10 sbin -> usr/sbin dr-xr-xr-x 3 4.0K Jun 9 2021 srv dr-xr-xr-x 13 0 Dec 3 04:39 sys drwxrwxrwt 10 200 Dec 3 09:39 tmp drwxr-xr-x 13 4.0K Sep 25 15:10 usr drwxr-xr-x 10 4.0K Oct 23 20:06 var # # grep RETT /etc/os-release PRETTY_NAME="Fedora Linux 39 (Thirty Nine)" # ls -gGh / total 202K dr-xr-xr-x 2 2.0K Jul 20 2023 afs lrwxrwxrwx 1 7 Jul 20 2023 bin -> usr/bin dr-xr-xr-x 5 6.0K Oct 30 19:14 boot drwxr-xr-x 20 4.4K Dec 3 09:41 dev drwxr-xr-x 111 10K Oct 30 19:12 etc drwxr-xr-x 14 4.0K Dec 1 20:35 home lrwxrwxrwx 1 7 Jul 20 2023 lib -> usr/lib lrwxrwxrwx 1 9 Jul 20 2023 lib64 -> usr/lib64 drwx------ 2 16K Jan 21 2020 lost+found drwxr-xr-x 2 2.0K Jul 20 2023 media drwxr-xr-x 2 2.0K Jul 20 2023 mnt drwxr-xr-x 3 2.0K Jul 20 2023 opt dr-xr-xr-x 224 0 Dec 3 04:41 proc dr-xr-x--- 18 6.0K Dec 3 09:41 root drwxr-xr-x 26 760 Dec 3 09:41 run lrwxrwxrwx 1 8 Jul 20 2023 sbin -> usr/sbin drwxr-xr-x 2 2.0K Jul 20 2023 srv dr-xr-xr-x 13 0 Dec 3 04:41 sys drwxrwxrwt 11 220 Dec 3 09:41 tmp drwxr-xr-x 12 2.0K Sep 20 2023 usr drwxr-xr-x 18 2.0K Sep 20 2023 var # -- 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 | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2024-12-03 20:40 +0100 |
| Message-ID | <JPGUx-dwhL-5@gated-at.bofh.it> |
| In reply to | #275194 |
On Tue, Dec 03, 2024 at 09:44:32 -0500, Felix Miata wrote: > Greg Wooledge composed on 2024-12-03 07:15 (UTC-0500): > > On Tue, Dec 03, 2024 at 12:01:15 +0100, pocket wrote: > >> lrwxrwxrwx 1 root root 7 Nov 25 19:15 sbin -> usr/bin > > That's not how Debian 12 has it. > > > hobbit:~$ ls -ld /sbin /bin > > lrwxrwxrwx 1 root root 7 Feb 17 2024 /bin -> usr/bin/ > > lrwxrwxrwx 1 root root 8 Feb 17 2024 /sbin -> usr/sbin/ > > > If Trixie has done an "sbin merge", it's news to me. Note that pocket's system has /sbin pointing to usr/bin NOT to usr/sbin. > Bookworm looks to be one of the last of the Mohicans: I'm not sure what you mean by that. > PRETTY_NAME="Debian GNU/Linux trixie/sid" > lrwxrwxrwx 1 8 Oct 16 2022 sbin -> usr/sbin > PRETTY_NAME="Ubuntu 24.04.1 LTS" > lrwxrwxrwx 1 8 Dec 8 2023 sbin -> usr/sbin > drwxr-xr-x 2 1.0K Feb 2 2024 sbin.usr-is-merged > PRETTY_NAME="KDE neon 6.2" > lrwxrwxrwx 1 8 Jun 2 2024 sbin -> usr/sbin > drwxr-xr-x 2 1.0K Aug 20 2022 sbin.usr-is-merged > PRETTY_NAME="openSUSE Tumbleweed" > lrwxrwxrwx 1 8 Sep 25 15:10 sbin -> usr/sbin > PRETTY_NAME="Fedora Linux 39 (Thirty Nine)" > lrwxrwxrwx 1 8 Jul 20 2023 sbin -> usr/sbin All of these systems have sbin pointing to usr/sbin (the same as bookworm), NOT to usr/bin the way pocket's system does. pocket's system is the outlier here. It's the only one where there isn't a separate usr/sbin.
[toc] | [prev] | [next] | [standalone]
| From | Andy Smith <andy@strugglers.net> |
|---|---|
| Date | 2024-12-03 20:50 +0100 |
| Message-ID | <JPH4d-dwmb-5@gated-at.bofh.it> |
| In reply to | #275201 |
Hi, On Tue, Dec 03, 2024 at 02:31:14PM -0500, Greg Wooledge wrote: > pocket's system is the outlier here. It's the only one where there > isn't a separate usr/sbin. For some reason pocket keeps telling us on a Debian list things about their Arch Linux system (actually). Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | linux.debian.user
csiph-web