How do i convert 32-bit to 64-bit arch on centos 6?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












Currently I installed Centos 6.9 32bit OS in VM and I want to convert into 64-bit architecture in same machine.



I checked lots of stuff over internet but didn't find any forum for same, specifically for CentOS.



What are the way to setup 64bit arch?



nb: Unable to convert on Debian/ubuntu










share|improve this question



























    up vote
    0
    down vote

    favorite












    Currently I installed Centos 6.9 32bit OS in VM and I want to convert into 64-bit architecture in same machine.



    I checked lots of stuff over internet but didn't find any forum for same, specifically for CentOS.



    What are the way to setup 64bit arch?



    nb: Unable to convert on Debian/ubuntu










    share|improve this question

























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      Currently I installed Centos 6.9 32bit OS in VM and I want to convert into 64-bit architecture in same machine.



      I checked lots of stuff over internet but didn't find any forum for same, specifically for CentOS.



      What are the way to setup 64bit arch?



      nb: Unable to convert on Debian/ubuntu










      share|improve this question















      Currently I installed Centos 6.9 32bit OS in VM and I want to convert into 64-bit architecture in same machine.



      I checked lots of stuff over internet but didn't find any forum for same, specifically for CentOS.



      What are the way to setup 64bit arch?



      nb: Unable to convert on Debian/ubuntu







      centos kernel x86 architecture






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Aug 8 at 4:19









      slm♦

      238k65491662




      238k65491662










      asked Aug 7 at 16:55









      Nullpointer

      2501215




      2501215




















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          0
          down vote













          The easiest solution is a new installation.



          If you don't want that, boot a life system and install the 64-bit programs. You can also start with a 64-bit kernel. The 64-bit kernel should run 32-bit binaries, and you can keep multiple kernels so you can switch back if it doesn't work.



          Also consider whether the benefit is worth the trouble. 64-bit x86 has been available for about 15 years. If you didn't install 64-bit when the machine was new, you probably didn't need it.






          share|improve this answer



























            up vote
            0
            down vote













            I did a 32 to 64 bit conversion on Debian, which is the only distro I think you can actually hope to do that with (due to the very rigorous Debian apt packaging rules, and the exceedingly robust apt tools), and even there, even though it technically worked in that I did not reinstall the OS, it took so absurdly long to do, and required so many fixes, that my next 32 to 64 conversion I just copied over all the /etc files to backup and then created a filtered package list (filtered out lib files, which are generally dependencies of programs). Next I did a base install of a new 64 bit system, then I installed the package list. Then I used my backups where needed to update the configs and various other files, but note, you do NOT want to just blindly reuse your 32 bit configs, since you don't know what has changed or might be different in 64 bit. Both methods are tedious, but I would never do the 32 to 64 bit crossgrade again, although it was interesting as a test just to confirm it can be done. But even there, most of the configs ended up needing to get purged, so it really was not super different from just rebuilding a fresh install from a package list, which is how I did my second cross-grade.



            With rpm/CentOS, I'd say your odds of hitting the best case scenario I cite above, where you do technically preserve the install while cross grading to 64 bit, are very close to zero, and you'd certainly regret it afterwards in terms of the time you spent.



            I disagree with the person who says if 32 was what you started with, it's probably still ok, that was not my experience, PAE (> 4gB) ram support in the kernel was and is getting more buggy, so you were limited to 4gB stable ram, although I ran more using PAE, but it had increasingly bad stability issues because basically almost nobody uses that in the real world, so the bugs were getting worse and worse in the kernel support by the year. Also, certain applications were not getting supported in 32 bit any longer, and that was also getting worse by the year, which is why I finally dumped my main 32 bit systems.



            As an aside, the reason you can't find anything on that conversion for CentOS is that there is no way rpm/CentOS can handle it, particularly not from that era. You can find several decent how-tos for Debian, but even those are quite optimistic, as I discovered, and very very picky and complicated, but theoretically possible because of how robust apt is.






            share|improve this answer






















            • It is not an easy feat indeed. Even with ((semi)automating the process and getting the hand of it, I might have spent around 30-45 minutes per V; in the last VMs I migrated. (some were small VMs - 300-500 packages for FreeRadius, BIND and ISC-DHCP). But by half of the process, I was already confident enough to be migrating 3 servers concurrently.
              – Rui F Ribeiro
              Aug 7 at 19:35

















            up vote
            0
            down vote













            A direct conversion/migration from 32-bit to pure 64-bits machine/VM on CentOS won't work.



            The main obstacle is that the housekeeping rpm/yum packages databases internal structures are dependent on integers. They differ on size and are not interchangeable between the two arquitectures.



            PS. I hot migrated 40 Debian machines from 32 bits to 64 bits. It was no minor feat, however Debian uses (or used to use at that time) only housekeeping text files.



            PS2. I do agree with @Lizardx There are costs keeping 32-bit VMs around. Besides what he mentions, having an homogenous infra-structure is gold, and you might pay a penalty in performance running 32-bit VMs with a 64-bit hypervisor.






            share|improve this answer


















            • 1




              I'm impressed, 40 machines is as you say, no minor feat, and I thought doing 1 was hard enough. But it does prove the technical robustness of apt and the Debian packaging rules, which are the strictest I know of, and it shows you when you run one of these ultimate tests of packaging systems.
              – Lizardx
              Aug 7 at 18:53










            • @Lizardx By hot, I meant I did the process with them running....no boot from other boot medium ;)
              – Rui F Ribeiro
              Aug 7 at 19:18






            • 1




              Yes, I know what you meant, that's why it's impressive. That's what I did too.
              – Lizardx
              Aug 7 at 22:47










            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f461108%2fhow-do-i-convert-32-bit-to-64-bit-arch-on-centos-6%23new-answer', 'question_page');

            );

            Post as a guest






























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            0
            down vote













            The easiest solution is a new installation.



            If you don't want that, boot a life system and install the 64-bit programs. You can also start with a 64-bit kernel. The 64-bit kernel should run 32-bit binaries, and you can keep multiple kernels so you can switch back if it doesn't work.



            Also consider whether the benefit is worth the trouble. 64-bit x86 has been available for about 15 years. If you didn't install 64-bit when the machine was new, you probably didn't need it.






            share|improve this answer
























              up vote
              0
              down vote













              The easiest solution is a new installation.



              If you don't want that, boot a life system and install the 64-bit programs. You can also start with a 64-bit kernel. The 64-bit kernel should run 32-bit binaries, and you can keep multiple kernels so you can switch back if it doesn't work.



              Also consider whether the benefit is worth the trouble. 64-bit x86 has been available for about 15 years. If you didn't install 64-bit when the machine was new, you probably didn't need it.






              share|improve this answer






















                up vote
                0
                down vote










                up vote
                0
                down vote









                The easiest solution is a new installation.



                If you don't want that, boot a life system and install the 64-bit programs. You can also start with a 64-bit kernel. The 64-bit kernel should run 32-bit binaries, and you can keep multiple kernels so you can switch back if it doesn't work.



                Also consider whether the benefit is worth the trouble. 64-bit x86 has been available for about 15 years. If you didn't install 64-bit when the machine was new, you probably didn't need it.






                share|improve this answer












                The easiest solution is a new installation.



                If you don't want that, boot a life system and install the 64-bit programs. You can also start with a 64-bit kernel. The 64-bit kernel should run 32-bit binaries, and you can keep multiple kernels so you can switch back if it doesn't work.



                Also consider whether the benefit is worth the trouble. 64-bit x86 has been available for about 15 years. If you didn't install 64-bit when the machine was new, you probably didn't need it.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Aug 7 at 17:08









                RalfFriedl

                3,5601522




                3,5601522






















                    up vote
                    0
                    down vote













                    I did a 32 to 64 bit conversion on Debian, which is the only distro I think you can actually hope to do that with (due to the very rigorous Debian apt packaging rules, and the exceedingly robust apt tools), and even there, even though it technically worked in that I did not reinstall the OS, it took so absurdly long to do, and required so many fixes, that my next 32 to 64 conversion I just copied over all the /etc files to backup and then created a filtered package list (filtered out lib files, which are generally dependencies of programs). Next I did a base install of a new 64 bit system, then I installed the package list. Then I used my backups where needed to update the configs and various other files, but note, you do NOT want to just blindly reuse your 32 bit configs, since you don't know what has changed or might be different in 64 bit. Both methods are tedious, but I would never do the 32 to 64 bit crossgrade again, although it was interesting as a test just to confirm it can be done. But even there, most of the configs ended up needing to get purged, so it really was not super different from just rebuilding a fresh install from a package list, which is how I did my second cross-grade.



                    With rpm/CentOS, I'd say your odds of hitting the best case scenario I cite above, where you do technically preserve the install while cross grading to 64 bit, are very close to zero, and you'd certainly regret it afterwards in terms of the time you spent.



                    I disagree with the person who says if 32 was what you started with, it's probably still ok, that was not my experience, PAE (> 4gB) ram support in the kernel was and is getting more buggy, so you were limited to 4gB stable ram, although I ran more using PAE, but it had increasingly bad stability issues because basically almost nobody uses that in the real world, so the bugs were getting worse and worse in the kernel support by the year. Also, certain applications were not getting supported in 32 bit any longer, and that was also getting worse by the year, which is why I finally dumped my main 32 bit systems.



                    As an aside, the reason you can't find anything on that conversion for CentOS is that there is no way rpm/CentOS can handle it, particularly not from that era. You can find several decent how-tos for Debian, but even those are quite optimistic, as I discovered, and very very picky and complicated, but theoretically possible because of how robust apt is.






                    share|improve this answer






















                    • It is not an easy feat indeed. Even with ((semi)automating the process and getting the hand of it, I might have spent around 30-45 minutes per V; in the last VMs I migrated. (some were small VMs - 300-500 packages for FreeRadius, BIND and ISC-DHCP). But by half of the process, I was already confident enough to be migrating 3 servers concurrently.
                      – Rui F Ribeiro
                      Aug 7 at 19:35














                    up vote
                    0
                    down vote













                    I did a 32 to 64 bit conversion on Debian, which is the only distro I think you can actually hope to do that with (due to the very rigorous Debian apt packaging rules, and the exceedingly robust apt tools), and even there, even though it technically worked in that I did not reinstall the OS, it took so absurdly long to do, and required so many fixes, that my next 32 to 64 conversion I just copied over all the /etc files to backup and then created a filtered package list (filtered out lib files, which are generally dependencies of programs). Next I did a base install of a new 64 bit system, then I installed the package list. Then I used my backups where needed to update the configs and various other files, but note, you do NOT want to just blindly reuse your 32 bit configs, since you don't know what has changed or might be different in 64 bit. Both methods are tedious, but I would never do the 32 to 64 bit crossgrade again, although it was interesting as a test just to confirm it can be done. But even there, most of the configs ended up needing to get purged, so it really was not super different from just rebuilding a fresh install from a package list, which is how I did my second cross-grade.



                    With rpm/CentOS, I'd say your odds of hitting the best case scenario I cite above, where you do technically preserve the install while cross grading to 64 bit, are very close to zero, and you'd certainly regret it afterwards in terms of the time you spent.



                    I disagree with the person who says if 32 was what you started with, it's probably still ok, that was not my experience, PAE (> 4gB) ram support in the kernel was and is getting more buggy, so you were limited to 4gB stable ram, although I ran more using PAE, but it had increasingly bad stability issues because basically almost nobody uses that in the real world, so the bugs were getting worse and worse in the kernel support by the year. Also, certain applications were not getting supported in 32 bit any longer, and that was also getting worse by the year, which is why I finally dumped my main 32 bit systems.



                    As an aside, the reason you can't find anything on that conversion for CentOS is that there is no way rpm/CentOS can handle it, particularly not from that era. You can find several decent how-tos for Debian, but even those are quite optimistic, as I discovered, and very very picky and complicated, but theoretically possible because of how robust apt is.






                    share|improve this answer






















                    • It is not an easy feat indeed. Even with ((semi)automating the process and getting the hand of it, I might have spent around 30-45 minutes per V; in the last VMs I migrated. (some were small VMs - 300-500 packages for FreeRadius, BIND and ISC-DHCP). But by half of the process, I was already confident enough to be migrating 3 servers concurrently.
                      – Rui F Ribeiro
                      Aug 7 at 19:35












                    up vote
                    0
                    down vote










                    up vote
                    0
                    down vote









                    I did a 32 to 64 bit conversion on Debian, which is the only distro I think you can actually hope to do that with (due to the very rigorous Debian apt packaging rules, and the exceedingly robust apt tools), and even there, even though it technically worked in that I did not reinstall the OS, it took so absurdly long to do, and required so many fixes, that my next 32 to 64 conversion I just copied over all the /etc files to backup and then created a filtered package list (filtered out lib files, which are generally dependencies of programs). Next I did a base install of a new 64 bit system, then I installed the package list. Then I used my backups where needed to update the configs and various other files, but note, you do NOT want to just blindly reuse your 32 bit configs, since you don't know what has changed or might be different in 64 bit. Both methods are tedious, but I would never do the 32 to 64 bit crossgrade again, although it was interesting as a test just to confirm it can be done. But even there, most of the configs ended up needing to get purged, so it really was not super different from just rebuilding a fresh install from a package list, which is how I did my second cross-grade.



                    With rpm/CentOS, I'd say your odds of hitting the best case scenario I cite above, where you do technically preserve the install while cross grading to 64 bit, are very close to zero, and you'd certainly regret it afterwards in terms of the time you spent.



                    I disagree with the person who says if 32 was what you started with, it's probably still ok, that was not my experience, PAE (> 4gB) ram support in the kernel was and is getting more buggy, so you were limited to 4gB stable ram, although I ran more using PAE, but it had increasingly bad stability issues because basically almost nobody uses that in the real world, so the bugs were getting worse and worse in the kernel support by the year. Also, certain applications were not getting supported in 32 bit any longer, and that was also getting worse by the year, which is why I finally dumped my main 32 bit systems.



                    As an aside, the reason you can't find anything on that conversion for CentOS is that there is no way rpm/CentOS can handle it, particularly not from that era. You can find several decent how-tos for Debian, but even those are quite optimistic, as I discovered, and very very picky and complicated, but theoretically possible because of how robust apt is.






                    share|improve this answer














                    I did a 32 to 64 bit conversion on Debian, which is the only distro I think you can actually hope to do that with (due to the very rigorous Debian apt packaging rules, and the exceedingly robust apt tools), and even there, even though it technically worked in that I did not reinstall the OS, it took so absurdly long to do, and required so many fixes, that my next 32 to 64 conversion I just copied over all the /etc files to backup and then created a filtered package list (filtered out lib files, which are generally dependencies of programs). Next I did a base install of a new 64 bit system, then I installed the package list. Then I used my backups where needed to update the configs and various other files, but note, you do NOT want to just blindly reuse your 32 bit configs, since you don't know what has changed or might be different in 64 bit. Both methods are tedious, but I would never do the 32 to 64 bit crossgrade again, although it was interesting as a test just to confirm it can be done. But even there, most of the configs ended up needing to get purged, so it really was not super different from just rebuilding a fresh install from a package list, which is how I did my second cross-grade.



                    With rpm/CentOS, I'd say your odds of hitting the best case scenario I cite above, where you do technically preserve the install while cross grading to 64 bit, are very close to zero, and you'd certainly regret it afterwards in terms of the time you spent.



                    I disagree with the person who says if 32 was what you started with, it's probably still ok, that was not my experience, PAE (> 4gB) ram support in the kernel was and is getting more buggy, so you were limited to 4gB stable ram, although I ran more using PAE, but it had increasingly bad stability issues because basically almost nobody uses that in the real world, so the bugs were getting worse and worse in the kernel support by the year. Also, certain applications were not getting supported in 32 bit any longer, and that was also getting worse by the year, which is why I finally dumped my main 32 bit systems.



                    As an aside, the reason you can't find anything on that conversion for CentOS is that there is no way rpm/CentOS can handle it, particularly not from that era. You can find several decent how-tos for Debian, but even those are quite optimistic, as I discovered, and very very picky and complicated, but theoretically possible because of how robust apt is.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Aug 7 at 18:44

























                    answered Aug 7 at 18:31









                    Lizardx

                    1,581410




                    1,581410











                    • It is not an easy feat indeed. Even with ((semi)automating the process and getting the hand of it, I might have spent around 30-45 minutes per V; in the last VMs I migrated. (some were small VMs - 300-500 packages for FreeRadius, BIND and ISC-DHCP). But by half of the process, I was already confident enough to be migrating 3 servers concurrently.
                      – Rui F Ribeiro
                      Aug 7 at 19:35
















                    • It is not an easy feat indeed. Even with ((semi)automating the process and getting the hand of it, I might have spent around 30-45 minutes per V; in the last VMs I migrated. (some were small VMs - 300-500 packages for FreeRadius, BIND and ISC-DHCP). But by half of the process, I was already confident enough to be migrating 3 servers concurrently.
                      – Rui F Ribeiro
                      Aug 7 at 19:35















                    It is not an easy feat indeed. Even with ((semi)automating the process and getting the hand of it, I might have spent around 30-45 minutes per V; in the last VMs I migrated. (some were small VMs - 300-500 packages for FreeRadius, BIND and ISC-DHCP). But by half of the process, I was already confident enough to be migrating 3 servers concurrently.
                    – Rui F Ribeiro
                    Aug 7 at 19:35




                    It is not an easy feat indeed. Even with ((semi)automating the process and getting the hand of it, I might have spent around 30-45 minutes per V; in the last VMs I migrated. (some were small VMs - 300-500 packages for FreeRadius, BIND and ISC-DHCP). But by half of the process, I was already confident enough to be migrating 3 servers concurrently.
                    – Rui F Ribeiro
                    Aug 7 at 19:35










                    up vote
                    0
                    down vote













                    A direct conversion/migration from 32-bit to pure 64-bits machine/VM on CentOS won't work.



                    The main obstacle is that the housekeeping rpm/yum packages databases internal structures are dependent on integers. They differ on size and are not interchangeable between the two arquitectures.



                    PS. I hot migrated 40 Debian machines from 32 bits to 64 bits. It was no minor feat, however Debian uses (or used to use at that time) only housekeeping text files.



                    PS2. I do agree with @Lizardx There are costs keeping 32-bit VMs around. Besides what he mentions, having an homogenous infra-structure is gold, and you might pay a penalty in performance running 32-bit VMs with a 64-bit hypervisor.






                    share|improve this answer


















                    • 1




                      I'm impressed, 40 machines is as you say, no minor feat, and I thought doing 1 was hard enough. But it does prove the technical robustness of apt and the Debian packaging rules, which are the strictest I know of, and it shows you when you run one of these ultimate tests of packaging systems.
                      – Lizardx
                      Aug 7 at 18:53










                    • @Lizardx By hot, I meant I did the process with them running....no boot from other boot medium ;)
                      – Rui F Ribeiro
                      Aug 7 at 19:18






                    • 1




                      Yes, I know what you meant, that's why it's impressive. That's what I did too.
                      – Lizardx
                      Aug 7 at 22:47














                    up vote
                    0
                    down vote













                    A direct conversion/migration from 32-bit to pure 64-bits machine/VM on CentOS won't work.



                    The main obstacle is that the housekeeping rpm/yum packages databases internal structures are dependent on integers. They differ on size and are not interchangeable between the two arquitectures.



                    PS. I hot migrated 40 Debian machines from 32 bits to 64 bits. It was no minor feat, however Debian uses (or used to use at that time) only housekeeping text files.



                    PS2. I do agree with @Lizardx There are costs keeping 32-bit VMs around. Besides what he mentions, having an homogenous infra-structure is gold, and you might pay a penalty in performance running 32-bit VMs with a 64-bit hypervisor.






                    share|improve this answer


















                    • 1




                      I'm impressed, 40 machines is as you say, no minor feat, and I thought doing 1 was hard enough. But it does prove the technical robustness of apt and the Debian packaging rules, which are the strictest I know of, and it shows you when you run one of these ultimate tests of packaging systems.
                      – Lizardx
                      Aug 7 at 18:53










                    • @Lizardx By hot, I meant I did the process with them running....no boot from other boot medium ;)
                      – Rui F Ribeiro
                      Aug 7 at 19:18






                    • 1




                      Yes, I know what you meant, that's why it's impressive. That's what I did too.
                      – Lizardx
                      Aug 7 at 22:47












                    up vote
                    0
                    down vote










                    up vote
                    0
                    down vote









                    A direct conversion/migration from 32-bit to pure 64-bits machine/VM on CentOS won't work.



                    The main obstacle is that the housekeeping rpm/yum packages databases internal structures are dependent on integers. They differ on size and are not interchangeable between the two arquitectures.



                    PS. I hot migrated 40 Debian machines from 32 bits to 64 bits. It was no minor feat, however Debian uses (or used to use at that time) only housekeeping text files.



                    PS2. I do agree with @Lizardx There are costs keeping 32-bit VMs around. Besides what he mentions, having an homogenous infra-structure is gold, and you might pay a penalty in performance running 32-bit VMs with a 64-bit hypervisor.






                    share|improve this answer














                    A direct conversion/migration from 32-bit to pure 64-bits machine/VM on CentOS won't work.



                    The main obstacle is that the housekeeping rpm/yum packages databases internal structures are dependent on integers. They differ on size and are not interchangeable between the two arquitectures.



                    PS. I hot migrated 40 Debian machines from 32 bits to 64 bits. It was no minor feat, however Debian uses (or used to use at that time) only housekeeping text files.



                    PS2. I do agree with @Lizardx There are costs keeping 32-bit VMs around. Besides what he mentions, having an homogenous infra-structure is gold, and you might pay a penalty in performance running 32-bit VMs with a 64-bit hypervisor.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Aug 7 at 19:28

























                    answered Aug 7 at 18:07









                    Rui F Ribeiro

                    36.5k1271116




                    36.5k1271116







                    • 1




                      I'm impressed, 40 machines is as you say, no minor feat, and I thought doing 1 was hard enough. But it does prove the technical robustness of apt and the Debian packaging rules, which are the strictest I know of, and it shows you when you run one of these ultimate tests of packaging systems.
                      – Lizardx
                      Aug 7 at 18:53










                    • @Lizardx By hot, I meant I did the process with them running....no boot from other boot medium ;)
                      – Rui F Ribeiro
                      Aug 7 at 19:18






                    • 1




                      Yes, I know what you meant, that's why it's impressive. That's what I did too.
                      – Lizardx
                      Aug 7 at 22:47












                    • 1




                      I'm impressed, 40 machines is as you say, no minor feat, and I thought doing 1 was hard enough. But it does prove the technical robustness of apt and the Debian packaging rules, which are the strictest I know of, and it shows you when you run one of these ultimate tests of packaging systems.
                      – Lizardx
                      Aug 7 at 18:53










                    • @Lizardx By hot, I meant I did the process with them running....no boot from other boot medium ;)
                      – Rui F Ribeiro
                      Aug 7 at 19:18






                    • 1




                      Yes, I know what you meant, that's why it's impressive. That's what I did too.
                      – Lizardx
                      Aug 7 at 22:47







                    1




                    1




                    I'm impressed, 40 machines is as you say, no minor feat, and I thought doing 1 was hard enough. But it does prove the technical robustness of apt and the Debian packaging rules, which are the strictest I know of, and it shows you when you run one of these ultimate tests of packaging systems.
                    – Lizardx
                    Aug 7 at 18:53




                    I'm impressed, 40 machines is as you say, no minor feat, and I thought doing 1 was hard enough. But it does prove the technical robustness of apt and the Debian packaging rules, which are the strictest I know of, and it shows you when you run one of these ultimate tests of packaging systems.
                    – Lizardx
                    Aug 7 at 18:53












                    @Lizardx By hot, I meant I did the process with them running....no boot from other boot medium ;)
                    – Rui F Ribeiro
                    Aug 7 at 19:18




                    @Lizardx By hot, I meant I did the process with them running....no boot from other boot medium ;)
                    – Rui F Ribeiro
                    Aug 7 at 19:18




                    1




                    1




                    Yes, I know what you meant, that's why it's impressive. That's what I did too.
                    – Lizardx
                    Aug 7 at 22:47




                    Yes, I know what you meant, that's why it's impressive. That's what I did too.
                    – Lizardx
                    Aug 7 at 22:47

















                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f461108%2fhow-do-i-convert-32-bit-to-64-bit-arch-on-centos-6%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Bahrain

                    Postfix configuration issue with fips on centos 7; mailgun relay