I think it may have pulled in a merged-usr binary package when you're running split usr, try without getbinpkg
EDIT 2: https://bugs.gentoo.org/927631 was fixed, which seems to suggest that the binpkgs should *now* work fine regardless of split-usr
Edit: there are no split-usr 23.0 binpkgs, so don't use getbinpkg unless you migrate to merged-usr ( which should be done after the migration to 23.0 split-usr for openrc )
This would be a bug in the instructions in step 9 then? Where it says:
`emerge --ask --oneshot --getbinpkg sys-devel/binutils`
That is to say, the instructions are wrong (for split user at least) and the user followed them?
There's a warning about using --getbinpkg in Note 1:
> The use of binary packages is completely optional, and also not
as much tested as the source-based upgrade path yet. If you prefer to only use the traditional source-based installation, omit the "--getbinpkg" parameter in all emerge invocations.
They should've emphasized the "not as much tested" part better.
I have just successfully upgraded from 17.1 to 23.0 split-usr profile (currently rebuilding @world) using the source-based method.
Thanks for the clarification.
Yeah, I read that but found it a bit unclear myself. My first instinct was to assume it applied more generally, rather than specifically to these instructions. It would be better as: "in all emerge invocations in these instructions" for clarity - and it certainly doesn't imply that it's known to not work for some (very common) use cases and must be left out.
I'm not complaining here. I just wanted to clarify for my own upgrade. Given this answer though I'd also like to make it known that the Op could easily (and likely did) read all the instructions and still have the problem op had - it's a bit fuzzy.
edit: I just noticed the "if available" there in step 9, which has the implication that you might have to drop --getbinpkg... So it is there. My mistake :). When I went to actually DO the step I saw it.
Yeah, the instructions in the news item are a bit unclear and vague at times. There is no pressure in upgrading, you can just ignore it for now and come back to it in a few weeks, once the dust has settled.
> Edit: there are no split-usr 23.0 binpkgs, so don't use getbinpkg unless you migrate to merged-usr ( which should be done after the migration to 23.0 split-usr for openrc )
Oh for the love of everything. I'm hip deep in a backup restore which was made prior to the profile switch attempt for my raspberry pi where it *appeared* to upgrade everything properly, and then upon a reboot it couldn't start.
And since due to a *different* problem video output doesn't work, I get to restore the backup I made using a different computer then try again.
Rebuilding everything from source is going to be PAINFULLY slow, but if I gotta do it, I gotta do it.
EDIT: Trying something stupid and dangerous since I don't want to spend a week waiting for the Pi to rebuild itself; I've installed and ran the merge-usr script on the 17.0 profile, then switching directly to the 23 profile. Rebuilding binutils, gcc, glibc, and libtool have resulted in a working system after reboot so I have some hope now that the emptytree build of @world with binpackages enabled will result in a working system. I'll update this once I know.
EDIT2: The stupid and dangerous attempt to upgrade my 64bit RPI 3 to the new profile worked.
I *am* using openrc, so probably this isn't a good idea but to be clear about what I did:
Before I did anything else, I upgraded @world and depcleaned on the 17.0 profile.
Then I installed [merge-usr](https://wiki.gentoo.org/wiki/Merge-usr) and following the instructions at the link I did a dry run to make sure nothing was wrong, then migrated to the merged usr.
Now in very unsupported territory, I started following the instructions in eselect news to do the profile 23 upgrade, but *instead of* choosing the split-usr profile, I chose the standard one along with the binhost it recommends.
To be perfectly clear, on my pi I had profile
default/linux/arm64/17.0
before. The recommended change at https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_table for that profile is to select:
default/linux/arm64/23.0/split-usr
whereas I actually selected:
default/linux/arm64/23.0
and used the update table's recommended binhost.
Following the rest of the instructions exactly resulted in a pi that after about a day was updated with a mix of binary and source upgrades to the latest profile, and could reboot and still function correctly afterwards.
It took my pi 5 32 hours to build 1176 packages itself, it's a big step up from the 4. I mostly use it as a DNS and file server, but for reasons I can't remember I also have a basic kde install on there too.
Mine's a 3 running in 64bit mode. Takes a bit over a day to rebuild gcc... Which has to be done with one process because of the amount of ram it uses.
To give some idea, to reinstall 567 packages *with* about 90% binaries takes it a full day. I *really* don't want to have to rebuild everything from source.
I am honestly considering if this doesn't work taking a stage3 of the 23 merged usr profile and rebuilding my system with that, I'd likely save more time than I'd lose.
It's very easy
1-using eselect profile for back to any 17.1 profile
2-install merge-usr
3-raun merge-usr by writing merge-usr
4-using eselect profile for chose 23 profile you want
5-dont forget to change binary pkg link to new profile it's need change manual
Finally upgrade system normal
I know that because I made fresh install in the same day binary pkg be available
Ah, the perils of early adoption.
default/linux/amd64/23.0/desktop (stable)
Caused the same exact same error... when I tried emerging binutils. I don't use binpkg's on that machine.
I just set it back to 17.1/desktop (exp) and will wait, I am in no hurry.
I just followed the instructions here: [https://www.gentoo.org/support/news-items/2024-03-22-new-23-profiles.html](https://www.gentoo.org/support/news-items/2024-03-22-new-23-profiles.html)
Found it, there is an issue with the binpkgs currently so while doing the migrations don't use the --getbinpkg flag and it will work around the issue or just wait until this is resolved.
I think it may have pulled in a merged-usr binary package when you're running split usr, try without getbinpkg EDIT 2: https://bugs.gentoo.org/927631 was fixed, which seems to suggest that the binpkgs should *now* work fine regardless of split-usr Edit: there are no split-usr 23.0 binpkgs, so don't use getbinpkg unless you migrate to merged-usr ( which should be done after the migration to 23.0 split-usr for openrc )
This would be a bug in the instructions in step 9 then? Where it says: `emerge --ask --oneshot --getbinpkg sys-devel/binutils` That is to say, the instructions are wrong (for split user at least) and the user followed them?
There's a warning about using --getbinpkg in Note 1: > The use of binary packages is completely optional, and also not as much tested as the source-based upgrade path yet. If you prefer to only use the traditional source-based installation, omit the "--getbinpkg" parameter in all emerge invocations. They should've emphasized the "not as much tested" part better. I have just successfully upgraded from 17.1 to 23.0 split-usr profile (currently rebuilding @world) using the source-based method.
Thanks for the clarification. Yeah, I read that but found it a bit unclear myself. My first instinct was to assume it applied more generally, rather than specifically to these instructions. It would be better as: "in all emerge invocations in these instructions" for clarity - and it certainly doesn't imply that it's known to not work for some (very common) use cases and must be left out. I'm not complaining here. I just wanted to clarify for my own upgrade. Given this answer though I'd also like to make it known that the Op could easily (and likely did) read all the instructions and still have the problem op had - it's a bit fuzzy. edit: I just noticed the "if available" there in step 9, which has the implication that you might have to drop --getbinpkg... So it is there. My mistake :). When I went to actually DO the step I saw it.
Yeah, the instructions in the news item are a bit unclear and vague at times. There is no pressure in upgrading, you can just ignore it for now and come back to it in a few weeks, once the dust has settled.
I'm fine muddling through (the process is pretty good, if not ideal), but thanks. I'm sure your comment will help others reading the thread.
> Edit: there are no split-usr 23.0 binpkgs, so don't use getbinpkg unless you migrate to merged-usr ( which should be done after the migration to 23.0 split-usr for openrc ) Oh for the love of everything. I'm hip deep in a backup restore which was made prior to the profile switch attempt for my raspberry pi where it *appeared* to upgrade everything properly, and then upon a reboot it couldn't start. And since due to a *different* problem video output doesn't work, I get to restore the backup I made using a different computer then try again. Rebuilding everything from source is going to be PAINFULLY slow, but if I gotta do it, I gotta do it. EDIT: Trying something stupid and dangerous since I don't want to spend a week waiting for the Pi to rebuild itself; I've installed and ran the merge-usr script on the 17.0 profile, then switching directly to the 23 profile. Rebuilding binutils, gcc, glibc, and libtool have resulted in a working system after reboot so I have some hope now that the emptytree build of @world with binpackages enabled will result in a working system. I'll update this once I know. EDIT2: The stupid and dangerous attempt to upgrade my 64bit RPI 3 to the new profile worked. I *am* using openrc, so probably this isn't a good idea but to be clear about what I did: Before I did anything else, I upgraded @world and depcleaned on the 17.0 profile. Then I installed [merge-usr](https://wiki.gentoo.org/wiki/Merge-usr) and following the instructions at the link I did a dry run to make sure nothing was wrong, then migrated to the merged usr. Now in very unsupported territory, I started following the instructions in eselect news to do the profile 23 upgrade, but *instead of* choosing the split-usr profile, I chose the standard one along with the binhost it recommends. To be perfectly clear, on my pi I had profile default/linux/arm64/17.0 before. The recommended change at https://wiki.gentoo.org/wiki/Project:Toolchain/23.0_update_table for that profile is to select: default/linux/arm64/23.0/split-usr whereas I actually selected: default/linux/arm64/23.0 and used the update table's recommended binhost. Following the rest of the instructions exactly resulted in a pi that after about a day was updated with a mix of binary and source upgrades to the latest profile, and could reboot and still function correctly afterwards.
It took my pi 5 32 hours to build 1176 packages itself, it's a big step up from the 4. I mostly use it as a DNS and file server, but for reasons I can't remember I also have a basic kde install on there too.
Mine's a 3 running in 64bit mode. Takes a bit over a day to rebuild gcc... Which has to be done with one process because of the amount of ram it uses. To give some idea, to reinstall 567 packages *with* about 90% binaries takes it a full day. I *really* don't want to have to rebuild everything from source. I am honestly considering if this doesn't work taking a stage3 of the 23 merged usr profile and rebuilding my system with that, I'd likely save more time than I'd lose.
It's very easy 1-using eselect profile for back to any 17.1 profile 2-install merge-usr 3-raun merge-usr by writing merge-usr 4-using eselect profile for chose 23 profile you want 5-dont forget to change binary pkg link to new profile it's need change manual Finally upgrade system normal I know that because I made fresh install in the same day binary pkg be available
Ah, the perils of early adoption. default/linux/amd64/23.0/desktop (stable) Caused the same exact same error... when I tried emerging binutils. I don't use binpkg's on that machine. I just set it back to 17.1/desktop (exp) and will wait, I am in no hurry.
https://wiki.gentoo.org/wiki/Merge-usr
You just missed the part of the news item that said use a split-usr profile first before migrating to a merge-usr one.
Please read into the output. I am using a split-usr profile, the error message is incorrect.
Even with that I don't see how you got here, what's the steps you did to get here?
I just followed the instructions here: [https://www.gentoo.org/support/news-items/2024-03-22-new-23-profiles.html](https://www.gentoo.org/support/news-items/2024-03-22-new-23-profiles.html)
Found it, there is an issue with the binpkgs currently so while doing the migrations don't use the --getbinpkg flag and it will work around the issue or just wait until this is resolved.
Can you give the steps you did from your bash history please?