Hi !

another "hardcore" solution could be to create a chroot fresh
installation whithin you import your system's preferences:

- Create directory
- Untar last hardened stage 3
- Copy your /etc in the chroot
- Copy your world file in the chroot
- Copy any kind of data or local aplication to your chroot
- chroot and update your system
- when things is done, test it
- wipe your old gentoo and move your chrooted one on /


that's "hardcore" but permit me several times to ressucite a old gentoo
system.

IF you can't do it, the normal way is:

- Recompile your toolchain by compiling twice this ports:
virtual/portage virtual/os-headers sys-libs/glibc sys-devel/binutils-config sys-devel/binutils sys-devel/gcc-config
(don't forget to switch your gcc on the way and to clean your ccache if you use it)
- Recompile your system (emerge -Davut system)
- Finally recompile your world.


TIPS: use of revdep-rebuild and lafilefixer could help on the way...


Hoping that could help you to update your old gentoo.





On Wed, 2011-06-15 at 10:55 +0000, Krlis Repsons wrote:
> Hi all,
>
> I've got a machine, which hasn't been upgraded for some 2 years or less. It
> has GCC-4.3.4 and now I tried to upgrade to 4.5.2, but something failed. So
> I'm here to ask for the right sequence of upgrades and other actions before
> it's too late...
>
> These actions done already:
> 1. updated binutils,
> 2. updated glibc,
> 3. unmerged and re-emerged libtool (had a blocker),
> 4. tried with the new GCC, but failed with some unclear problems,
> 5. switched to vanilla GCC and now compile glibc...
>
> So have I done something bad or what should I do to be sure that the upgrade
> goes as smooth as possible? Thanks...

--
--------------------------------------------------------------------------------------
Jean-Franois Maeyhieux
--------------------------------------------------------------------------------------
PGP Public Key - Key ID = 63DB4770 Tuttle (JFM) <b4b1@free.fr>
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x63DB4770
--------------------------------------------------------------------------------------

On 15/06/2011 11:55, K�rlis Repsons wrote:
> Hi all,
>
> I've got a machine, which hasn't been upgraded for some 2 years or less. It
> has GCC-4.3.4 and now I tried to upgrade to 4.5.2, but something failed. So
> I'm here to ask for the right sequence of upgrades and other actions before
> it's too late...
>
> These actions done already:
> 1. updated binutils,
> 2. updated glibc,
> 3. unmerged and re-emerged libtool (had a blocker),
> 4. tried with the new GCC, but failed with some unclear problems,
> 5. switched to vanilla GCC and now compile glibc...
>
> So have I done something bad or what should I do to be sure that the upgrade
> goes as smooth as possible? Thanks...

You didn't give any info on the problems you had using gcc 4.5 so very
hard to comment. However, roughly the upgrade of any gcc is as per the
docs (upgrade, switch to it, upgrade libtool, emerge -ev system)

Likely problems you had were dependencies upgrading from a very old
system? Remember there is no harm in masking your gcc, upgrading, then
upgrading gcc is this solves some dependency? (Slower)

Remember to backup the machine...

Ed W

On 06/15/11 07:35, Jean-François Maeyhieux wrote:

Hi !

another "hardcore" solution could be to create a chroot fresh
installation whithin you import your system's preferences:

- Create directory - Untar last hardened stage 3 - Copy your /etc in
the chroot - Copy your world file in the chroot - Copy any kind of
data or local aplication to your chroot - chroot and update your
system - when things is done, test it - wipe your old gentoo and
move your chrooted one on /


that's "hardcore" but permit me several times to ressucite a old
gentoo system.

IF you can't do it, the normal way is:

- Recompile your toolchain by compiling twice this ports:
virtual/portage virtual/os-headers sys-libs/glibc
sys-devel/binutils-config sys-devel/binutils sys-devel/gcc-config
(don't forget to switch your gcc on the way and to clean your ccache
if you use it) - Recompile your system (emerge -Davut system) -
Finally recompile your world.




Somewhere you need to fool with profiles and make.conf. I *think* the
profiles will add, e.g., "hardened" to your gcc flag

There used to be a wiki somewhere that described the building of
hardened-gentoo step by step after branching off from the gentoo
handbook - to upgrade a standard box. It may have been called
gentooexperimental, but appears now dead.

IF anyone can point me to current documentation about building a
hardened box (which should include the make.conf and other hardened
settings), please post it here.

TIA

On 06/28/11 17:42, 7v5w7go9ub0o wrote:



IF anyone can point me to current documentation about building a
hardened box (which should include the make.conf and other hardened
settings), please post it here.


I just dropped by #gentoo-hardened on irc.freenode.net and asked about
instructions for building, and for migration (upgrading).

FWICT the instructions for building a hardened box are not quite yet
incorporated into the Gentoo handbook. However, thanks to Klondike, I
was quickly directed to:

<http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#hardenedprofile>

which pretty-well describes the migration process.

(Note the "eselect profile list" step, which switches to the hardened
profile - necessary before recompiling stuff.)

On 20 June 2011 14:20, Ed W <lists@wildgooses.com> wrote:
> On 15/06/2011 11:55, K�rlis Repsons wrote:
>> Hi all,
>>
>> I've got a machine, which hasn't been upgraded for some 2 years or less. It
>> has GCC-4.3.4 and now I tried to upgrade to 4.5.2, but something failed. So
>> I'm here to ask for the right sequence of upgrades and other actions before
>> it's too late...
>>
>> These actions done already:
>> 1. updated binutils,
>> 2. updated glibc,
>> 3. unmerged and re-emerged libtool (had a blocker),
>> 4. tried with the new GCC, but failed with some unclear problems,
>> 5. switched to vanilla GCC and now compile glibc...
>>
>> So have I done something bad or what should I do to be sure that the upgrade
>> goes as smooth as possible? Thanks...
>
> You didn't give any info on the problems you had using gcc 4.5 so very
> hard to comment. Â*However, roughly the upgrade of any gcc is as per the
> docs (upgrade, switch to it, upgrade libtool, emerge -ev system)
>
> Likely problems you had were dependencies upgrading from a very old
> system? Â*Remember there is no harm in masking your gcc, upgrading, then
> upgrading gcc is this solves some dependency? (Slower)
>
> Remember to backup the machine...

Thanks, the problem was rather silly: I ran out of RAM in a diskless machine...

By the way, if I wish to update and totally rebuild my system, what
steps do I have to take? I've seen many guides telling about the
toolchain and emerge -e system, then world, but I lack consistency and
understanding about how exactly and why. Anyone to suggest me some
valuable link about that?

On 28 June 2011 22:20, 7v5w7go9ub0o <7v5w7go9ub0o@gmail.com> wrote:
> <http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#hardenedprofile>
Does it say when glibc and libtool, perhaps some other
toolchain-related components need to be rebuilt? Didn't find anything
really...
(perhaps rebuilding virtual/libc leads to glibc rebuild?)

On 06/29/2011 04:39 AM, K�rlis Repsons wrote:
> On 20 June 2011 14:20, Ed W <lists@wildgooses.com> wrote:
>> On 15/06/2011 11:55, K�rlis Repsons wrote:
>>> Hi all,
>>>
>>> I've got a machine, which hasn't been upgraded for some 2 years or less. It
>>> has GCC-4.3.4 and now I tried to upgrade to 4.5.2, but something failed. So
>>> I'm here to ask for the right sequence of upgrades and other actions before
>>> it's too late...
>>>
>>> These actions done already:
>>> 1. updated binutils,
>>> 2. updated glibc,
>>> 3. unmerged and re-emerged libtool (had a blocker),
>>> 4. tried with the new GCC, but failed with some unclear problems,
>>> 5. switched to vanilla GCC and now compile glibc...
>>>
>>> So have I done something bad or what should I do to be sure that the upgrade
>>> goes as smooth as possible? Thanks...
>>
>> You didn't give any info on the problems you had using gcc 4.5 so very
>> hard to comment. However, roughly the upgrade of any gcc is as per the
>> docs (upgrade, switch to it, upgrade libtool, emerge -ev system)
>>
>> Likely problems you had were dependencies upgrading from a very old
>> system? Remember there is no harm in masking your gcc, upgrading, then
>> upgrading gcc is this solves some dependency? (Slower)
>>
>> Remember to backup the machine...
>
> Thanks, the problem was rather silly: I ran out of RAM in a diskless machine...
>
> By the way, if I wish to update and totally rebuild my system, what
> steps do I have to take? I've seen many guides telling about the
> toolchain and emerge -e system, then world, but I lack consistency and
> understanding about how exactly and why. Anyone to suggest me some
> valuable link about that?

The safest approach in either switching or recompiling everything is:

1. Make the profile is set "eselect profile list" and pick your hardened
box. Careful on amd64 about changing multilib/nomultilib. Stick with
your mutilib-edness (if such a word exists

2. Rebuild the tool chain: emerge binutils glibc gcc

3. Rebuild system: emerge --keep-going -eq system
(note anything that fails you might want to file a bug)

4. Rebuild world: emerge --keep-going -eq world
(again not any failures, shouldn't happen else we're not doing our job)

system vs world = system is just the bare minimum packages that any box
running that profile needs. world = system + what you've added. You
can skip step 3, but there might be a chance of mixing
unhardened/hardened stuff if you do, but I'm not 100% sure.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535

On 06/29/2011 04:39 AM, K�rlis Repsons wrote:
> On 20 June 2011 14:20, Ed W <lists@wildgooses.com> wrote:
>> On 15/06/2011 11:55, K�rlis Repsons wrote:
>>> Hi all,
>>>
>>> I've got a machine, which hasn't been upgraded for some 2 years or less. It
>>> has GCC-4.3.4 and now I tried to upgrade to 4.5.2, but something failed. So
>>> I'm here to ask for the right sequence of upgrades and other actions before
>>> it's too late...
>>>
>>> These actions done already:
>>> 1. updated binutils,
>>> 2. updated glibc,
>>> 3. unmerged and re-emerged libtool (had a blocker),
>>> 4. tried with the new GCC, but failed with some unclear problems,
>>> 5. switched to vanilla GCC and now compile glibc...
>>>
>>> So have I done something bad or what should I do to be sure that the upgrade
>>> goes as smooth as possible? Thanks...
>>
>> You didn't give any info on the problems you had using gcc 4.5 so very
>> hard to comment. However, roughly the upgrade of any gcc is as per the
>> docs (upgrade, switch to it, upgrade libtool, emerge -ev system)
>>
>> Likely problems you had were dependencies upgrading from a very old
>> system? Remember there is no harm in masking your gcc, upgrading, then
>> upgrading gcc is this solves some dependency? (Slower)
>>
>> Remember to backup the machine...
>
> Thanks, the problem was rather silly: I ran out of RAM in a diskless machine...
>
> By the way, if I wish to update and totally rebuild my system, what
> steps do I have to take? I've seen many guides telling about the
> toolchain and emerge -e system, then world, but I lack consistency and
> understanding about how exactly and why. Anyone to suggest me some
> valuable link about that?

The safest approach in either switching or recompiling everything is:

1. Make the profile is set "eselect profile list" and pick your hardened
box. Careful on amd64 about changing multilib/nomultilib. Stick with
your mutilib-edness (if such a word exists

2. Rebuild the tool chain: emerge binutils glibc gcc

3. Rebuild system: emerge --keep-going -eq system
(note anything that fails you might want to file a bug)

4. Rebuild world: emerge --keep-going -eq world
(again not any failures, shouldn't happen else we're not doing our job)

system vs world = system is just the bare minimum packages that any box
running that profile needs. world = system + what you've added. You
can skip step 3, but there might be a chance of mixing
unhardened/hardened stuff if you do, but I'm not 100% sure.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535

On 06/29/11 07:19, Anthony G. Basile wrote:

[snip]

>
> The safest approach in either switching or recompiling everything
> is:
>
> 1. Make the profile is set "eselect profile list" and pick your
> hardened box. Careful on amd64 about changing multilib/nomultilib.
> Stick with your mutilib-edness (if such a word exists
>
> 2. Rebuild the tool chain: emerge binutils glibc gcc
>
> 3. Rebuild system: emerge --keep-going -eq system (note anything
> that fails you might want to file a bug)
>
> 4. Rebuild world: emerge --keep-going -eq world (again not any
> failures, shouldn't happen else we're not doing our job)
>
> system vs world = system is just the bare minimum packages that any
> box running that profile needs. world = system + what you've added.
> You can skip step 3, but there might be a chance of mixing
> unhardened/hardened stuff if you do, but I'm not 100% sure.
>

Thank You!

1. Is there some way this clear, succinct list could get into the
hardened documentation?

2. At this point, the 'clearest' way to build a hardened box from scratch
seems to go a few steps into the Gentoo handbook, then migrate using the
steps above. Not ideal, but until the documentation can be refined, how
about either putting these steps into the handbook, or alternatively a
reference *in the handbook* to wherever you find a home for these steps
(e.g. QandA).

IIRC, there is nowhere a reference to "hardened" in the Gentoo Handbook.

On 06/29/11 07:19, Anthony G. Basile wrote:

[snip]

>
> The safest approach in either switching or recompiling everything
> is:
>
> 1. Make the profile is set "eselect profile list" and pick your
> hardened box. Careful on amd64 about changing multilib/nomultilib.
> Stick with your mutilib-edness (if such a word exists
>
> 2. Rebuild the tool chain: emerge binutils glibc gcc
>
> 3. Rebuild system: emerge --keep-going -eq system (note anything
> that fails you might want to file a bug)
>
> 4. Rebuild world: emerge --keep-going -eq world (again not any
> failures, shouldn't happen else we're not doing our job)
>
> system vs world = system is just the bare minimum packages that any
> box running that profile needs. world = system + what you've added.
> You can skip step 3, but there might be a chance of mixing
> unhardened/hardened stuff if you do, but I'm not 100% sure.
>

Thank You!

1. Is there some way this clear, succinct list could get into the
hardened documentation?

2. At this point, the 'clearest' way to build a hardened box from scratch
seems to go a few steps into the Gentoo handbook, then migrate using the
steps above. Not ideal, but until the documentation can be refined, how
about either putting these steps into the handbook, or alternatively a
reference *in the handbook* to wherever you find a home for these steps
(e.g. QandA).

IIRC, there is nowhere a reference to "hardened" in the Gentoo Handbook.