Re: Adding a new boot disk while keeping old disk
On 10/12/2024 06:23, Charlie Gibbs wrote: 1. Do a network install on the new drive; It was advised assuming that you would not do the following, otherwise it is wasting of time: sudo rsync -av /etc /mnt/backup sudo rsync -av /lib /mnt/backup sudo rsync -av /lib64 /mnt/backup sudo rsync -av /sbin /mnt/backup sudo rsync -av /usr /mnt/backup sudo rsync -av /var /mnt/backup Several years ago I successfully cloned Ubuntu (it should not be relevant) from a hdd to a ssd. Though I used more rsync options rsync -aXSHA --numeric-ids --progress -x to ensure that other file attributes are copied. 6. Restore the new drive's /etc/fstab: sudo cp -p ~/etc/fstab /mnt/backup/etc Have you updated fstab to mount partitions from the new drive? Have you created swap? 7. Re-boot from the new drive and cross your fingers. Instead of crossing fingers I would check if more /etc files need update: /etc/crypttab, /etc/default/grub, resume and smartmontools configuration, etc. To make changes effective it is necessary to run some tools (after chroot to new storage): update-grup, update-initramfs. If the system is booted using UEFI you may need to migrate EFI system partition and to update NVRAM (if it is not done by update-grub). The system comes up with an xfce login window, but I can't log in using my regular user ID. Sometimes the screen just goes black, then after a couple of seconds re-displays a blank login screen. Lately, though, I've been getting a window with the message: Xsession: warning: unable to write to /tmp; X session may exit with an error. login as root from console (or connect using ssh) systemctl --failed Inspect for errors journalctl -b To verify that actual files meet dpkg expectations dpkg -V
Re: Subject: Re: Adding a new boot disk while keeping old disk
On Tue 10 Dec 2024 at 15:03:46 (-0800), Charlie Gibbs wrote: > On Tue Dec 10 14:05:20 2024 David Wright wrote: > > > You still haven't said what files cause you concern in /usr/bin/. > > There are a lot of them, e.g. xscreensaver, zip, sox... > > > All the files belonging to Debian's packages are going to be present, > > because you wrote: > > > >>> At this point the old and new systems' root partitions should be > >>> as alike as possible, aside from my own customizations. > > > > That implies you installed the same set of Debian packages as were > > present on the old disk. Right? > > Not quite. See below. > > >> Yes, not even zip is present after an installation from scratch - > >> and apt puts it into /usr/bin. > > > > That's irrelevant: it's just part of Step 1. > > No, it's not. Step 1 was just a basic network install. > I didn't ask for anything extra. Basic. That's a new description of Step 1. But there's obviously a mismatch in our terminology: to me, customizations are things where I deviate from what Debian installs as part of its packages, not just adding packages themselves. Things such as printer queues, email handling, etc, which Debian can't know about. If you use, say, dpkg --get/set-selections to get a closely similar system, you can then run rsync --dry-run to show you where there are differences. > Digging around in some musty old files, I found some post-installation > notes left over from a previous upgrade. Here's an excerpt: > [ … … ] > > Most of that stuff goes into /usr/bin, but it's not put there > by a basic install from scratch. I have to do it manually. Easily automated as above. > And then there are the truly non-standard utilities like xv, > the Seamonkey web browser, and all my Steam games. I was > hoping to find ways to bring all that stuff over in an rsync > or two rather than rebuilding it piece by piece. But that's not /usr/bin/. At least, I assume it's not from what you've told us. /opt/ perhaps. > > But /var/lib/ contains the state of the system, and I would worry that > > any difference in the state of the old disk's system is going to be > > forced onto the new one, even when it's not appropriate. > > Yes, I'm concerned that I'm overwriting parts of the new install > (e.g. in /etc and /var) that should be left alone; that's why I > was saving and restoring /etc/fstab, but there are probably other > things that I missed and one of them is no doubt what's biting me. > On the other tentacle, my Usenet archives are in /var/spool/slrnpull, > and I don't want to lose them. That's where rsync really comes into play. Anyway, good luck with the knee. And you can always plan another migration any time, with the experience you've gained. Cheers, David.
Re: Subject: Re: Adding a new boot disk while keeping old disk
On 12/10/24 15:03, Charlie Gibbs wrote: I think it's time to throw in the towel. The only reason I'm spending so much time on this is that I had knee surgery a few days ago and I'm sitting here at home, not mobile enough to do much else but putter with my machines. But I think I'll just forget about that shiny new NVMe SSD - it was an extra toy I got talked into as part of a motherboard upgrade but it isn't really necessary. My original hard drive is still intact and works perfectly well (albeit a bit slower than the SSD), so I'll just go back to booting from it. If someday my machine has a meltdown and really does need to be rebuilt from scratch, then I'll re-visit the matter. It's sort of like normal system updates/upgrades - usually they work smoothly and I can upgrade from one release to another without touching anything else. But if things really go south (which they have done once or twice in the past, but not often), I have enough backups to put Humpty Dumpty together again - and I'll work the SSD into the re-build. Another option to consider is to do a simple and small install onto the NVME PCIe SSD, install a hypervisor, add a partition and file system to the NVMe PCIe SSD for virtual machines, migrate your old OS disk into a new VM, and run the VM. David
Re: Subject: Re: Adding a new boot disk while keeping old disk
Seems like you are going about this in the most difficult and roundabout way possible. -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: Subject: Re: Adding a new boot disk while keeping old disk
On Tue Dec 10 14:05:20 2024 David Wright wrote: > You still haven't said what files cause you concern in /usr/bin/. There are a lot of them, e.g. xscreensaver, zip, sox... > All the files belonging to Debian's packages are going to be present, > because you wrote: > >>> At this point the old and new systems' root partitions should be >>> as alike as possible, aside from my own customizations. > > That implies you installed the same set of Debian packages as were > present on the old disk. Right? Not quite. See below. >> Yes, not even zip is present after an installation from scratch - >> and apt puts it into /usr/bin. > > That's irrelevant: it's just part of Step 1. No, it's not. Step 1 was just a basic network install. I didn't ask for anything extra. Digging around in some musty old files, I found some post-installation notes left over from a previous upgrade. Here's an excerpt: # apt install zip # apt install libncurses5-dev # apt install openssl # apt install libssl-dev # apt install dosemu # echo 1 > /proc/sys/abi/ldt16 # apt install mplayer # apt install sox # apt install libsox-fmt-mp3 # apt install lame # apt install ntp # apt install rsync # apt install xpdf # apt install xscreensaver # apt install xscreensaver-data # apt install xscreensaver-data # apt install xscreensaver-gl # apt install xscreensaver-gl-extra # apt install xscreensaver-screensaver-bsod Most of that stuff goes into /usr/bin, but it's not put there by a basic install from scratch. I have to do it manually. And then there are the truly non-standard utilities like xv, the Seamonkey web browser, and all my Steam games. I was hoping to find ways to bring all that stuff over in an rsync or two rather than rebuilding it piece by piece. > What worries me is whether anything was copied by Step 5's: > >>> sudo rsync -av /bin /mnt/backup >>> sudo rsync -av /lib /mnt/backup >>> sudo rsync -av /lib64 /mnt/backup >>> sudo rsync -av /sbin /mnt/backup >>> sudo rsync -av /usr /mnt/backup > > That stuff is all Debian's, and everything should already have > been present and correct after Step 1. Much of /etc and /var too. > > But /var/lib/ contains the state of the system, and I would worry that > any difference in the state of the old disk's system is going to be > forced onto the new one, even when it's not appropriate. Yes, I'm concerned that I'm overwriting parts of the new install (e.g. in /etc and /var) that should be left alone; that's why I was saving and restoring /etc/fstab, but there are probably other things that I missed and one of them is no doubt what's biting me. On the other tentacle, my Usenet archives are in /var/spool/slrnpull, and I don't want to lose them. I think it's time to throw in the towel. The only reason I'm spending so much time on this is that I had knee surgery a few days ago and I'm sitting here at home, not mobile enough to do much else but putter with my machines. But I think I'll just forget about that shiny new NVMe SSD - it was an extra toy I got talked into as part of a motherboard upgrade but it isn't really necessary. My original hard drive is still intact and works perfectly well (albeit a bit slower than the SSD), so I'll just go back to booting from it. If someday my machine has a meltdown and really does need to be rebuilt from scratch, then I'll re-visit the matter. It's sort of like normal system updates/upgrades - usually they work smoothly and I can upgrade from one release to another without touching anything else. But if things really go south (which they have done once or twice in the past, but not often), I have enough backups to put Humpty Dumpty together again - and I'll work the SSD into the re-build. Thanks, everyone, for your help. -- /~\ Charlie Gibbs | Life is perverse. \ /| It can be beautiful - X I'm really at ac.dekanfrus | but it won't. / \ if you read it the right way. |-- Lily Tomlin
Re: Subject: Re: Adding a new boot disk while keeping old disk
On Mon 09 Dec 2024 at 21:25:59 (-0800), Charlie Gibbs wrote: > On Mon Dec 9 20:53:54 2024 David Wright wrote: > > On Mon 09 Dec 2024 at 15:23:18 (-0800), Charlie Gibbs wrote: > > > >> Some of you may recall my account of trying to install a new disk (in > >> my case a 1TB NVMe stick) for use as a boot device. There has been > >> another thread or two from other people dealing with the same issue, > >> so it seems to be a hot topic. > >> > >> I'm still unwilling to give up all my installed packages and > >> customizations and rebuild the system from scratch, when all I want > >> to do is copy existing directories to a new boot drive. My own data > >> files all live in /home, a separate partition - no problem there. > >> But many binaries have been installed in places like /usr/bin; their > >> configuration files may or may not be in /home, but I'd rather not > >> lose them wherever they are. > > > > Why "But …"? Aren't most binaries (those that users run, anyway) > > installed in /usr/bin/. > > Yes - and since I have a copy of the old /usr/bin, I should be able > to retain them by simply copying the old /usr over the new one, > rather than having to re-install them one by one. You still haven't said what files cause you concern in /usr/bin/. All the files belonging to Debian's packages are going to be present, because you wrote: > >> At this point the old and new systems' root partitions should be > >> as alike as possible, aside from my own customizations. That implies you installed the same set of Debian packages as were present on the old disk. Right? But… On Mon 09 Dec 2024 at 17:34:08 (-0800), Charlie Gibbs wrote: > On Mon Dec 9 17:25:55 2024 John Hasler wrote: > > Do you mean that you have placed stuff not under control of the > > package management system in /usr/bin? > > No, I've been good about installing things the approved way, That implies that you haven't polluted /usr/bin/ with non-Debian binaries. Is that true? Then why should anything be missing from /usr/bin/? > e.g. > > apt install zip > > Yes, not even zip is present after an installation from scratch - > and apt puts it into /usr/bin. That's irrelevant: it's just part of Step 1. What worries me is whether anything was copied by Step 5's: > >> sudo rsync -av /bin /mnt/backup > >> sudo rsync -av /lib /mnt/backup > >> sudo rsync -av /lib64 /mnt/backup > >> sudo rsync -av /sbin /mnt/backup > >> sudo rsync -av /usr /mnt/backup That stuff is all Debian's, and everything should already have been present and correct after Step 1. Much of /etc and /var too. But /var/lib/ contains the state of the system, and I would worry that any difference in the state of the old disk's system is going to be forced onto the new one, even when it's not appropriate. > >> Here's the process I've been trying so far: > >> > >> 1. Do a network install on the new drive; to be really belt-and- > >> suspenders, make sure everything is completely updated: > >> sudo apt update > >> sudo apt upgrade > >> > >> 2. Re-boot from the original drive and update everything: > >> sudo apt update > >> sudo apt upgrade > >> At this point the old and new systems' root partitions should be > >> as alike as possible, aside from my own customizations. > >> 3. Mount the new drive's root partition somewhere that I can access > >> from the original drive: > >> sudo mount /dev/nvme0n1p2 /mnt/backup > >> > >> 4. Save the new system's /etc/fstab: > >> sudo cp -p /mnt/backup/etc/fstab ~ > >> > >> 5. Copy directories from the original drive to the new drive: > >> sudo rsync -av /bin /mnt/backup > >> sudo rsync -av /etc /mnt/backup > >> sudo rsync -av /lib /mnt/backup > >> sudo rsync -av /lib64 /mnt/backup > >> sudo rsync -av /opt /mnt/backup > >> sudo rsync -av /sbin /mnt/backup > >> sudo rsync -av /usr /mnt/backup > >> sudo rsync -av /var /mnt/backup > >> sudo rsync -av /home /mnt/backup > >> [ … … ] > > I've never used DMs and DEs. Do they squirrel away anything > > with ownerships attached (either by name or number) that might > > be mistranslated, seeing as your two disks likely have different > > ideas on the matter. Others have expressed that better, with talk of attributes and ACLs. Cheers, David.
Re: Adding a new boot disk while keeping old disk
Charlie Gibbs writes: > 5. Copy directories from the original drive to the new drive: > sudo rsync -av /bin /mnt/backup > sudo rsync -av /etc /mnt/backup > sudo rsync -av /lib /mnt/backup > sudo rsync -av /lib64 /mnt/backup > sudo rsync -av /opt /mnt/backup > sudo rsync -av /sbin /mnt/backup > sudo rsync -av /usr /mnt/backup > sudo rsync -av /var /mnt/backup > sudo rsync -av /home /mnt/backup It seems to me there are that things that are not be handled by rsync -a, namely acls and extended attributes and SELINUX context too. At least. >From a little googling it seems GDM at least changes ACLs of some things so maybe that's the problem? Some use of getfacl might show differences in ACLs. I don't really understand the /tmp writing issue though. Anyways, I usually image when cloning drives. Either partition by partition with partclone or whole disk with dd, possibly doing file checksums before and checking after to make sure.
Subject: Re: Adding a new boot disk while keeping old disk
[Sorry about breaking the thread structure - I read this group via Usenet and e-mail replies.] On Mon Dec 9 20:53:54 2024 David Wright wrote: > On Mon 09 Dec 2024 at 15:23:18 (-0800), Charlie Gibbs wrote: > >> Some of you may recall my account of trying to install a new disk (in >> my case a 1TB NVMe stick) for use as a boot device. There has been >> another thread or two from other people dealing with the same issue, >> so it seems to be a hot topic. >> >> I'm still unwilling to give up all my installed packages and >> customizations and rebuild the system from scratch, when all I want >> to do is copy existing directories to a new boot drive. My own data >> files all live in /home, a separate partition - no problem there. >> But many binaries have been installed in places like /usr/bin; their >> configuration files may or may not be in /home, but I'd rather not >> lose them wherever they are. > > Why "But …"? Aren't most binaries (those that users run, anyway) > installed in /usr/bin/. Yes - and since I have a copy of the old /usr/bin, I should be able to retain them by simply copying the old /usr over the new one, rather than having to re-install them one by one. >> Here's the process I've been trying so far: >> >> 1. Do a network install on the new drive; to be really belt-and- >> suspenders, make sure everything is completely updated: >> sudo apt update >> sudo apt upgrade >> >> 2. Re-boot from the original drive and update everything: >> sudo apt update >> sudo apt upgrade >> At this point the old and new systems' root partitions should be >> as alike as possible, aside from my own customizations. > > At that point, I would compare sorted versions of /etc/passwd > and /etc/group from both machines to make sure that they have > matching lists of user/group names. (The numeric IDs can be > different.) Otherwise rsync could mistranslate ownerships. Good point. I'll check out those files. >> 3. Mount the new drive's root partition somewhere that I can access >> from the original drive: >> sudo mount /dev/nvme0n1p2 /mnt/backup >> >> 4. Save the new system's /etc/fstab: >> sudo cp -p /mnt/backup/etc/fstab ~ >> >> 5. Copy directories from the original drive to the new drive: >> sudo rsync -av /bin /mnt/backup >> sudo rsync -av /etc /mnt/backup >> sudo rsync -av /lib /mnt/backup >> sudo rsync -av /lib64 /mnt/backup >> sudo rsync -av /opt /mnt/backup >> sudo rsync -av /sbin /mnt/backup >> sudo rsync -av /usr /mnt/backup >> sudo rsync -av /var /mnt/backup >> sudo rsync -av /home /mnt/backup >> >> 6. Restore the new drive's /etc/fstab: >> sudo cp -p ~/etc/fstab /mnt/backup/etc > ↑ > Where did that file come from? Not step 4. Oops! My bad. That should be sudo cp -p ~/fstab /mnt/backup/etc I'll try it again with the corrected command. >> 7. Re-boot from the new drive and cross your fingers. >> >> The system comes up with an xfce login window, but I can't log in >> using my regular user ID. Sometimes the screen just goes black, >> then after a couple of seconds re-displays a blank login screen. >> Lately, though, I've been getting a window with the message: >> Xsession: warning: unable to write to /tmp; >> X session may exit with an error. >> Clicking on "okay" makes the screen goes black; after a >> couple of seconds it then returns to an empty login screen. >> However, I can log in as root, which suggests some sort >> of permissions issue, but it doesn't seem to be with /tmp: >> >> drwxrwxrwt 12 root root 4096 Dec 9 11:58 tmp >> >> To further muddy the waters, I can SSH in from another machine >> using my regular user ID. >> >> I'd like to resolve this, but if not I can always fall back to the >> original drive. Anybody wanna buy a lightly used 1TB NVMe SSD? > > I've never used DMs and DEs. Do they squirrel away anything > with ownerships attached (either by name or number) that might > be mistranslated, seeing as your two disks likely have different > ideas on the matter. I don't know, but it seems like a good place to look next. Thanks for the hints. I'll run some more tests tomorrow and let you know the results. Right now it's bedtime... -- /~\ Charlie Gibbs | You can't save the earth \ /| unless you're willing to X I'm really at ac.dekanfrus | make other people sacrifice. / \ if you read it the right way. |-- Dogbert the green consultant
Re: Adding a new boot disk while keeping old disk
On Mon 09 Dec 2024 at 15:23:18 (-0800), Charlie Gibbs wrote: > Some of you may recall my account of trying to install a new disk (in > my case a 1TB NVMe stick) for use as a boot device. There has been > another thread or two from other people dealing with the same issue, > so it seems to be a hot topic. > > I'm still unwilling to give up all my installed packages and > customizations and rebuild the system from scratch, when all I want > to do is copy existing directories to a new boot drive. My own data > files all live in /home, a separate partition - no problem there. > But many binaries have been installed in places like /usr/bin; their > configuration files may or may not be in /home, but I'd rather not > lose them wherever they are. Why "But …"? Aren't most binaries (those that users run, anyway) installed in /usr/bin/. > Here's the process I've been trying so far: > > 1. Do a network install on the new drive; to be really belt-and- > suspenders, make sure everything is completely updated: > sudo apt update > sudo apt upgrade > > 2. Re-boot from the original drive and update everything: > sudo apt update > sudo apt upgrade > At this point the old and new systems' root partitions should be > as alike as possible, aside from my own customizations. At that point, I would compare sorted versions of /etc/passwd and /etc/group from both machines to make sure that they have matching lists of user/group names. (The numeric IDs can be different.) Otherwise rsync could mistranslate ownerships. > 3. Mount the new drive's root partition somewhere that I can access > from the original drive: > sudo mount /dev/nvme0n1p2 /mnt/backup > > 4. Save the new system's /etc/fstab: > sudo cp -p /mnt/backup/etc/fstab ~ > > 5. Copy directories from the original drive to the new drive: > sudo rsync -av /bin /mnt/backup > sudo rsync -av /etc /mnt/backup > sudo rsync -av /lib /mnt/backup > sudo rsync -av /lib64 /mnt/backup > sudo rsync -av /opt /mnt/backup > sudo rsync -av /sbin /mnt/backup > sudo rsync -av /usr /mnt/backup > sudo rsync -av /var /mnt/backup > sudo rsync -av /home /mnt/backup > > 6. Restore the new drive's /etc/fstab: > sudo cp -p ~/etc/fstab /mnt/backup/etc ↑ Where did that file come from? Not step 4. > 7. Re-boot from the new drive and cross your fingers. > > The system comes up with an xfce login window, but I can't log in > using my regular user ID. Sometimes the screen just goes black, > then after a couple of seconds re-displays a blank login screen. > Lately, though, I've been getting a window with the message: > Xsession: warning: unable to write to /tmp; > X session may exit with an error. > Clicking on "okay" makes the screen goes black; after a > couple of seconds it then returns to an empty login screen. > However, I can log in as root, which suggests some sort > of permissions issue, but it doesn't seem to be with /tmp: > > drwxrwxrwt 12 root root 4096 Dec 9 11:58 tmp > > To further muddy the waters, I can SSH in from another machine > using my regular user ID. > > I'd like to resolve this, but if not I can always fall back to the > original drive. Anybody wanna buy a lightly used 1TB NVMe SSD? I've never used DMs and DEs. Do they squirrel away anything with ownerships attached (either by name or number) that might be mistranslated, seeing as your two disks likely have different ideas on the matter. Cheers, David.
Re: Adding a new boot disk while keeping old disk
Charlie Gibbs writes: > No, I've been good about installing things the approved way, e.g. > apt install zip Then what files do you think you will lose? > Yes, not even zip is present after an installation from scratch - zip is priority: optional. It won't be installed unless you ask for it. -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: Adding a new boot disk while keeping old disk
On Mon Dec 9 17:25:55 2024 John Hasler wrote: > Charlie Gibbs writes: > >> But many binaries have been installed in places like /usr/bin; their >> configuration files may or may not be in /home, but I'd rather not >> lose them wherever they are. > > Do you mean that you have placed stuff not under control of the > package management system in /usr/bin? No, I've been good about installing things the approved way, e.g. apt install zip Yes, not even zip is present after an installation from scratch - and apt puts it into /usr/bin. -- cgi...@surfnaked.ca (Charlie Gibbs)
Re: Adding a new boot disk while keeping old disk
Charlie Gibbs writes: > But many binaries have been installed in places like /usr/bin; their > configuration files may or may not be in /home, but I'd rather not > lose them wherever they are. Do you mean that you have placed stuff not under control of the package management system in /usr/bin? -- John Hasler j...@sugarbit.com Elmwood, WI USA
Re: Adding a new boot disk while keeping old disk
Some of you may recall my account of trying to install a new disk (in my case a 1TB NVMe stick) for use as a boot device. There has been another thread or two from other people dealing with the same issue, so it seems to be a hot topic. I'm still unwilling to give up all my installed packages and customizations and rebuild the system from scratch, when all I want to do is copy existing directories to a new boot drive. My own data files all live in /home, a separate partition - no problem there. But many binaries have been installed in places like /usr/bin; their configuration files may or may not be in /home, but I'd rather not lose them wherever they are. Here's the process I've been trying so far: 1. Do a network install on the new drive; to be really belt-and- suspenders, make sure everything is completely updated: sudo apt update sudo apt upgrade 2. Re-boot from the original drive and update everything: sudo apt update sudo apt upgrade At this point the old and new systems' root partitions should be as alike as possible, aside from my own customizations. 3. Mount the new drive's root partition somewhere that I can access from the original drive: sudo mount /dev/nvme0n1p2 /mnt/backup 4. Save the new system's /etc/fstab: sudo cp -p /mnt/backup/etc/fstab ~ 5. Copy directories from the original drive to the new drive: sudo rsync -av /bin /mnt/backup sudo rsync -av /etc /mnt/backup sudo rsync -av /lib /mnt/backup sudo rsync -av /lib64 /mnt/backup sudo rsync -av /opt /mnt/backup sudo rsync -av /sbin /mnt/backup sudo rsync -av /usr /mnt/backup sudo rsync -av /var /mnt/backup sudo rsync -av /home /mnt/backup 6. Restore the new drive's /etc/fstab: sudo cp -p ~/etc/fstab /mnt/backup/etc 7. Re-boot from the new drive and cross your fingers. The system comes up with an xfce login window, but I can't log in using my regular user ID. Sometimes the screen just goes black, then after a couple of seconds re-displays a blank login screen. Lately, though, I've been getting a window with the message: Xsession: warning: unable to write to /tmp; X session may exit with an error. Clicking on "okay" makes the screen goes black; after a couple of seconds it then returns to an empty login screen. However, I can log in as root, which suggests some sort of permissions issue, but it doesn't seem to be with /tmp: drwxrwxrwt 12 root root 4096 Dec 9 11:58 tmp To further muddy the waters, I can SSH in from another machine using my regular user ID. I'd like to resolve this, but if not I can always fall back to the original drive. Anybody wanna buy a lightly used 1TB NVMe SSD? -- /~\ Charlie Gibbs | "Some of you may die, \ /| but it's a sacrifice X I'm really at ac.dekanfrus | I'm willing to make." / \ if you read it the right way. |-- Lord Farquaad (Shrek)
Re: Adding a new boot disk while keeping old disk
On 11/26/24 01:03, Charlie Gibbs wrote: > But there are no icons left on the desktop - no more Portal, and none of > the utilities I downloaded were on my $PATH. > > How do the rest of you deal with all the user-added stuff that vanishes > when you do a fresh install? Are there some tricks I can use, rather > than painstakingly re-installing all my utilities one by one? If they were installed through a package manager, you probably shouldn't do that. > I assume you can just copy the old /home over to the new drive Mind the dotfiles. Apps might behave strangely when you run them with an old config file. > But that does nothing about all the nifty utilities that > were in (e.g.) /usr/bin (even though the configuration files are probably > in /home). I hate losing stuff and drastic changes like that, so what I've done in the past when I used Ubuntu was: * do a complete backup * clean-install the latest *-LTS version * restore /home, being careful not to overwrite existing dotfiles * restore any other filesystems that aren't part of the base install * modify /etc/profile.d/* to change $PATH as appropriate * keep the installation as long as possible. The last time I went through this I made a list of installed packages (apt list --installed) so I could re-install (some of) them on the new OS. This probably is not the recommended procedure. Since I switched to Debian the issue hasn't come up, so I haven't yet been forced into a decision as to how to deal with it.
Re: Adding a new boot disk while keeping old disk
On Mon 25 Nov 2024 at 22:03:33 (-0800), Charlie Gibbs wrote: > But, as I expected, all my stuff is gone. Well, sort of. > I plugged the hard drive back in, and all my files are > there. But there are no icons left on the desktop - no > more Portal, and none of the utilities I downloaded were > on my $PATH. > > How do the rest of you deal with all the user-added stuff > that vanishes when you do a fresh install? Are there some > tricks I can use, rather than painstakingly re-installing > all my utilities one by one? I assume you can just copy > the old /home over to the new drive (although in my case > I'll be leaving the big music and video directories on the > spinning rust, to be accessed at a new mount point that I'll > add to /etc/fstab). But that does nothing about all the > nifty utilities that were in (e.g.) /usr/bin (even though > the configuration files are probably in /home). You have the perfect opportunity not to repeat the mistake of scattering these nifty utilities about, whatever they are, or comingling them with the Debian system. Knowing nothing about where you got them, and in what form, you could either repeat installing them, or just copy the binaries across, but keep them separate from Debian by placing them in any of /opt, /usr/local/bin, ~/.local/bin or ~/bin as appropriate. /usr/local/ will already have other subdirectories besides bin/, and you can create similar ones under ~/.local/bin/. Cheers, David.
Re: Adding a new boot disk while keeping old disk
On 11/25/24 22:03, Charlie Gibbs wrote: Many thanks to all of you who have replied to my questions. YW. :-) It seems that I've been creating trouble for myself by trying to kludge something together from the old installation. The only reason I tried this was the age-old problem I have whenever I start from a fresh install: I lose all my customizations and added packages that went into /usr, /var, /etc, etc. :-) It takes a while to put all this stuff back; for a month or so after a fresh install I'm discovering (and re-installing) missing things. I was hoping I could avoid this, but it seems that the time I'm spending on my jury-rigged "solution" more than offsets any savings I might realize. I bit the bullet and downloaded the Debian 12.8 installer to a thumb drive. To be safe, I unplugged the original hard drive to keep it out of harm's way (and to avoid any possible confusion for the installer). Then I deleted all the partitions I was experimenting with on the SSD, and did a fresh install. WOW! Was that ever fast! A complete install in 5 minutes or less! And booting is also lightning-fast. But, as I expected, all my stuff is gone. Well, sort of. I plugged the hard drive back in, and all my files are there. But there are no icons left on the desktop - no more Portal, and none of the utilities I downloaded were on my $PATH. How do the rest of you deal with all the user-added stuff that vanishes when you do a fresh install? Similar to other readers, I use a version control system (CVS) to help me with system administration -- checking in system configuration files I modify or create, keeping a plain text log file of my notes and console sessions, keeping a plain text file containing the names of packages I have installed, checking in various shell and Perl scripts I have written over the years, checking in app configuration and data files, etc.. Then when I do a fresh install, I check out a CVS working directory for the previous incarnation of that machine, or something similar, and use those files to help me configure the new system. AIUI the "top shelf" solution is configuration management systems, such as Puppet, Ansible, etc.. I expect they are necessities in large organization IT environments. Are there some tricks I can use, rather than painstakingly re-installing all my utilities one by one? I take images of my OS disks using dd(1) on a regular basis. So, if I finger fumble and scramble an OS instance, recovery consists of pulling the OS SSD, restoring the last image onto a spare SSD, booting, updating Debian, checking out the appropriate CVS working directories, and merging changes made since the image was taken. I assume you can just copy the old /home over to the new drive (although in my case I'll be leaving the big music and video directories on the spinning rust, to be accessed at a new mount point that I'll add to /etc/fstab). But that does nothing about all the nifty utilities that were in (e.g.) /usr/bin (even though the configuration files are probably in /home). I treat the home tree as part of the OS instance. So, it is incorporated into my image backup/ restore process (above). My home directory contains CVS working directories and whatever files and/or directories Debian and the various apps put there. It is up to us and/or the various app developers to figure out migration, disaster preparedness, disaster recovery, etc., for the various apps we use. I have configured Thunderbird to copy incoming mail to a spare directory on the IMAP server, I have configured Thunderbird to send a BCC of outgoing mail to a spare e-mail account, and I backup the Thunderbird profile directory daily. I use the Firefox "Sync" feature to deal with that app's configuration and data. I have put various app files into CVS projects. For now, though, the box is sort of running. And man, is it a speed demon. Once again, thanks for the assistance. Enjoy. :-) David
Re: Adding a new boot disk while keeping old disk
Charlie Gibbs writes: > How do the rest of you deal with all the user-added stuff > that vanishes when you do a fresh install? I don't do fresh installs as a rule, not when changing hardware or shuffling files around like in your case, or when I wanted to switch from MBR partition table to GPT or when otherwise shuffling partitions around. In fact, I find it weird to see people advocate the Windows way of "if in doubt, reinstall". Linux installations are robust and long lived. In fact, Windows is pretty good too, these days. However, my little pizza box kicked the bucket recently so I got an identical replacement. My backups include the output of dpkg --get-selections "*" as recommended in the Debian release notes so putting all the same packages on the replacement box needed just some apt work. I also save the partition table but in the case of a small system it's not an issue. The system specific stuff in /etc and /home I pulled from backups as well.
Re: Adding a new boot disk while keeping old disk
>> On Tue 26 Nov 2024 at 01:21:31 (-0500), Charlie Gibbs wrote: > > How do the rest of you deal with all the user-added stuff that vanishes > when you do a fresh install? Are there some tricks I can use, rather > than painstakingly re-installing all my utilities one by one? I do two things:- 1 - Keep a simple text list of packages I have added to the system using 'apt install' (or aptitude, or synaptic, or whatever). Then when I do a clean install I can simply add all the extra packages, I suppose I could automate it even but I don't bother doing that. 2 - I have a mercurial repository in /etc, it has an ignore file that, by default, ignores every file in /etc. Then, when I modify something, I first do an 'hg add ' and then do the change and commit it to the repository. I thus have a history (and diffs) of all the changes I have done in /etc. With a new install I make a backup copy of the old /etc and refer to it to make similar changes to the new system. -- Chris Green ·
Re: Adding a new boot disk while keeping old disk
>> On Tue 26 Nov 2024 at 01:21:31 (-0500), Charlie Gibbs wrote:
> How do the rest of you deal with all the user-added stuff that vanishes
> when you do a fresh install? Are there some tricks I can use, rather
> than painstakingly re-installing all my utilities one by one?
I use a filesystem "/dist" to keep various installations I've done:
/dist
| +--i386-pc-solaris2.11
| +--sparc-sun-solaris2.10
| +--x86_64-centos5-linux
| +--x86_64-centos6-linux
| +--x86_64-freebsd-10.4-rel
| +--x86_64-freebsd-11.3-rel
| +--x86_64-oracle6.9-linux
| +--x86_64-oracle6.10-linux
| +--x86_64-oracle7.9-linux
Each system directory (named by architecture and OS-release) contains
a tree like this:
/dist
| +--x86_64-whatever
| | +--bin # original /bin
| | +--boot # original /boot
| | +--etc.orig # original /etc
| | +--etc # /etc with all my changes
| | +--home # interesting parts of $HOME like dotfiles
| | +--lib # original /lib
| | +--libexec # original /libexec, if present
| | +--root # anything I added to root home directory
| | +--sbin # original /sbin
| | +--STIG # STIG software and check results, if any
| | +--usr
| | | +--bin # original /usr/bin
| | | +--lib # original /usr/lib
| | | +--local# anything I installed
| | +--var
| | | +--cron
| | | | +--tabs # scheduled jobs for me, root, etc.
| | | +--log # any /var/log files I created --
# placeholders with owner and permissions
I create this tree when I have a server/workstation I'm happy with,
and I update it when I'm about to retire the system.
The biggest {time,error}-saver was doing this immediately after getting
a bootable system so I can recover from a bad change to an /etc file:
root# mkdir /etc.orig
root# cd /etc
root# find . -print | cpio -pdum /etc.orig
HTH.
--
Karl Vogel I don't speak for anyone but myself
CEO assistant: "please reset CEO's password, he's too drunk to remember it."
--Reddit "unusual IT support tickets", 5 Nov 2024
Re: Adding a new boot disk while keeping old disk
On Tuesday, 26-11-2024 at 17:03 Charlie Gibbs wrote: > Many thanks to all of you who have replied to my questions. > It seems that I've been creating trouble for myself by trying > to kludge something together from the old installation. > The only reason I tried this was the age-old problem I > have whenever I start from a fresh install: I lose all my > customizations and added packages that went into /usr, /var, > /etc, etc. :-) It takes a while to put all this stuff back; > for a month or so after a fresh install I'm discovering (and > re-installing) missing things. I was hoping I could avoid > this, but it seems that the time I'm spending on my jury-rigged > "solution" more than offsets any savings I might realize. > > I bit the bullet and downloaded the Debian 12.8 installer to a > thumb drive. To be safe, I unplugged the original hard drive > to keep it out of harm's way (and to avoid any possible confusion > for the installer). Then I deleted all the partitions I was > experimenting with on the SSD, and did a fresh install. WOW! > Was that ever fast! A complete install in 5 minutes or less! > And booting is also lightning-fast. > > But, as I expected, all my stuff is gone. Well, sort of. > I plugged the hard drive back in, and all my files are > there. But there are no icons left on the desktop - no > more Portal, and none of the utilities I downloaded were > on my $PATH. Linux's libraries and dependencies from your old installs of your "utilities" are likely to be very different to your new Linux environment. I recommend finding current Debian (i.e. Bookworm?) packaged versions, and if they are not in Debian packages, then downloading the Utilities from their respective web sites (if they offer installation instructions for the Debian environment. If these too were not possible, I personally would give up using the "utilities", and where possible finding something that kind of does what they did. Not knowing what your utilities are that you used to run, I can only make broad suggestions, and sorry if some of those "utilities" are very important to you. For me, I give up and move on quicker that some, even if I really miss them. All the best in your efforts, I hope you succeed ! > > How do the rest of you deal with all the user-added stuff > that vanishes when you do a fresh install? Are there some > tricks I can use, rather than painstakingly re-installing > all my utilities one by one? I assume you can just copy > the old /home over to the new drive (although in my case > I'll be leaving the big music and video directories on the > spinning rust, to be accessed at a new mount point that I'll > add to /etc/fstab). If you had spare space, I would be tempted to put a copy of the videos/music that I liked, to the new NVMe. Speed and ease of use. I would keep the HD as a backup. BTW: I still think HDs have less chance of dying and/or loosing data that SDD (inc NVMe SSDs). >But that does nothing about all the > nifty utilities that were in (e.g.) /usr/bin (even though > the configuration files are probably in /home). I would not recommend copying over hidden folder config files unless they were for a specific "utility" that you used to use. I have found conflicts between new installations with configuration files of older installations due to programs changing the way they store their own configurations/data. Even if it means setting things up again, and the waste of time that takes, I prefer to have a stable environment as my first priority. Stability even triumphs over my laziness. > > For now, though, the box is sort of running. And man, is it > a speed demon. Once again, thanks for the assistance. I hope for a nice stable, fast, and reliable Debian system for you (with programs that do what you used to do, whether that be the same utilities you used to use, or some kind of replacement program. George. > > -- > /~\ Charlie Gibbs | Life is perverse. > \ /| It can be beautiful - > X I'm really at ac.dekanfrus | but it won't. > / \ if you read it the right way. |-- Lily Tomlin > >
Re: Adding a new boot disk while keeping old disk
Many thanks to all of you who have replied to my questions. It seems that I've been creating trouble for myself by trying to kludge something together from the old installation. The only reason I tried this was the age-old problem I have whenever I start from a fresh install: I lose all my customizations and added packages that went into /usr, /var, /etc, etc. :-) It takes a while to put all this stuff back; for a month or so after a fresh install I'm discovering (and re-installing) missing things. I was hoping I could avoid this, but it seems that the time I'm spending on my jury-rigged "solution" more than offsets any savings I might realize. I bit the bullet and downloaded the Debian 12.8 installer to a thumb drive. To be safe, I unplugged the original hard drive to keep it out of harm's way (and to avoid any possible confusion for the installer). Then I deleted all the partitions I was experimenting with on the SSD, and did a fresh install. WOW! Was that ever fast! A complete install in 5 minutes or less! And booting is also lightning-fast. But, as I expected, all my stuff is gone. Well, sort of. I plugged the hard drive back in, and all my files are there. But there are no icons left on the desktop - no more Portal, and none of the utilities I downloaded were on my $PATH. How do the rest of you deal with all the user-added stuff that vanishes when you do a fresh install? Are there some tricks I can use, rather than painstakingly re-installing all my utilities one by one? I assume you can just copy the old /home over to the new drive (although in my case I'll be leaving the big music and video directories on the spinning rust, to be accessed at a new mount point that I'll add to /etc/fstab). But that does nothing about all the nifty utilities that were in (e.g.) /usr/bin (even though the configuration files are probably in /home). For now, though, the box is sort of running. And man, is it a speed demon. Once again, thanks for the assistance. -- /~\ Charlie Gibbs | Life is perverse. \ /| It can be beautiful - X I'm really at ac.dekanfrus | but it won't. / \ if you read it the right way. |-- Lily Tomlin
Re: Adding a new boot disk while keeping old disk
On 25/11/2024 23:59, to...@tuxteam.de wrote: On Mon, Nov 25, 2024 at 10:07:35AM -0500, e...@gmx.us wrote: I find PARTLABELs to be a lot more human-friendly than UUIDs. The idea of UUIDs is that they are "unique", so you can run two OS installs automatically without the disk IDs colliding. We leave the collision probability of UUIDs as an exercise for the reader. I recall a couple of reports on this mailing list when data recovery was necessary due to usage of UUIDs. Snapshots have the same filesystem UUID, so some old version may be accidentally mounted during boot. Do not use them in the case of LVM. Certainly FS labels are affected by the same issue. Do not take it wrong, in other cases I still recommend UUID as first option to consider. Specifically to partition UUIDs, sgdisk has an option for cloned drives: -G, --randomize-guids
Re: Adding a new boot disk while keeping old disk
On 11/24/24 17:56, Charlie Gibbs wrote: I have a 20-year-old box which was nonetheless enough to run Debian Bookworm (12.5) - but the video card, equipped with an Nvidia GeForce 610 GPU, was too old. I was getting messages on boot saying that it was only supported by drivers up to version 390, while Bookworm doesn't support drivers that old. You have not mentioned backups or archives. Please do so, if you have not already. A key decision you must make is whether to have one computer (all-in-one) or to have two computers (workstation and file server). Each approach has its advantages and disadvantages. My SOHO installation has a file server, a backup server, many client devices, Gigabit Ethernet, and 802.11ac Wi-Fi. I have an 8-port KVM switch at my primary work area. A newer used video card could make that old motherboard/ CPU/ memory useful again. I would put the new parts in a new case, put the old parts in the old case, buy a KVM switch, and have two working computers. This gives you more options. I recently rebuilt my file server and my backup server using Fractal Design cases and power supplies. I have been very impressed with the quietness and cooling: https://www.fractal-design.com/products/cases/define/define-r5/black/ https://www.fractal-design.com/products/power-supplies/ion/ion-2-platinum-660w/black/ https://www.fractal-design.com/products/fans/venturi/venturi-hf-14/white/ The box was getting flaky on boot anyway, How so? so I figured it was time to spring for a new motherboard, Make and model? complete with an AMD Ryzen 5 processor, Model? 32GB of RAM, and GeForce 1030 video card. I was getting nothing on the screen when I first fired it up, but a friend and I eventually tracked it down to a RAM module that wasn't properly seated. Once we corrected that, the machine happily came up, found the existing hard drive and everything on it, and was fully operational. Things really have progressed since the bad old days. But here's the catch. Since I was laying out the bucks for lots of new hardware anyway, the salesman talked me into throwing in a 1TB NVMe SSD. Make and model? What the heck, might as well really speed things up. However, I want to keep my existing hard drive; it's a fairly new 4TB unit Make and mode? and /home contains large archives of music and video files. What I'd like to do is move everything to the SSD - including the /home partition but without the music and video files, which I'd leave on the spinning rust in a renamed set of directories mounted elsewhere. Rather than doing a full re-install and copying massive amounts of data back and forth, I'm trying to take a shortcut - which may or may not be a good idea, but I'll let you guys judge. Here's the output of lsblk: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 3.6T 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 27.9G 0 part / ├─sda3 8:3 0 7.5G 0 part [SWAP] └─sda4 8:4 0 3.6T 0 part /home sdb 8:16 1 0B 0 disk sdc 8:32 1 0B 0 disk sdd 8:48 1 0B 0 disk sde 8:64 1 0B 0 disk sr0 11:0 1 1024M 0 rom nvme0n1 259:0 0 931.5G 0 disk ├─nvme0n1p1 259:5 0 1M 0 part ├─nvme0n1p2 259:6 0 30G 0 part ├─nvme0n1p3 259:7 0 8G 0 part └─nvme0n1p4 259:8 0 893.5G 0 part As you can see, I've duplicated the partitions on the SSD. I also copied the 30GB / partition to the SSD with dd, and changed the UUID of the copy to avoid conflicts due to the cloning. I mounted /dev/nvme0n1p2 (which I hope to make the new / partition) and changed the UUIDs in its copy of /etc/fstab to point to the partitions on the SSD. I think my problem is getting GRUB to go to the SSD. I tried the following: sudo grub-install /dev/nvme0n1 The following messages came out (with a delay of several seconds between them): Installing for i386-pc platform. Installation finished. No error reported. (Is that first message correct? That sounds like old hardware.) When re-booting, I went into the BIOS screen, and saw that the SSD was first in the boot order. However, this probably doesn't mean much if I didn't get it set up properly. The machine boots, but apparently falls back to the hard drive. The first two lines of dmesg are: [ 0.00] Linux version 6.1.0-23-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) [ 0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-23-amd64 root=UUID=fb2c9cb9-1737-4bbf-b3e8-c5e88b40877e ro quiet According to blkid, that UUID corresponds to /dev/sda2, i.e. the / partition on the hard drive. I'm obviously missing an incantation to make the machine go to the SSD instead. In /boot/grub/grub.cfg I find all sorts of references to the
Re: Adding a new boot disk while keeping old disk
On Tuesday, 26-11-2024 at 02:33 Felix Miata wrote: > David Wright composed on 2024-11-25 09:21 (UTC-0600): > > > On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote: > > >> George at Clug wrote: > > >>> I would create a folder into which to mount the HD's relevant > >>> partition, then used "blkid" to find the UUID and manually added a > >>> mount point to "/etc/fstab". The resulting paths may be a bit ugly, > >>> but I am lazy. > > >> I find PARTLABELs to be a lot more human-friendly than UUIDs. > > > Can you put PARTLABELs on an MBR disk? > > > (I'm not condoning such a disk. I'd take the opportunity to > > switch to UEFI booting from a GPT SSD if that's possible. > > Some explanation of the partitioning would be useful, rather > > that slavishly copying them.) > > I have to think eben wasn't conscious of the difference between PARTLABEL and > LABEL when composing. > > All manual configuration I do involving Linux native filesystems is done using > LABELs, swapspace too. I favor lsblk -f over blkid most of the time. "$ lsblk -f" output is very nice ! Thanks. George. > -- > 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 > >
Re: Adding a new boot disk while keeping old disk
On Mon 25 Nov 2024 at 10:33:35 (-0500), Felix Miata wrote: > David Wright composed on 2024-11-25 09:21 (UTC-0600): > > On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote: > >> George at Clug wrote: > > >>> I would create a folder into which to mount the HD's relevant > >>> partition, then used "blkid" to find the UUID and manually added a > >>> mount point to "/etc/fstab". The resulting paths may be a bit ugly, > >>> but I am lazy. > > >> I find PARTLABELs to be a lot more human-friendly than UUIDs. > > > Can you put PARTLABELs on an MBR disk? > > > (I'm not condoning such a disk. I'd take the opportunity to > > switch to UEFI booting from a GPT SSD if that's possible. > > Some explanation of the partitioning would be useful, rather > > that slavishly copying them.) > > I have to think eben wasn't conscious of the difference between PARTLABEL and > LABEL when composing. My comment was more for the benefit of the OP, who's the one actually configuring their system. AFAICT they're sticking with BIOS booting and MBR partitions. > All manual configuration I do involving Linux native filesystems is done using > LABELs, swapspace too. I favor lsblk -f over blkid most of the time. Same here, but with one exception of course: encrypted partitions, which are selected by PARTLABEL. On Mon 25 Nov 2024 at 12:24:57 (-0500), eben wrote: > On 11/25/24 10:21, David Wright wrote: > > Can you put PARTLABELs on an MBR disk? The question mark is there because the evidence for the OP having an MBR disk is entirely circumstantial. IOW I'm guessing. > Ah, apparently you have to use LABEL, but otherwise yes, at least in fstab: You can use pretty much anything that points to the particular device in fstab besides /dev/sdXN: LABEL, PARTLABEL, UUID and PARTUUID having the keyword syntax, or any of the symlinks, like /dev/disk/by-foo/bar, that point to the device file. > eben@cerberus:~$ sudo fdisk -l /dev/sdc | grep label > Disklabel type: dos > > eben@cerberus:~$ sudo blkid /dev/sdc1 > /dev/sdc1: LABEL="Partition_1" UUID="ab7e9bee-27f4-4f4f-94c4-5d19d8413074" > BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b1604273-01" > > eben@cerberus:~$ grep Partition_1 /etc/fstab > LABEL=Partition_1 /mnt/temp2 ext4default A few things to notice: No PARTLABEL on MBR disks. A GPT PARTLABEL string would be 4½× too large to fit within the entire partition table entry on an MBR disk. The PARTUUID is AFAIK not stable, being a made up string generated from the Disk ID and the partition number. It's not clear to me whether that number is the maybe-stable slot number for a primary partition, or something else; and what sort of chaos arises within an extended partition. When used about MBR disks, the term Partition Label doesn't mean a PARTLABEL, but a Filesystem LABEL, coined when partitions weren't named/labelled. Cheers, David.
Re: Adding a new boot disk while keeping old disk
Greg Wooledge composed on 2024-11-25 17:50 (UTC-0500): > Given that you dd-copied a file system, you might consider changing > the UUID of the new copy. Assuming this is an ext4 file system, > tune2fs(8) has a -U option that looks like it should do the job. > Specifically, "-U random" looks promising, though I haven't tested it. Well tested here: # grep U .bash_history | head -1 tune2fs -U random -L p20deb12 /dev/sda20 # grep U .bash_history | wc -l 42 # Another PC: # grep U .bash_history | wc -l 34 # grep U .bash_history | head -1 tune2fs -U random -L p13trixie /dev/sda13 # I've been getting rid of 128 byte inode filesystems lately in long term prep for 2038 32bit time rollover. -- 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
Re: Adding a new boot disk while keeping old disk
On Mon, Nov 25, 2024 at 17:37:28 -0500, e...@gmx.us wrote: > I'm not Thomas, but here you go. If you do > > dd if=/dev/sda1 of=/dev/sdb1 > > to copy sda1 to sdb1, they get the same UUID. Which makes one question the > Uniqueness part. I ran into that, and my solution was to use the actual > device names everywhere, something of the sdXY format. Which worked great > until I installed Debian, and something in the boot process makes the names > switch randomly. Using "sda1" in fstab is a bad idea, for exactly the reasons you discovered the hard way. The names will not necessarily be assigned to the same devices each time you boot. Given that you dd-copied a file system, you might consider changing the UUID of the new copy. Assuming this is an ext4 file system, tune2fs(8) has a -U option that looks like it should do the job. Specifically, "-U random" looks promising, though I haven't tested it. If it's not ext4, then consult your documentation for whichever type of file system this is.
Re: Adding a new boot disk while keeping old disk
On 11/25/24 12:36, Default User wrote: > > Thomas, would you mind elaborating on, or give a link to an > explanation of: > > "Of course, this UUID uniqueness thing starts looking ever more > flimsy once you start bit-copying file systems . . . " > > I'm not sure I understand what bit-copying of file systems is, > and why it would be flimsy. I'm not Thomas, but here you go. If you do dd if=/dev/sda1 of=/dev/sdb1 to copy sda1 to sdb1, they get the same UUID. Which makes one question the Uniqueness part. I ran into that, and my solution was to use the actual device names everywhere, something of the sdXY format. Which worked great until I installed Debian, and something in the boot process makes the names switch randomly.
Re: Adding a new boot disk while keeping old disk
I am not sure, what you are intend to do. If you want a new bootable harddrive, I suggest, to clone the old (maybe smaller one) to the new one using clonezilla. After it you can resize the partitions of new one to your needs and then mount the old one to any folder you want (maybe "/space" or "/data", whatever) Or just format it. If you then want it automatically mounted, I suggest, to enter the device (like "/dev/sdc1") into /etc/fstab, but the UUID. If you are using the devicename, it may happen when several harrdtrives, the BIOS will not recognize the correct order. So /dev/sdc1 is /dev/sdd1 suddenly. (I have 4 harddrives in my computer and ran in this issue) Using UUID will avoid this. An entry in /etc/fstab would then look like this: UUID=X----X /homeext4defaults0 Just an example. Dunno, if it is that, what you want. If not, just ignore my mail. Best Hans
Re: Adding a new boot disk while keeping old disk
On Mon, 2024-11-25 at 18:59 +0100, to...@tuxteam.de wrote: > On Mon, Nov 25, 2024 at 12:36:55PM -0500, Default User wrote: > > [...] > > > Thomas, would you mind elaborating on, or give a link to an > > explanation of: > > > > "Of course, this UUID uniqueness thing starts looking ever more > > flimsy once you start bit-copying file systems . . . " > > > > I'm not sure I understand what bit-copying of file systems is, > > and why it would be flimsy. > > It's more trivial than it seems. If you copy a whole file system > bit-for-bit (e.g. with dd or similar), since the UUID is "in there", > it travels along. Now you have two identical file systems with the > same UUID. > > If you now, for example, mount one and write things to it, you have > two different file systems with the same UUID. > > Cheers Okay, got it. Thanks!
Re: Adding a new boot disk while keeping old disk
On Mon, Nov 25, 2024 at 12:36:55PM -0500, Default User wrote: [...] > Thomas, would you mind elaborating on, or give a link to an > explanation of: > > "Of course, this UUID uniqueness thing starts looking ever more > flimsy once you start bit-copying file systems . . . " > > I'm not sure I understand what bit-copying of file systems is, > and why it would be flimsy. It's more trivial than it seems. If you copy a whole file system bit-for-bit (e.g. with dd or similar), since the UUID is "in there", it travels along. Now you have two identical file systems with the same UUID. If you now, for example, mount one and write things to it, you have two different file systems with the same UUID. Cheers -- t signature.asc Description: PGP signature
Re: Adding a new boot disk while keeping old disk
On Mon, 2024-11-25 at 17:59 +0100, to...@tuxteam.de wrote: > On Mon, Nov 25, 2024 at 10:07:35AM -0500, e...@gmx.us wrote: > > On 11/25/24 02:26, George at Clug wrote: > > > I would create a folder into which to mount the HD's relevant > > > partition, then used "blkid" to find the UUID and manually added > > > a > > > mount point to "/etc/fstab". The resulting paths may be a bit > > > ugly, > > > but I am lazy. > > > > I find PARTLABELs to be a lot more human-friendly than UUIDs. > > As Felix pointed out in this thread, you're possibly talking about > (file system) LABELS. The idea of UUIDs is that they are "unique", > so you can run two OS installs automatically without the disk IDs > colliding. We leave the collision probability of UUIDs as an exercise > for the reader. Suffice it to say that the probability of /very > weird/ things happening (let alone an alpha particle flipping a few > bits in your RAM) is higher than a UUID collision. > > A label is something you come up to slap onto something. So using > the same label is most of the time intended. > > Of course, this UUID uniqueness thing starts looking ever more > flimsy once you start bit-copying file systems (people do this! > I know I do!). > > Civilised file systems have a slot for each, so you can use both > of them, at the same time, for different purposes. > > Cheers Thomas, would you mind elaborating on, or give a link to an explanation of: "Of course, this UUID uniqueness thing starts looking ever more flimsy once you start bit-copying file systems . . . " I'm not sure I understand what bit-copying of file systems is, and why it would be flimsy.
Re: Adding a new boot disk while keeping old disk
On 11/25/24 10:21, David Wright wrote: > On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote: >> On 11/25/24 02:26, George at Clug wrote: >>> I would create a folder into which to mount the HD's relevant >>> partition, then used "blkid" to find the UUID and manually added a >>> mount point to "/etc/fstab". The resulting paths may be a bit ugly, >>> but I am lazy. >> >> I find PARTLABELs to be a lot more human-friendly than UUIDs. > > Can you put PARTLABELs on an MBR disk? Ah, apparently you have to use LABEL, but otherwise yes, at least in fstab: eben@cerberus:~$ sudo fdisk -l /dev/sdc | grep label Disklabel type: dos eben@cerberus:~$ sudo blkid /dev/sdc1 /dev/sdc1: LABEL="Partition_1" UUID="ab7e9bee-27f4-4f4f-94c4-5d19d8413074" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b1604273-01" eben@cerberus:~$ grep Partition_1 /etc/fstab LABEL=Partition_1 /mnt/temp2 ext4 defaults,noauto 0 0 eben@cerberus:~$ mount | grep temp2 eben@cerberus:~$ sudo mount /mnt/temp2 eben@cerberus:~$ mount | grep temp2 /dev/sdc1 on /mnt/temp2 type ext4 (rw,relatime,stripe=8191) > (I'm not condoning such a disk. I'd take the opportunity to > switch to UEFI booting from a GPT SSD if that's possible. > Some explanation of the partitioning would be useful, rather > that slavishly copying them.) I repartitioned in GPT because the 4 partition limit in MBR without jumping through hoops made them hard to deal with. My motherboard doesn't boot in UEFI, but still.
Re: Adding a new boot disk while keeping old disk
On Mon, Nov 25, 2024 at 10:07:35AM -0500, e...@gmx.us wrote: > On 11/25/24 02:26, George at Clug wrote: > > I would create a folder into which to mount the HD's relevant > > partition, then used "blkid" to find the UUID and manually added a > > mount point to "/etc/fstab". The resulting paths may be a bit ugly, > > but I am lazy. > > I find PARTLABELs to be a lot more human-friendly than UUIDs. As Felix pointed out in this thread, you're possibly talking about (file system) LABELS. The idea of UUIDs is that they are "unique", so you can run two OS installs automatically without the disk IDs colliding. We leave the collision probability of UUIDs as an exercise for the reader. Suffice it to say that the probability of /very weird/ things happening (let alone an alpha particle flipping a few bits in your RAM) is higher than a UUID collision. A label is something you come up to slap onto something. So using the same label is most of the time intended. Of course, this UUID uniqueness thing starts looking ever more flimsy once you start bit-copying file systems (people do this! I know I do!). Civilised file systems have a slot for each, so you can use both of them, at the same time, for different purposes. Cheers -- t signature.asc Description: PGP signature
Re: Adding a new boot disk while keeping old disk
David Wright composed on 2024-11-25 09:21 (UTC-0600): > On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote: >> George at Clug wrote: >>> I would create a folder into which to mount the HD's relevant >>> partition, then used "blkid" to find the UUID and manually added a >>> mount point to "/etc/fstab". The resulting paths may be a bit ugly, >>> but I am lazy. >> I find PARTLABELs to be a lot more human-friendly than UUIDs. > Can you put PARTLABELs on an MBR disk? > (I'm not condoning such a disk. I'd take the opportunity to > switch to UEFI booting from a GPT SSD if that's possible. > Some explanation of the partitioning would be useful, rather > that slavishly copying them.) I have to think eben wasn't conscious of the difference between PARTLABEL and LABEL when composing. All manual configuration I do involving Linux native filesystems is done using LABELs, swapspace too. I favor lsblk -f over blkid most of the time. -- 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
Re: Adding a new boot disk while keeping old disk
On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote: > On 11/25/24 02:26, George at Clug wrote: > > I would create a folder into which to mount the HD's relevant > > partition, then used "blkid" to find the UUID and manually added a > > mount point to "/etc/fstab". The resulting paths may be a bit ugly, > > but I am lazy. > > I find PARTLABELs to be a lot more human-friendly than UUIDs. Can you put PARTLABELs on an MBR disk? (I'm not condoning such a disk. I'd take the opportunity to switch to UEFI booting from a GPT SSD if that's possible. Some explanation of the partitioning would be useful, rather that slavishly copying them.) Cheers, David.
Re: Adding a new boot disk while keeping old disk
On 11/25/24 02:26, George at Clug wrote: > I would create a folder into which to mount the HD's relevant > partition, then used "blkid" to find the UUID and manually added a > mount point to "/etc/fstab". The resulting paths may be a bit ugly, > but I am lazy. I find PARTLABELs to be a lot more human-friendly than UUIDs.
Re: Adding a new boot disk while keeping old disk
On Sun, 24 Nov 2024 17:56:25 -0800 Charlie Gibbs wrote: > > When re-booting, I went into the BIOS screen, and saw that the SSD was > first in the boot order. However, this probably doesn't mean much if > I didn't get it set up properly. The machine boots, but apparently > falls back to the hard drive.[...] > > According to blkid, that UUID corresponds to /dev/sda2, i.e. the / > partition on the hard drive. I'm obviously missing an incantation > to make the machine go to the SSD instead. In /boot/grub/grub.cfg > I find all sorts of references to the UUID of /dev/sda2, but the > file starts with a big scary "DO NOT EDIT THIS FILE" message. I've seen this problem recently on an amd64 architechture machine. You do not have to edit this file. Since your HDD is large, your system is likely to boot UEFI. Check whether there is an EFI partition - the 1M partitions are a good candidate. Check your grub package to support this: grub-efi-amd64 The package grub-pc will be removed, when you install that one. Inside a chroot install grub with a mounted EFI partition (e.g. to /boot/efi relative to the chroot environment) with something like: grub-install --target=x86_64-efi --efi-directory=/boot/efi The classic GRUB package and install will write to disk, but the UEFI firmware might not be able to boot that. BTST HTH kind regards Frank
Re: Adding a new boot disk while keeping old disk
On Sun, Nov 24, 2024 at 05:56:25PM -0800, Charlie Gibbs wrote: > I have a 20-year-old box which was nonetheless enough to run Debian > Bookworm (12.5) - but the video card, equipped with an Nvidia GeForce > 610 GPU, was too old. I was getting messages on boot saying that it > was only supported by drivers up to version 390, while Bookworm doesn't > support drivers that old. > Fair enough: at 20 years old - that might also explain the flakiness on boot you mentioned. > Good to hear that you got an operational machine second try :) > > But here's the catch. Since I was laying out the bucks for lots of new > hardware anyway, the salesman talked me into throwing in a 1TB NVMe SSD. > What the heck, might as well really speed things up. However, I want > to keep my existing hard drive; it's a fairly new 4TB unit and /home > contains large archives of music and video files. What I'd like to > do is move everything to the SSD - including the /home partition but > without the music and video files, which I'd leave on the spinning rust > in a renamed set of directories mounted elsewhere. > > Rather than doing a full re-install and copying massive amounts of data > back and forth, I'm trying to take a shortcut - which may or may not be > a good idea, but I'll let you guys judge. > No - REALLY don't do that - a reinstall will be quicker, especially since I see you were using legacy MBR install rather than UEFI (if that's how I interpreted the installation of grub-pc.) Do an install to the 1TB NVME using AMD64 media. Do it using LVM. Maybe use the expert install to allow you more flexibility in partitioning. If what you want to keep from your old /home is small, just copy it across as a directory called /oldhome and delete it once you're happy. [Dotfiles, some configs] Don't forget mail from /var or wherever your mail was stored. On the 4TB spinner, make a mount point called /data and move the music and video files across to sit under it. . Optionally, at some point, repartition the 4TB for everything other than the music data amd make another LVM volume for use. Maybe you want to keep a smaller swap partition on the spinning disk rather than swapping onto NVME but that's a choice. > Here's the output of lsblk: > > NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > sda 8:00 3.6T 0 disk > ├─sda18:10 1M 0 part > ├─sda28:20 27.9G 0 part / > ├─sda38:30 7.5G 0 part [SWAP] > └─sda48:40 3.6T 0 part /home > sdb 8:16 1 0B 0 disk > sdc 8:32 1 0B 0 disk > sdd 8:48 1 0B 0 disk > sde 8:64 1 0B 0 disk > sr0 11:01 1024M 0 rom > nvme0n1 259:00 931.5G 0 disk > ├─nvme0n1p1 259:50 1M 0 part > ├─nvme0n1p2 259:6030G 0 part > ├─nvme0n1p3 259:70 8G 0 part > └─nvme0n1p4 259:80 893.5G 0 part > > As you can see, I've duplicated the partitions on the SSD. I also > copied the 30GB / partition to the SSD with dd, and changed the > UUID of the copy to avoid conflicts due to the cloning. I mounted > /dev/nvme0n1p2 (which I hope to make the new / partition) and > changed the UUIDs in its copy of /etc/fstab to point to the > partitions on the SSD. > Copying with dd just means that you've copied a chunk - it may not be aligned. > I think my problem is getting GRUB to go to the SSD. I tried the > following: > > sudo grub-install /dev/nvme0n1 > > The following messages came out (with a delay of several seconds between > them): > > Installing for i386-pc platform. > Installation finished. No error reported. > > (Is that first message correct? That sounds like old hardware.) > That's problematic, I think. > When re-booting, I went into the BIOS screen, and saw that the SSD was > first in the boot order. However, this probably doesn't mean much if > I didn't get it set up properly. The machine boots, but apparently > falls back to the hard drive. The first two lines of dmesg are: > > [0.00] Linux version 6.1.0-23-amd64 (debian-ker...@lists.debian.org) > (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 > SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-23-amd64 > root=UUID=fb2c9cb9-1737-4bbf-b3e8-c5e88b40877e ro quiet > > According to blkid, that UUID corresponds to /dev/sda2, i.e. the / > partition on the hard drive. I'm obviously missing an incantation > to make the machine go to the SSD instead. In /boot/grub/grub.cfg > I find all sorts of references to the UUID of /dev/sda2, but the > file starts with a big scary "DO NOT EDIT THIS FILE" message. > > I've been looking up GRUB documentation, but my eyes are starting to > glaze over. I get the feeling that I'm close, but don't quite have > the GRUB fu. Could someone provide some pointers? In some sense, all you have to safeguard is your music and video fil
Re: Adding a new boot disk while keeping old disk
Charlie, I think this is what you are looking for (and what I use). # nano /etc/default/grub https://wiki.debian.org/Grub The configuration file is /boot/grub/grub.cfg, but you shouldn't edit it directly. This file is generated by grub v2's update-grub(8)... To configure grub "v2", you should edit /etc/default/grub, then run update-grub. You are far more adventurous than myself. I would have unpluged the HD, install an nice clean, fresh Debian Linux to the nice new NVMe, then after the installation worked well, plugged in the HD and mounted it through the GUI. If I got frustrated mounting the drive frequently, I would create a folder into which to mount the HD's relevant partition, then used "blkid" to find the UUID and manually added a mount point to "/etc/fstab". The resulting paths may be a bit ugly, but I am lazy. In /etc/fstab add entry something like, depending on what ext or other format your drive is: UUID=ecbf69dd-e238-42f4-9ee9-043044cc0953 /home/[username]/videos/HD ext4 defaults,noatime 0 2 I hope the "nano /etc/default/grub" info helps? As far as changing the UUIDs in "/etc/default/grub", that is not something I bother to do, so I am not much help in that regard. Good luck on your efforts ! George. On Monday, 25-11-2024 at 12:56 Charlie Gibbs wrote: > I have a 20-year-old box which was nonetheless enough to run Debian > Bookworm (12.5) - but the video card, equipped with an Nvidia GeForce > 610 GPU, was too old. I was getting messages on boot saying that it > was only supported by drivers up to version 390, while Bookworm doesn't > support drivers that old. > > The box was getting flaky on boot anyway, so I figured it was time to > spring for a new motherboard, complete with an AMD Ryzen 5 processor, > 32GB of RAM, and GeForce 1030 video card. > > I was getting nothing on the screen when I first fired it up, but a > friend and I eventually tracked it down to a RAM module that wasn't > properly seated. Once we corrected that, the machine happily came up, > found the existing hard drive and everything on it, and was fully > operational. Things really have progressed since the bad old days. > > But here's the catch. Since I was laying out the bucks for lots of new > hardware anyway, the salesman talked me into throwing in a 1TB NVMe SSD. > What the heck, might as well really speed things up. However, I want > to keep my existing hard drive; it's a fairly new 4TB unit and /home > contains large archives of music and video files. What I'd like to > do is move everything to the SSD - including the /home partition but > without the music and video files, which I'd leave on the spinning rust > in a renamed set of directories mounted elsewhere. > > Rather than doing a full re-install and copying massive amounts of data > back and forth, I'm trying to take a shortcut - which may or may not be > a good idea, but I'll let you guys judge. > > Here's the output of lsblk: > > NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > sda 8:00 3.6T 0 disk > ├─sda18:10 1M 0 part > ├─sda28:20 27.9G 0 part / > ├─sda38:30 7.5G 0 part [SWAP] > └─sda48:40 3.6T 0 part /home > sdb 8:16 1 0B 0 disk > sdc 8:32 1 0B 0 disk > sdd 8:48 1 0B 0 disk > sde 8:64 1 0B 0 disk > sr0 11:01 1024M 0 rom > nvme0n1 259:00 931.5G 0 disk > ├─nvme0n1p1 259:50 1M 0 part > ├─nvme0n1p2 259:6030G 0 part > ├─nvme0n1p3 259:70 8G 0 part > └─nvme0n1p4 259:80 893.5G 0 part > > As you can see, I've duplicated the partitions on the SSD. I also > copied the 30GB / partition to the SSD with dd, and changed the > UUID of the copy to avoid conflicts due to the cloning. I mounted > /dev/nvme0n1p2 (which I hope to make the new / partition) and > changed the UUIDs in its copy of /etc/fstab to point to the > partitions on the SSD. > > I think my problem is getting GRUB to go to the SSD. I tried the > following: > > sudo grub-install /dev/nvme0n1 > > The following messages came out (with a delay of several seconds between > them): > > Installing for i386-pc platform. > Installation finished. No error reported. > > (Is that first message correct? That sounds like old hardware.) > > When re-booting, I went into the BIOS screen, and saw that the SSD was > first in the boot order. However, this probably doesn't mean much if > I didn't get it set up properly. The machine boots, but apparently > falls back to the hard drive. The first two lines of dmesg are: > > [0.00] Linux version 6.1.0-23-amd64 > (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU > ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian > 6.1.99-1 (2024-07-15) > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-23-amd64 > root=UUID=fb2c9cb9-1737-4bbf-b3e8-c5e88b4087
Adding a new boot disk while keeping old disk
I have a 20-year-old box which was nonetheless enough to run Debian Bookworm (12.5) - but the video card, equipped with an Nvidia GeForce 610 GPU, was too old. I was getting messages on boot saying that it was only supported by drivers up to version 390, while Bookworm doesn't support drivers that old. The box was getting flaky on boot anyway, so I figured it was time to spring for a new motherboard, complete with an AMD Ryzen 5 processor, 32GB of RAM, and GeForce 1030 video card. I was getting nothing on the screen when I first fired it up, but a friend and I eventually tracked it down to a RAM module that wasn't properly seated. Once we corrected that, the machine happily came up, found the existing hard drive and everything on it, and was fully operational. Things really have progressed since the bad old days. But here's the catch. Since I was laying out the bucks for lots of new hardware anyway, the salesman talked me into throwing in a 1TB NVMe SSD. What the heck, might as well really speed things up. However, I want to keep my existing hard drive; it's a fairly new 4TB unit and /home contains large archives of music and video files. What I'd like to do is move everything to the SSD - including the /home partition but without the music and video files, which I'd leave on the spinning rust in a renamed set of directories mounted elsewhere. Rather than doing a full re-install and copying massive amounts of data back and forth, I'm trying to take a shortcut - which may or may not be a good idea, but I'll let you guys judge. Here's the output of lsblk: NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:00 3.6T 0 disk ├─sda18:10 1M 0 part ├─sda28:20 27.9G 0 part / ├─sda38:30 7.5G 0 part [SWAP] └─sda48:40 3.6T 0 part /home sdb 8:16 1 0B 0 disk sdc 8:32 1 0B 0 disk sdd 8:48 1 0B 0 disk sde 8:64 1 0B 0 disk sr0 11:01 1024M 0 rom nvme0n1 259:00 931.5G 0 disk ├─nvme0n1p1 259:50 1M 0 part ├─nvme0n1p2 259:6030G 0 part ├─nvme0n1p3 259:70 8G 0 part └─nvme0n1p4 259:80 893.5G 0 part As you can see, I've duplicated the partitions on the SSD. I also copied the 30GB / partition to the SSD with dd, and changed the UUID of the copy to avoid conflicts due to the cloning. I mounted /dev/nvme0n1p2 (which I hope to make the new / partition) and changed the UUIDs in its copy of /etc/fstab to point to the partitions on the SSD. I think my problem is getting GRUB to go to the SSD. I tried the following: sudo grub-install /dev/nvme0n1 The following messages came out (with a delay of several seconds between them): Installing for i386-pc platform. Installation finished. No error reported. (Is that first message correct? That sounds like old hardware.) When re-booting, I went into the BIOS screen, and saw that the SSD was first in the boot order. However, this probably doesn't mean much if I didn't get it set up properly. The machine boots, but apparently falls back to the hard drive. The first two lines of dmesg are: [0.00] Linux version 6.1.0-23-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-23-amd64 root=UUID=fb2c9cb9-1737-4bbf-b3e8-c5e88b40877e ro quiet According to blkid, that UUID corresponds to /dev/sda2, i.e. the / partition on the hard drive. I'm obviously missing an incantation to make the machine go to the SSD instead. In /boot/grub/grub.cfg I find all sorts of references to the UUID of /dev/sda2, but the file starts with a big scary "DO NOT EDIT THIS FILE" message. I've been looking up GRUB documentation, but my eyes are starting to glaze over. I get the feeling that I'm close, but don't quite have the GRUB fu. Could someone provide some pointers? -- /~\ Charlie Gibbs | We'll go down in history as \ /| the first society that wouldn't X I'm really at ac.dekanfrus | save itself because it wasn't / \ if you read it the right way. | cost-effective. -- Kurt Vonnegut
