Advice on copy/replace (damaged) partition

[figueroa]

It's a miracle. Do you trust miracles? Suggest you learn more deeply about making proper backups.

[MoonWalker]

In fact, I use to keep an extra disk as a clone of the one in use but it somehow got lost in the mist of having covid twice. I will get a new one for sure but thanks for pointing it out.

[NeddySeagoon]

MoonWalker,

Looking at your first dmesr

Code: Select all

[    2.505185] EXT4-fs (sda4): INFO: recovery required on readonly filesystem
[    2.505186] EXT4-fs (sda4): write access will be enabled during recovery
[    2.525064] EXT4-fs (sda4): recovery complete
[    2.535354] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
...
[   13.065817] EXT4-fs error (device sda4): mb_free_blocks:1457: group 401, block 13141532:freeing already freed block (bit 1564); block bitmap corrupt.
[   13.065838] EXT4-fs error (device sda4): ext4_mb_generate_buddy:747: group 401, block bitmap and bg descriptor inconsistent: 31468 vs 31469 free clusters

That suggests unclean shutdown on the previous boot that rootfsck was mostly able to fix.
Enough for the boot to proceed anyway.

The

Code: Select all

block bitmap and bg descriptor inconsistent

is some of the remaining damage.
fsck will make the fields consistent again but it says nothing for and data you may have there. Essentially, the fs has lost track of its free space.

The second boot shows

Code: Select all

[    2.518061] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
...
[    7.861686] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)

whicn is correct. Somehow the free space tracking was fixed.
Does that mean you lost some data though?

From smartctl,

Code: Select all

ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  5 Reallocated_Sector_Ct   PO--CK   200   200   140    -    0
  9 Power_On_Hours          -O--CK   036   036   000    -    47386
197 Current_Pending_Sector  -O--CK   200   200   000    -    0

With 47386 running hours the drive is middle aged.
It has not used any of the spare sectors since it was new and it has no sectors that it knows about that it can't read. I was expecting one or both of those numbers to be non zero.

There have been several read errors at

Code: Select all

