On 11/3/22 06:51, David T-G wrote:
Dennis, et al --
...and then DennisG said... % % On 10/30/22 16:06, David T-G wrote: % % > I have no interest in loading lots of other candidate OSes (unles the % > whole "containerized" thing blows up, anyway ;-) but instead just want to % > be able to practice an upgrade migration on a copy ("next") while % > retaining the ability to go back to the old ("prev") instance. % % Oh my. I had written a rather lengthy reply but when I got to the last % paragraph, I deleted it all. Clearly I must be missing something . . .
Sorry for the confusion :-( I admit that I must be weird to want just SuSE on the box and have a bunch of disks in there. It's a poor man's server for home.
% % Let me get this straight: One disk only, with one instance of openSUSE % which is your production system and a second instance of openSUSE which you % want to be a copy to test upgrading on? That's the extent of it?
Wellll ... The original config is one swap/boot/boot/home device and everything else is data. I'd *like* a MIRRORED swap/boot/boot/home device for fault tolerance, which brings us to two disks [of interest]. But, yeah, that's pretty much it.
% % If so, why wouldn't you just do a clean install on one partition and then % make a snapshot copy on to an identical partition for testing upgrades when % the time comes? Why all the business with RAID/mirroring/containers? Or % the second disk (although having your test copy on a second disk might make % this a bit easier)?
The only RAID is for mirroring. I'm not doing anything with containers. Heck, I don't even know how to create and run a VM, and I've had that on my to-do list for five years and haven't had a chance to look at a single man page or HOWTO!
% % If you suspect dirty bits or bad pointers for whatever reason, use dd to % zero out the first 10MB on the disk, starting with the first sector. That % will clear anything in the MBR or the "bios boot" sectors (which is NOT the % same as a traditional /boot partition or an efi partition) in case that % space was used before for any reason.
That sounds like a conveniently round number. I probably shouldn't try that on any of the data disks (which, of course, are recovered from other old computers) to get rid of the Win boot loader. But it does sound like a good way to make a disk unrecognizable == "fresh".
% % Unless you must use UEFI, which I gather from your posts you do not, then at
Not as far as I know ...
% your install (as you illustrated) create a GPT with a single root partition % for your production system and another identical partition for the test
Perfect. And also swap and data for the remainder, but I can't see how that should be a problem ... right?
% copy. There will not be a separate /boot (or /efi); the install will % allocate ~8MB at the front of the disk which is not a real partition but % just space to hold grub2 code because it can't fit in the MBR like the old
Well, wait ... Maybe I'm partitioning things wrong. You can see below that I only have about 1M free, rather than 8M free, on sda (on both machines, in fact). How did I even boot on diskfarm, and how do I even boot on jpo?
% grub. During install enter the Boot Loader dialog, select vanilla grub2, % and instruct YaST to "write to the master boot record" and turn on the % "probe foreign OS" switch. You will now have a system which will both % either instance.
Oho! I do want "probe"? I've been turning that off because I don't want it to try to use those old Windows drives. Maybe that's part of my problem.
% % There are a couple of additional details you would need to tend to with the % above, but I won't go that far until the above sounds like what you're % looking for. Does it?
Yes, I think so. Here's the layout on the "working" machine:
davidtg@jpo:~> sudo lsblk -a /dev/sda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 119.2G 0 disk ..sda1 8:1 0 33G 0 part [SWAP] ..sda2 8:2 0 32G 0 part / ..sda3 8:3 0 32G 0 part ..sda4 8:4 0 22.2G 0 part /mnt/ssd
davidtg@jpo:~> sudo parted /dev/sda p free Model: ATA SAMSUNG MZ7LN128 (scsi) Disk /dev/sda: 128GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: pmbr_boot
Number Start End Size File system Name Flags 17.4kB 1049kB 1031kB Free Space 1 1049kB 35.4GB 35.4GB linux-swap(v1) jpo-swap swap 2 35.4GB 69.8GB 34.4GB xfs jposuse 3 69.8GB 104GB 34.4GB xfs jpoalt legacy_boot 4 104GB 128GB 23.9GB xfs jpo-ssd
Here's the old sda on the "broken" machine:
diskfarm:~ # lsblk -a /dev/sda NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 119.2G 0 disk ââsda1 8:1 0 33G 0 part [SWAP] ââsda2 8:2 0 32G 0 part / ââsda3 8:3 0 32G 0 part ââsda4 8:4 0 22.2G 0 part /mnt/ssd
diskfarm:~ # parted /dev/sda p free Model: ATA SanDisk SD6SB1M1 (scsi) Disk /dev/sda: 128GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: pmbr_boot
Number Start End Size File system Name Flags 17.4kB 1049kB 1031kB Free Space 1 1049kB 35.4GB 35.4GB linux-swap(v1) diskfarm-swap swap 2 35.4GB 69.8GB 34.4GB xfs diskfarmsuse 3 69.8GB 104GB 34.4GB diskfarmknop legacy_boot 4 104GB 128GB 23.9GB xfs diskfarm-ssd
Here's the new sde on the "broken" machine:
diskfarm:~ # lsblk -a /dev/sde NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sde 8:64 0 238.5G 0 disk ââsde1 8:65 0 34G 0 part â ââmd124 9:124 0 34G 0 raid1 ââsde2 8:66 0 34G 0 part â ââmd125 9:125 0 34G 0 raid1 /tmp/e2 ââsde3 8:67 0 34G 0 part â ââmd126 9:126 0 34G 0 raid1 /tmp/e3 ââsde4 8:68 0 136.5G 0 part ââmd127 9:127 0 136.4G 0 raid1 /tmp/e4
diskfarm:~ # parted /dev/sde p free Model: ATA SATA SSD (scsi) Disk /dev/sde: 256GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 32.3kB 1049kB 1016kB Free Space 1 1049kB 36.5GB 36.5GB primary type=82 2 36.5GB 73.0GB 36.5GB primary boot, type=83 3 73.0GB 110GB 36.5GB primary type=83 4 110GB 256GB 147GB primary type=83 256GB 256GB 352kB Free Space
That's after I tried an MSDOS-MBR install, and it didn't work at all. I'm currently up and running via thumb drive -> boot linux system -> it finds sda -> ta-da, but curiously sde was not even an option. Before I go too deeply down that rabbit hole, though, yes, I think we're talking about the same very simple setup.
% % --dg % 15.3 & Plasma
Thanks again & HAND
:-D
Way, way too convoluted and complicated. One more time (and only one) . . . First, forget about mirroring or RAID or any such thing. Put that out of your mind for now. No offense, but my sense is that you don't have a good grasp of how booting works. Look once again at the fdisk output you posted for /dev/sda: Device Start End Sectors Size Type /dev/sda1 2048 69208063 69206016 33G Linux swap /dev/sda2 69208064 136316927 67108864 32G Linux filesystem /dev/sda3 136316928 203425791 67108864 32G Linux filesystem /dev/sda4 203425792 250069646 46643855 22.2G Linux filesystem Note that the first partition in the table begins at sector 2048. The sectors immediately before that partition are explained here: /In the context of GPT on a BIOS-based computer, a BIOS boot partition is similar /[but not the same!]/in some respects to the EFI system partition, which is used by systems based on EFI. The EFI System partition holds a _filesystem and files_ used by the UEFI, while the BIOS boot partition is used in BIOS-based systems and accessed without a filesystem by holding _raw binary code_. /To reiterate, the boot distinction between an UEFI vs a BIOS system, is that with UEFI an/actual partition in the partition table/ is required for the efi files (and filesystem) that grub2 needs in order to boot such a system. With a BIOS type system that is not required, but instead all that is needed is simply additional/space/ to hold the grub2 raw code. The sectors preceding sda1 are for that raw code only. The term "boot partition" in a BIOS system is correct only in the sense that it is a piece or segment of the disk, a partition of this disk, if you will. But it is not a "partition" in the sense of typical partitions in the table that hold filesystems, etc.. When Linux is installed on a BIOS machine, the installer will automatically allocate the disk space needed to fit the grub2 code, beginning at the first sector. When the user/system then proceeds with building the partition table, it will place the user's first partition immediately following the spaced allocated for grub2, i.e., at sector 2048 above. So to get a working system on your /dev/sde, all that is needed is to set the BIOS to not use UEFI (which apparently you have done), instruct the installer to use grub2 (not grub2-efi), have the installer format the entire disk, and then partition however you wish. I don't recall at the moment what the default partitioning is as recommended by the installer. But probably the simplest and very common way these days would be 3 partitions, one for the entire OS (/), another for /home, and the third for swap. But you can easily have openSUSE entirely on one partition, if you wish. Or you can have a bunch more for various types of data, etc. Choosing whatever partitioning best fits your needs is beyond the scope of this message, except to say that if you want to use the "snapshot" feature where you can "roll back" the system to a prior point in time, you will need to use the btrfs filesystem. You might want to consider this given your interest in "fault tolerance" (which strictly speaking, this is not - and it is very doubtful that you would need true FT anyway). Beyond that, my advice is to keep things simple and only do what you are sure about. Including W$ - or not - in your boot configuration is a separate discussion. And the previous suggestion re zeroing out the first ~10MB was strictly in the context of being concerned that there were old bits hanging around from previous use/attempts and preparing to use the old DOS method. Disregard all that. I suggest you first focus on only getting a simple working sde, nothing more. Go thru the vanilla install per above for verification using ext4. Once you have confirmed that, you can repeat the process however once you've worked out the partitioning scheme that you actually need. That's all I got. Good luck. --dg 15.3/Plasma