Error 53 [4] occurred at disk power-on lifetime: 47371 hours (1973 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 51 00 00 00 00 00 64 21 74 ef 00  Error: UNC at LBA = 0x0f642174 = 258220404

Is LBA 258220404 your sda4 superblock?

and

Code: Select all

Error: UNC 240 sectors at LBA = 0x0f642174 = 258220404

The drive is not happy. This is all internal drive information too. The interface is in the clear.

Use smartctl to run the long test. Leave it for 3 hours.

Code: Select all

Extended self-test routine
recommended polling time: 	 ( 174) minutes.

Then post the smart data again. A non zero Current_Pending_Sector count means that the drive cannot read is own writing any more, so it's scrap.
That's not supposed to happen, when sectors get difficult to read, they should get mapped to a spare. That increments Reallocated_Sector_Ct. That's a sign of wear and the drive operating as designed.

[MoonWalker]

MoonWalker,

Looking at your first dmesr

Code: Select all

[    2.505185] EXT4-fs (sda4): INFO: recovery required on readonly filesystem
[    2.505186] EXT4-fs (sda4): write access will be enabled during recovery
[    2.525064] EXT4-fs (sda4): recovery complete
[    2.535354] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
...
[   13.065817] EXT4-fs error (device sda4): mb_free_blocks:1457: group 401, block 13141532:freeing already freed block (bit 1564); block bitmap corrupt.
[   13.065838] EXT4-fs error (device sda4): ext4_mb_generate_buddy:747: group 401, block bitmap and bg descriptor inconsistent: 31468 vs 31469 free clusters

That suggests unclean shutdown on the previous boot that rootfsck was mostly able to fix.
Enough for the boot to proceed anyway.

The

Code: Select all

block bitmap and bg descriptor inconsistent

is some of the remaining damage.
fsck will make the fields consistent again but it says nothing for and data you may have there. Essentially, the fs has lost track of its free space.

Okay... I think it could have been at a power break, although I have an APC but sure it only last for a few minutes, so if I'm not around. The last mount data as I dug up earlier, August last year, I think that fir with when they were here and completed my Optic Fiber connection. It's possible they broke power or simply pulled a plug or whatever. Whatsoever, as memory clears here it must have happened in connection with that event.

The second boot shows

Code: Select all

[    2.518061] EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
...
[    7.861686] EXT4-fs (sda5): mounted filesystem with ordered data mode. Opts: (null)

whicn is correct. Somehow the free space tracking was fixed.
Does that mean you lost some data though?

It's possible. I just tried to do a

Code: Select all

# emerge --sync

but it wasn't happy to complete...

>>> Syncing repository 'gentoo' into '/usr/portage'...
* Using keys from /usr/share/openpgp-keys/gentoo-release.asc
* Refreshing keys via WKD ... [ !! ]
* Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://keys.gentoo.org
gpg: keyserver refresh failed: Server indicated a failure
OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://keys.gentoo.org
gpg: key
server refresh failed: Server indicated a failure
...
OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://keys.gentoo.org
gpg: key
server refresh failed: Server indicated a failure

I don't know if it can be due to data loss, but indicates something is off. Net now seems to work as it should though and I can also connect "remote" from my Windows box with kitty.
Maybe a full system rebuild? (once I have run the smartctr test)

btw I have now rebooted several times w/o a direct, at least visual, problems.

From smartctl,

Code: Select all

ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  5 Reallocated_Sector_Ct   PO--CK   200   200   140    -    0
  9 Power_On_Hours          -O--CK   036   036   000    -    47386
197 Current_Pending_Sector  -O--CK   200   200   000    -    0

With 47386 running hours the drive is middle aged.
It has not used any of the spare sectors since it was new and it has no sectors that it knows about that it can't read. I was expecting one or both of those numbers to be non zero.

Well, it's a quite old drive really. According to the on disk label it will celebrate 10 years on 15 June, but lately it hasn't been running continuously. I kinda remember now how it was, I used this drive as a backup of the running server disk. It's actually my old desktop disk, so every time I upgraded the kernel or something like that, major, I cloned the main disk to this one. Then the main (Seagate Barracuda) disk failed and for various reasons (covid being one) I never got a new drive for it.

There have been several read errors at

Code: Select all

Error 53 [4] occurred at disk power-on lifetime: 47371 hours (1973 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  40 -- 51 00 00 00 00 00 64 21 74 ef 00  Error: UNC at LBA = 0x0f642174 = 258220404

Is LBA 258220404 your sda4 superblock?

I don't know. dumpe2fs -h gives this output

# dumpe2fs -h /dev/sda4
dumpe2fs 1.46.3 (27-Jul-2021)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: 2ac59fdb-4dd1-4242-b9ec-39bf73b60596
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 15597568
Block count: 62390272
Reserved block count: 3119513
Free blocks: 50913385
Free inodes: 14684990
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Wed Oct 4 08:42:20 2017
Last mount time: Tue Mar 29 12:46:18 2022
Last write time: Mon Mar 28 23:47:02 2022
Mount count: 3
Maximum mount count: -1
Last checked: Mon Mar 28 23:47:02 2022
Check interval: 0 (<none>)
Lifetime writes: 771 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: e3601eac-3663-4599-8886-68d26c107b46
Journal backup: inode blocks
Journal features: journal_incompat_revoke journal_64bit
Total journal size: 1024M
Total journal blocks: 262144
Max transaction length: 262144
Fast commit length: 0
Journal sequence: 0x0011a66a
Journal start: 1

which is odd as -h should show only the superblock but not sure I see it there. Is there a better way, maybe it's due to /dev/sda4 is mounted?

and

Code: Select all

Error: UNC 240 sectors at LBA = 0x0f642174 = 258220404

The drive is not happy. This is all internal drive information too. The interface is in the clear.

Use smartctl to run the long test. Leave it for 3 hours.

Code: Select all

Extended self-test routine
recommended polling time: 	 ( 174) minutes.

Then post the smart data again. A non zero Current_Pending_Sector count means that the drive cannot read is own writing any more, so it's scrap.
That's not supposed to happen, when sectors get difficult to read, they should get mapped to a spare. That increments Reallocated_Sector_Ct. That's a sign of wear and the drive operating as designed.

Ok, I will run that test, but from the sound of it, it appears as if it could break the drive, so wonder if it wouldn't make sense to clone or copy the whole system to another drive first, just in case?

You said drive was "middle aged" as of run hours, but still you see signs of wear... The physical age of the drive is well past "middle" though, but it's a WD Caviar Black, supposed to be top of the line at the time... I mean quality beyond "average".

I was just thinking, can it be that the repeated cloning to the drive, could have had an impact, like inherited bad data/blocks etc. from the drive that later died? My thinking goes back to what you said earlier when succeeding to mount /dev/sda4 by using the superblock backup. You said if used dd for backup it would also backup the bad block. So when cloning with clonezilla, isn't it doing the same thing reading everything off the disk?

Anyway, I have ordered a new drive, a 1TB Seagate Exos 7E8 but wont get it until 1 April, also thinking of getting one for my live server. the smartctl check of the current live drive doesn't ring any alarm though from what I can see,
http://dpaste.com/7NNXBHLRG
would you agree?

BTW I really want to thank you for helping me out here, much appreciated. I know you have others in need as well, so no urgency, but I think we are close to reach a conclusion of this thread, so let's get there.

TIA

[NeddySeagoon]

MoonWalker,

The easy one first. You cannot clone a bad sector. Whatever the copy program does, it won't get the data.
Most give up with a error message, a few, like ddrescue, leave a 'hole' in the data.
Whatever, its harmless to the drive.

The long test instructs the drive to do a full surface scan. Its all done internal to the drive.
Like reading the entire drive to /dev/null but the SATA interface in not used.

It should not do any damage. The test will abort at the first bad sector that cannot be read with retries and the Current_Pending_Sector will be incremented.
If the drive decides that a sector is getting hard to read, it will relocate the data and increment Reallocated_Sector_Ct.
It's a health check for the drive. The test won't change anything, it might tell you things are not what the seem though, so you learn about it now, no later when it might be inconvenient.

Its always good to have a backup - see my sig :)


Your sync failed as

Code: Select all

* Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://keys.gentoo.org
gpg: keyserver refresh failed: Server indicated a failure
OpenPGP keyring refresh failed: 

but we cannot tell why from that. The key server is implicated though.

[MoonWalker]

Ok thanks.

I have started the long test, I hope

Code: Select all

# smartctl -t long /dev/sda

It wrote a few lines on the screen, including "Testing has begun.", ending with "Use smartctl -X to abort test."
and the back to an empty prompt # _ (underscore blinking)

I assume this is all okay and do I understand it correctly that I have to stop it manually? it also said "Please wait 174 minutes for test to complete."

[NeddySeagoon]

MoonWalker,

It will stop when it completes, or before that if it fails.
Its supposed to take 173 min. ... so 3 hours at least.

All that's happened is that smartctl has issued a command to the drive.
There is noting to see. It the test is interrupted, it will be logged as interrupted and cannot be resumed, its start over.

Getting back to where is LBA = 0x0f642174 = 258220404.
Your

Code: Select all

fdisk -l /dev/sda

will help.
It should show the starting sector of each partition.
If sector 258220404 is near the start of sda4, its likely in the default superblock.

The summary result will be

Code: Select all

 SMART Extended Self-test Log Version: 1 (1 sectors)
No self-tests have been logged.  [To run self-tests, use: smartctl -t]
<here>

[MoonWalker]

MoonWalker,

It will stop when it completes, or before that if it fails.
Its supposed to take 173 min. ... so 3 hours at least.

All that's happened is that smartctl has issued a command to the drive.
There is noting to see. It the test is interrupted, it will be logged as interrupted and cannot be resumed, its start over.

Getting back to where is LBA = 0x0f642174 = 258220404.
Your

Code: Select all

fdisk -l /dev/sda

will help.

Code: Select all

 ~ # fdisk -l /dev/sda
Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: WDC WD1002FAEX-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 2DF4CAAD-4487-426F-9820-A1967B10FF15

Device         Start       End   Sectors   Size Type
/dev/sda1       2048      6143      4096     2M BIOS boot
/dev/sda2       6144    460799    454656   222M Linux filesystem
/dev/sda3     460800  10483711  10022912   4.8G Linux filesystem
/dev/sda4   10483712 509605887 499122176   238G Linux filesystem
/dev/sda5  509605888 968284159 458678272 218.7G Linux filesystem
/dev/sda6  968284160 976656383   8372224     4G Linux filesystem

seems to be somewhere in the middle of /dev/sda4

[MoonWalker]

This is output from

Code: Select all

# smartctl -x /dev/sda

after the long test.

https://dpaste.com/B4SDE2KGP
Apart from if it shows up in the smartctl -x I cannot see any visual sign that the test was completed on screen or any specific log in /var/log

Another "change" is that the wgetpaste call didn't work now, but I'm able to connect to the server box from this one I could still cat the output file and dpaste it manually.

[NeddySeagoon]

MoonWalker,

Code: Select all

SMART Extended Self-test Log Version: 1 (1 sectors)
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     47411   

and the zero error counts are ideal. That's the best sign that the drive is healthy.

Something happened to corrupt the primary superbtock but we will never determine what/how/why.

Pastebin tites do go offline from time to time. wgetpaste knows about 8 sites. Try

Code: Select all

wgetpaste -S

You can change the default site os use the -s option to set one on the command line.

-- edit --

I don't see any correlation between

Code: Select all

/dev/sda4   10483712 509605887 499122176   238G Linux filesystem

sectors close to sector 10483712 and LBA 258220404, so I think the read errors in the smart log and primary superblock errors are not related.

[MoonWalker]

NeddySeagoon,

I found that I had a typo in /etc/conf.d/net for the dns ip address, somehow a . in the address had a / instead, which was the reason that wgetpaste didn't work, and same for # emerge --sync

So I was able to sync and update the tree, which brought new news items where I fond one package affected by the VDB bug. I was able to fix that and am now running

Code: Select all

# emerge --ask --emptytree --usepkg=n @world

and all fine so far having merged 112 of 541 packages.

So maybe the drive is healthy anyway, somewhat anyhow. So let's see.

Once the emerge completes I plan to take a backup of the drive. I fund a somewhat old 500G WD drive in my store that looks healthy
http://dpaste.com/4477ZQURR
from what I can see. Do you agree?

In such case plan on using clonezilla to make a close, or do you have a better suggestion? Anyway, I think we can consider the original problem [SOLVED] now.

[NeddySeagoon]

MoonWalker,

Its worth a long test before you put it back into service.
Its looks healthy from the smart data.

[MoonWalker]

NeddySeagoon,

I want to thank you so much for your help, concidering now also I know that that you have a job as well! Outstanding!

So I think we can consider this as completed now, just want to follow up with my final steps in case it can be of help to someone else getting here in the future.

So I ran a long test also on the second HDD, which I think is older in age, but has considering less powered on hours, and it passed. So both discs have now passed the long test.
However, I decided to use that older but smaller disc as main now, but due to being smaller there was a problem to solve with moving that data and make it bootable, as a strait Clonezilla clone wouldent work. So here is how I solved that:

First, with both disks connected I booted with MX-Workbench and used gparted to first clear the smaller disk (sdb) of it current partitions and then copied all partitions from sda, one by one so both disks were identical.
However, this doesn't result in the small disk to be bootable, to to solve that I used Clonezilla to simply clone sda1 to sdb1 and viola. I could now remove sda and make sdb to be sda and it booted w/o any problem.

A note about MX-Workbench. It's probably a great tool of which I haven't tested the rest, but I found Clonezilla to be non-functional. This because when you run Clonezilla it automatically also starts to mount partitions and opening them in some file handler and keep insisting to do this if you close these windows. It also asks for a password, probably because it uses su, which is create if you qickly need to fix something as root, but for an administrators toolbox I don't like the approach. If I live boot to work with a problematic system, I want to be root no questions asked. period.

So I ended up to use the Clonezilla LiveCD for that final fix. Optimal would of course be to have both gparted and clonezilla available from the same bootable Live CD/USB, but apart from MX-Workbench I have only seen one other solution "Parted Magic" but it's a "buy before you try" complilation/solution.

So now start next step, to bring this old box up-to-date, currently with a 4.19 kernel and gcc 6.5, while the heartbeat from the CPU will stay the same (Intel Q9400 @ 2.66GHz) and if I run into a need for help I will open a new topic. So far all good though. I decided to begin with gcc 9.4.1 and will decide for kernel later, after I have resuilt the box.

Also, this will just be a pre-excersice for my main online server where I will have to do the same updates later.

[NeddySeagoon]

MoonWalker,

Thank you for that last post. I'm sure it will help others.

Good luck and enjoy your Gentoo

[MoonWalker]

NeddySeagoon,

a final question, after all,

I have rebuilt the whole box using gcc 9.4.1 (emerg --emptytree @system & --emptytree @world), but w/ --exclude gentoo-sources (as well as compiling a new kernet) because I want to take a backup before I take that step. I have made the backup using Clonezilla to take a full disk clone. All cloning of partitions seems to have completed successfully. However, there is something in the final monitor text display as the clone completes that makes me doubtful if it was successful or not.

On the final monitor display the 3 top rows shown are the ones of concern, the first in yellow and the next 2 in red:

Yes, we are able to chroot the restored OS partition /dev/sdb4.
The tool to update initramfs was NOT found in function do_run_update_initrd_from_restored_os!
Failed to create initrd in the restored OS.
*************************************************
...

******************************************
Press "Enter" to continue...

What came before that was something about installing grub, which apparently worked in the end as the cloned disk indeed boots, but red text is always something to take serious and I know initramfs is related to the kernel. Well, I know (remember) that I boot my kernel with it. Also, I know my kernel (4.19.108) is old and for reasons I cannot remember now I haven't updated genkernel (which I used to create initramfs for 4.19.108 with) to version 4 but still runs 3.5.3.3 and finally then my question as such - is this something I have to worry about regarding my clone backup? I figure it may have something to do with my old "stuff" here and maybe it all pans out as things gets updated, but not sure about these things.

[NeddySeagoon]

MoonWalker,

I don't know. I've never used genkernel or Clonezilla.

I leaned to build kernels before I started with Gentoo.
At that time, I learned to configure the kernel not to need an initrd.

More recently, I use an initrd as root is on raid or in LVM. or both. That means I need user space tools to make root available before it can be mounted.
I have to have an initrd but its only user space tools, so its like firmware. Its made when the system is first installed and not changed.
As the initrd does not contain any kernel modules, it works with any kernel.

I use the kernel provided script to put all the pieces together, not the autoblackmagic of a tool that i don't understand.

If the clone boots, the initrd is either present or not needed, or both.

[MoonWalker]

Ok, but just to make it clear. I don't use genkernel to build the kernel, only to generate the initramfs after the kernel has been built and copied into /boot. So the initramfs is used to load the kernel. That's the only was I have been able to boot the kernel on my old hardware. So I will continue and see how it goes.

thanks again.

[NeddySeagoon]

MoonWalker,

The boot loader loads the kernel, not the initrd.

See PC Boot Process

[MoonWalker]

So following up, I was able to upgrade the kernel to 4.19.237 and reboot successfully. Everything now compiled using gcc-9.4.1

The box was brought up-to-date with # emerge --emptytree @world, everything going smooth.

Then I successfully migrated the profile switching to 17.1 no-multilib, I thought.

But after syncing and update world once again I got this output in the end

* One or more symlinks to directories have been preserved in order to
* ensure that files installed via these symlinks remain accessible. This
* indicates that the mentioned symlink(s) may be obsolete remnants of an
* old install, and it may be appropriate to replace a given symlink with
* the directory that it points to.
*
* /lib32
* /usr/lib32
*

* Messages for package sys-libs/libxcrypt-4.4.28:

*
* Directory symlink(s) may need protection:
*
* /lib32
* /usr/lib32
*
* Use the UNINSTALL_IGNORE variable to exempt specific symlinks
* from the following search (see the make.conf man page).
*
* Searching all installed packages for files installed via above symlink(s)...
*
* One or more symlinks to directories have been preserved in order to
* ensure that files installed via these symlinks remain accessible. This
* indicates that the mentioned symlink(s) may be obsolete remnants of an
* old install, and it may be appropriate to replace a given symlink with
* the directory that it points to.
*
* /lib32
* /usr/lib32
*

* Messages for package sys-apps/sandbox-2.29:

*
* Directory symlink(s) may need protection:
*
* /usr/lib32
*
* Use the UNINSTALL_IGNORE variable to exempt specific symlinks
* from the following search (see the make.conf man page).
*
* Searching all installed packages for files installed via above symlink(s)...
*
* The above directory symlink(s) are all safe to remove. Removing them now...
*

Is it safe just to delete these symlinks as from what I understand the system should now be 100% 64bit? On the other hand, it almost seems as if there still are parts of the system that "hasn't got the memo", so to speak, and tries to preserve what is meant to be lost - or maybe it's just to expect too much of portage, that it will clean up after me having taken those actions.

[figueroa]

Did you follow the profile migration instructions?
https://www.gentoo.org/support/news-ite ... table.html

[NeddySeagoon]

MoonWalker,

You say you are on 17.1 no-multilib now.

What 17.0 profile were you on?

== edit ==

Your other topic says it was default/linux/amd64/17.0.
Having switched to no-multilib, your installed 32 bit code is orphaned.

[MoonWalker]

Did you follow the profile migration instructions?
https://www.gentoo.org/support/news-ite ... table.html

Yes. of course I did and everything went fine from what I can see, but the migration instruction doesn't really touch on no-multilib, in fact rather the opposite (multilib). Maybe this is something that should have been included as from what I can understand it would appear to anyone choosing the 17.1 no-multilib profile.

I find it a bit strange though as 17.1 migration is supposed to be a switch to no symlink libs, and I though it removed these links. Then, I don't know if "no-multilib" issues belongs to the migration as such. Maybe it's not a good idea to choose, unless you used it for your old profile as well.

[MoonWalker]

MoonWalker,

You say you are on 17.1 no-multilib now.

What 17.0 profile were you on?

== edit ==

Your other topic says it was default/linux/amd64/17.0.
Having switched to no-multilib, your installed 32 bit code is orphaned.

Does it mean it was a bad idea to switch to no-multilib in connection with the migration, instead of doing it after, of it doesn't really matter?

I can redo the whole process if need be, and this is exactly why I'm running this box, to test/practice on maneuvers like this before I hit my live server and bring it down because "I didn't think of that".

[NeddySeagoon]

MoonWalker,

If you have rebuilt any part of the the toolchain since the profile switch, you only have a 64 bit capable toolchain.
Going back will be difficult.

[MoonWalker]

MoonWalker,

If you have rebuilt any part of the the toolchain since the profile switch, you only have a 64 bit capable toolchain.
Going back will be difficult.

Yes, I understand that. With "going back" I mean restoring my backup. The question though is if it's necessary as 64 bit is what I want. I mean, would it have made any difference if I migrated to 17.1 (default) and then switched to 17.1 no-multilib? I assume it would leave me with the same result, old 32 bit code and symlinks left behind for me to clean up manually?

Remember, this is my test server, I can afford to "screw up" even though it can be time consuming, so I don't need to make have that experience with my live server. So it would be good to have an answer on the questions above. I'm trying to dig for info in the forum but its search function is well below par.

I know one can use google site search, but... I haven't played with BB for many years but I'm sure there is a plugin or mod (or whatever it's called today) that would fix this. <just a parenthesis>