First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates. if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance. KM
If there are many old kernels in there, you can probably remove the oldest one(s) to make room for newer ones.
I've run into problems where the yum update didn't work because there wasn't enough room in /boot; my notes for updating now include removing old kernels first before running updates.
--- Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265 Russ Engineering Center 937-775-5157 michael.vanhorn@wright.edu
On 10/10/17, 9:55 AM, "CentOS on behalf of KM" <centos-bounces@centos.org on behalf of info4km@yahoo.com> wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates. if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance. KM _______________________________________________ CentOS mailing list CentOS@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
Thanks for the idea. I've already restricted it to one kernel. .... so this will not help me.
On Tuesday, October 10, 2017 10:04:56 AM, Vanhorn, Mike michael.vanhorn@wright.edu wrote:
If there are many old kernels in there, you can probably remove the oldest one(s) to make room for newer ones.
I've run into problems where the yum update didn't work because there wasn't enough room in /boot; my notes for updating now include removing old kernels first before running updates.
--- Mike VanHorn Senior Computer Systems Administrator College of Engineering and Computer Science Wright State University 265 Russ Engineering Center 937-775-5157 michael.vanhorn@wright.edu
On 10/10/17, 9:55 AM, "CentOS on behalf of KM" <centos-bounces@centos.org on behalf of info4km@yahoo.com> wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates. if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance. KM _______________________________________________ CentOS mailing list CentOS@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/10/2017 07:04 AM, Vanhorn, Mike wrote:
If there are many old kernels in there, you can probably remove the oldest one(s) to make room for newer ones.
This is what I do. When /boot hits about 80% I go through and remove old kernels I will never boot into anyway.
Usually that's at four kernels.
On Tue, 2017-10-10 at 13:55 +0000, KM wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates.
How big is it?
if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this?
No, you can't do that. /boot is special and needs to be a separate partition.
The most likely cause of your problems is that you have multiple kernels installed - when you boot the machine do you see multiple versions on the grub boot screen? If you don't need the previous versions then they can just be deleted using yum: do 'rpm -q kernel' to see which kernels are installed and 'uname -r' to see which version you are currently running (it should be the same as the highest version installed). You can then use 'yum erase ...' to remove the old kernels. It's always handy to have a version or two old ones in case of emergency so I always leave three on a system.
The multiple versions installed of some things - i.e. the kernel - is controlled by a yum variable in /etc/yum.conf called 'installonly_limit'. It's probably set to 5 at the moment, you can set it to 3 safely and that is usually sufficient to stop /boot filling up.
P.
Here is my current info, should have increased it to like 500M or so at least. Filesystem Size Used Avail Use% Mounted on/dev/sda1 96M 33M 59M 36% /boot
ls /boot config-2.6.32-358.el6.x86_64 efi grub initramfs-2.6.32-358.el6.x86_64.img initrd-2.6.32-358.el6.x86_64kdump.img lost+found symvers-2.6.32-358.el6.x86_64.gz System.map-2.6.32-358.el6.x86_64 vmlinuz-2.6.32-358.el6.x86_64
On Tuesday, October 10, 2017 10:17:46 AM, Pete Biggs pete@biggs.org.uk wrote:
On Tue, 2017-10-10 at 13:55 +0000, KM wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates.
How big is it?
if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this?
No, you can't do that. /boot is special and needs to be a separate partition.
The most likely cause of your problems is that you have multiple kernels installed - when you boot the machine do you see multiple versions on the grub boot screen? If you don't need the previous versions then they can just be deleted using yum: do 'rpm -q kernel' to see which kernels are installed and 'uname -r' to see which version you are currently running (it should be the same as the highest version installed). You can then use 'yum erase ...' to remove the old kernels. It's always handy to have a version or two old ones in case of emergency so I always leave three on a system.
The multiple versions installed of some things - i.e. the kernel - is controlled by a yum variable in /etc/yum.conf called 'installonly_limit'. It's probably set to 5 at the moment, you can set it to 3 safely and that is usually sufficient to stop /boot filling up.
P. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Tue, 10 Oct 2017, Pete Biggs wrote:
No, you can't do that. /boot is special and needs to be a separate partition.
Needs is a bit strong, as grub2 does support LVM. It's not a supported configuration for Redhat.
I'm not a sure there's a lot to it beyond having the lvm module loaded in grub, but I've honestly not tried.
jh
On 10/10/17 15:27, John Hodrien wrote:
On Tue, 10 Oct 2017, Pete Biggs wrote:
No, you can't do that. /boot is special and needs to be a separate partition.
Needs is a bit strong, as grub2 does support LVM. It's not a supported configuration for Redhat.
I'm not a sure there's a lot to it beyond having the lvm module loaded in grub, but I've honestly not tried.
Indeed, /boot does not need to be a separate partition. I have /boot within the root filesystem on my test boxes where I know I will need to install many / all kernels for testing / development purposes for the specific reason that I do not need to set a size for /boot and it can just consume whatever it needs from the rest of the filesystem.
Do i need to do something special or is it as easy as: - save the contents of the current /boot - umount /boot and change the /etc/fstab so it doesn't mount again- create a boot directory that is in the root filesystem- copy the contents back I realize the physical/current /boot will be a waste of space but it's not that big so it's fine. I thought i probably have to make configuration changes of some sort. Again I apologize in advance since I am not really good at this (partition/file system). I have tried searching but am never sure exactly what I should try. I need to find the "for dummies" version(s) of this. Thanks again. KM
On Tuesday, October 10, 2017 02:44:12 PM, Phil Perry pperry@elrepo.org wrote:
On 10/10/17 15:27, John Hodrien wrote:
On Tue, 10 Oct 2017, Pete Biggs wrote:
No, you can't do that. /boot is special and needs to be a separate partition.
Needs is a bit strong, as grub2 does support LVM. It's not a supported configuration for Redhat.
I'm not a sure there's a lot to it beyond having the lvm module loaded in grub, but I've honestly not tried.
Indeed, /boot does not need to be a separate partition. I have /boot within the root filesystem on my test boxes where I know I will need to install many / all kernels for testing / development purposes for the specific reason that I do not need to set a size for /boot and it can just consume whatever it needs from the rest of the filesystem.
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
KM info4km@yahoo.com wrote:
Do i need to do something special or is it as easy as:
- save the contents of the current /boot - umount /boot and change
the /etc/fstab so it doesn't mount again- create a boot directory that is in the root filesystem- copy the contents back
You'll also have to reinstall Grub. The wiki has information on this.
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of KM Sent: den 10 oktober 2017 21:06 To: centos@centos.org; Phil Perry pperry@elrepo.org Subject: Re: [CentOS] /boot partition too small
Do i need to do something special or is it as easy as:
- save the contents of the current /boot - umount /boot and change the
/etc/fstab so it doesn't mount again- create a boot directory that is in the root filesystem- copy the contents back I realize the physical/current /boot will be a waste of space but it's not that big so it's fine. I thought i probably have to make configuration changes of some sort. Again I apologize in advance since I am not really good at this (partition/file system). I have tried searching but am never sure exactly what I should try. I need to find the "for dummies" version(s) of this. Thanks again. KM
Assuming you have backups, if something should go south, you might want to try out the Gparted boot-iso.
Using Gparted you should be able to shrink some of the other partitions, and then grow the boot partition.
More info on: https://gparted.org/index.php
If you have another non-critical computer to test using Gparted on, do that first before doing it "for real".
Hope this helps. -- //Sorin
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Sorin Srbu Sent: den 11 oktober 2017 07:57 To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] /boot partition too small
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of KM Sent: den 10 oktober 2017 21:06 To: centos@centos.org; Phil Perry pperry@elrepo.org Subject: Re: [CentOS] /boot partition too small
Do i need to do something special or is it as easy as:
- save the contents of the current /boot - umount /boot and change the
/etc/fstab so it doesn't mount again- create a boot directory that is
in
the root filesystem- copy the contents back I realize the physical/current /boot will be a waste of space but it's
not
that big so it's fine. I thought i probably have to make configuration changes of some sort. Again I apologize in advance since I am not really good at this (partition/file system). I have tried searching but am never sure exactly what I should try. I need to find the "for dummies" version(s) of this. Thanks
again.
KM
Assuming you have backups, if something should go south, you might want to try out the Gparted boot-iso.
Using Gparted you should be able to shrink some of the other partitions,
and
then grow the boot partition.
More info on: https://gparted.org/index.php
If you have another non-critical computer to test using Gparted on, do
that
first before doing it "for real".
Hope this helps.
Wait a sec, this was LVM right? Not sure if Gparted supports that yet.
-- //Sorin
On 10 October 2017 at 09:55, KM info4km@yahoo.com wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates. if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance. KM
There is no easy way to increase the /boot partition. One can try to build another /boot partition and use that but that isn't simple either and prone to problems if the /boot is outside of where that particular BIOS can intepret (aka embedded in an LVM) or jump to.
I have found the simpler method is usually: dump the disks to backup, reinstall the system with 500 to 1000 MB /boot and restore from backups.
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Tue, Oct 10, 2017 at 10:36:16AM -0400, Stephen John Smoogen wrote:
On 10 October 2017 at 09:55, KM info4km@yahoo.com wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates.
if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance. KM
There is no easy way to increase the /boot partition. One can try to build another /boot partition and use that but that isn't simple either and prone to problems if the /boot is outside of where that particular BIOS can intepret (aka embedded in an LVM) or jump to.
I have found the simpler method is usually: dump the disks to backup, reinstall the system with 500 to 1000 MB /boot and restore from backups.
You can do this (warning--back up everything first, just in case): -download the grub live CD image (google for it) -burn it to a CD -boot it -use the graphical partition editor to resize and/or move existing partitions to make room for a larger boot then enlarge the /boot. all this may take a while once you tell it to commit your changes, but it isn't hard to do. I've done it several times, as well as smaller changes, and have yet to have a failure (knock on wood).
Does it work with LVM? Hmmm... good question. I think so, but would have to go check to be sure.
Good luck!
Thanks for all of the input, not really sure what if anything I will do. i was hoping it would be easy and i could just create a /boot in root, and copy the actual boot contents to it and use it. wishful thinking i guess. just to give a complete picture here is the current partitioning on the server....in case anyone wants to say anymore. Thanks in advance. Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_bldsrv-lv_root 50G 26G 22G 55% / tmpfs 9.0G 156K 9.0G 1% /dev/shm /dev/sda1 96M 33M 59M 36% /boot /dev/mapper/vg_bldsrv-lv_home 861G 371G 447G 46% /home
Most of this is like speaking another language to me anyway. I'll consider it all. KM
On Tuesday, October 10, 2017 10:42:21 AM, Fred Smith fredex@fcshome.stoneham.ma.us wrote:
On Tue, Oct 10, 2017 at 10:36:16AM -0400, Stephen John Smoogen wrote:
On 10 October 2017 at 09:55, KM info4km@yahoo.com wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates.
if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance. KM
There is no easy way to increase the /boot partition. One can try to build another /boot partition and use that but that isn't simple either and prone to problems if the /boot is outside of where that particular BIOS can intepret (aka embedded in an LVM) or jump to.
I have found the simpler method is usually: dump the disks to backup, reinstall the system with 500 to 1000 MB /boot and restore from backups.
You can do this (warning--back up everything first, just in case): -download the grub live CD image (google for it) -burn it to a CD -boot it -use the graphical partition editor to resize and/or move existing partitions to make room for a larger boot then enlarge the /boot. all this may take a while once you tell it to commit your changes, but it isn't hard to do. I've done it several times, as well as smaller changes, and have yet to have a failure (knock on wood).
Does it work with LVM? Hmmm... good question. I think so, but would have to go check to be sure.
Good luck!
KM wrote:
Thanks for all of the input, not really sure what if anything I will do. i was hoping it would be easy and i could just create a /boot in root, and copy the actual boot contents to it and use it. wishful thinking i guess. just to give a complete picture here is the current partitioning on the server....in case anyone wants to say anymore. Thanks in advance. Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_bldsrv-lv_root 50G 26G 22G 55% / tmpfs 9.0G 156K 9.0G 1% /dev/shm /dev/sda1 96M 33M 59M 36% /boot /dev/mapper/vg_bldsrv-lv_home 861G 371G 447G 46% /home
Most of this is like speaking another language to me anyway. I'll consider it all.
What I would recommend: go out and buy a "small" new h/d, say, 150GB or 250GB. Also get an adapter for it (let me note that I actually bought, a year or two ago, a hot-swap drive bay that fits in a std. tower case...). Then partition that (we've been using 1G for /boot for years), mount it on /mnt, mount newdrive/boot /mnt/newdrive/boot, and rsync -HPavx /. /mnt/newdrive, and rsync -HPavx /boot /mnt/newdrive/boot
Then grub-install /dev/newdrive, and swap drives.
mark
On 10/10/2017 09:53 AM, KM wrote:
Thanks for all of the input, not really sure what if anything I will do. i was hoping it would be easy and i could just create a /boot in root, and copy the actual boot contents to it and use it. wishful thinking i guess. just to give a complete picture here is the current partitioning on the server....in case anyone wants to say anymore. Thanks in advance. Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_bldsrv-lv_root 50G 26G 22G 55% / tmpfs 9.0G 156K 9.0G 1% /dev/shm /dev/sda1 96M 33M 59M 36% /boot /dev/mapper/vg_bldsrv-lv_home 861G 371G 447G 46% /home
Your root filesystem is in an LVM volume. CentOS 6 is still using GRUB legacy, which does not support /boot in LVM.
For you, there really is no way around the messy and delicate process of shrinking and relocating a filesystem and the LVM volumes to make space for a larger /boot partition. Frankly, I would hesitate to do that in place on my own system, and I have quite a bit of experience with doing unspeakable things with LVM volumes. You really need to do that resizing in the context of moving everything to another disk.
If it's a server that you don't want to take down for the time it takes for that procedure, you can do amazing things with pvmove while your system continues to run, but you still need another disk to hold those volumes temporarily.
On 10/10/2017 6:20 PM, Robert Nichols wrote:
Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_bldsrv-lv_root 50G 26G 22G 55% / tmpfs 9.0G 156K 9.0G 1% /dev/shm /dev/sda1 96M 33M 59M 36% /boot /dev/mapper/vg_bldsrv-lv_home 861G 371G 447G 46% /home
Your root filesystem is in an LVM volume. CentOS 6 is still using GRUB legacy, which does not support /boot in LVM.
says up there, /boot is /dev/sda1, this is almost exactly the config of my C6 servers.
On 10/10/2017 6:50 PM, John R Pierce wrote:
Your root filesystem is in an LVM volume. CentOS 6 is still using GRUB legacy, which does not support /boot in LVM.
says up there, /boot is /dev/sda1, this is almost exactly the config of my C6 servers.
never mind, I realized after I sent this, you were talking about him MOVING his /boot to /
On 10/10/2017 09:20 PM, Robert Nichols wrote:
For you, there really is no way around the messy and delicate process of shrinking and relocating a filesystem and the LVM volumes to make space for a larger /boot partition. Frankly, I would hesitate to do that in place on my own system, and I have quite a bit of experience with doing unspeakable things with LVM volumes. You really need to do that resizing in the context of moving everything to another disk.
Agreed. If / and /home are on xfs you can't shrink anyway. I'm not sure if ext4 can be shrunk while mounted (I seem to remember that it can't).
If it's a server that you don't want to take down for the time it takes for that procedure, you can do amazing things with pvmove while your system continues to run, but you still need another disk to hold those volumes temporarily.
As long as there is enough slack space in the volume group you can do this. If there is no slack space you have real problems, especially with XFS (one reason I still use ext4 for many things, and one reason I never fill the volume group to 100%).
I have done the pvmove and filesystem resize dance before, live, with the second hard disk attached via iSCSI. The least fun piece is then resizing the /boot partition and its filesystem. But I had enough slack space in the volume group. What can be done here is unmounting /home, shrinking /home the appropriate amount, and then you have enough slack space to do the shrink and move (not fully live, but semi-live, and you can't have any logged-in users with open files in /home). Shrinking from the end of the filesystem and pv is easy; shrinking from the beginning is hard and prone to errors. (gparted and similar do the move of the end of a partition fine; moving the start is much much harder).
However, if you can shrink enough from the end you can put /boot on the last partition on the disk instead of the first, although you will have to do some grub stanza editing to get rid of /dev/sda1 and replace with the appropriate device for the new /boot. So you could shrink /home, shrink the pv, shrink the partition holding the pv (this is the risky part), then add a partition to the end of the disk for the new /boot. If you've never done this sort of thing before you may want to get someone who has done this sort of thing to do it.
Otherwise, if you feel at all uncomfortable doing this it may just be easier to pull a backup and reinstall.
I searched a bit to see if there is a way to upgrade from CentOS 7 directly to CentOS 8. I found RHEL instructions but not CentOS. Although they probably should be/would be similar, the instructions I found enable a rhel repository to get the leap command, which I can't seem to do in CentOS.
Does anyone know if you can do an upgrade yet. I know they had been working on it in the past.
also - when they say upgrade (for example on the rhel pages), is it in place meaning I can leave my files/data there, or is it strictly a way of installing the OS that is going to wipe out my files?
Thanks in advance. KM
KM via CentOS wrote:
I searched a bit to see if there is a way to upgrade from CentOS 7 directly to CentOS 8. I found RHEL instructions but not CentOS.  Although they probably should be/would be similar, the instructions I found enable a rhel repository to get the leap command, which I can't seem to do in CentOS.
Does anyone know if you can do an upgrade yet. I know they had been working on it in the past.
also - when they say upgrade (for example on the rhel pages), is it in place meaning I can leave my files/data there, or is it strictly a way of installing the OS that is going to wipe out my files?
Your files - data, home directories, etc, SHOULD NOT BE ON THE SAME FILESYSTEM as the o/s: /, /var/, /etc, /usr.
If you didn't do that (the way M$ does), then you're ok - the o/s can be replaced, and it won't hurt anything... just make SURE that you unselect the partitions/drives that everything else is on.
mark
Your answer has nothing to do with the original question which is related to upgrade method and not condition for reinstalling without loosing data.
Sometimes you need to keep your configuration and want to avoid reconfiguring everything, and reimaging your computer keeping /home is not an option. Of course having all user files on a separate filesystem helps when reimaging the OS (that what I do as main developer of SystemImager, but in some circumstances, you may want to just upgrade the OS Like you do when you upgrade iOS-12 to iOS-13 or Android-8 to Android-9 without loosing a single bit of configuration. A mature OS should be able to do upgrade itself without artifacts. MacOS and iOS and now Windows-10 are example of OS that are able to self upgrade from version to version.
Reimaging a computer to perform an upgrade of its OS is just as silly as rebooting a computer to restart a service (that's what windows-10 still do).
That said, the original question is more like: is there a dnf dist-upgrade or similar to what is available on fedora for upgrading centos-7 to centos-8:
$ sudo dnf upgrade --refresh # Make sur packages are up to date in current OS release and that there are no dependancies issues. $ sudo dnf install dnf-plugin-system-upgrade # Add the OS upgrade plugin $ sudo dnf system-upgrade download --refresh --releasever=30 # example for fedora-29 to 30 $ sudo dnf system-upgrade reboot
As of writing, dnf-plugin-system-upgrade package is not available in centos-7 and thus this method is not available to upgrade centos-7 to centos-8.
Olivier.
Le 01/10/2019 17:21, « CentOS au nom de mark » <centos-bounces@centos.org au nom de m.roth@5-cent.us> a écrit :
KM via CentOS wrote: > I searched a bit to see if there is a way to upgrade from CentOS 7 > directly to CentOS 8. I found RHEL instructions but not CentOS.  > Although they probably should be/would be similar, the instructions I > found enable a rhel repository to get the leap command, which I can't > seem to do in CentOS. > > Does anyone know if you can do an upgrade yet. I know they had been > working on it in the past. > > also - when they say upgrade (for example on the rhel pages), is it in > place meaning I can leave my files/data there, or is it strictly a way of > installing the OS that is going to wipe out my files?
Your files - data, home directories, etc, SHOULD NOT BE ON THE SAME FILESYSTEM as the o/s: /, /var/, /etc, /usr.
If you didn't do that (the way M$ does), then you're ok - the o/s can be replaced, and it won't hurt anything... just make SURE that you unselect the partitions/drives that everything else is on.
mark _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Your answer has nothing to do with the original question which is related to upgrade method and not condition for reinstalling without loosing data.
After 40 years of upgrading many different operating systems, Windows (from 3.1 to 10), CentOS 6 to 8, Ubuntu, Fedora, Red Hat, AT&T Unix, VAX VMS; I have never observed an upgrade from one major version to the next to work. The last one I tried using their "upgrade process" was Ubuntu 18 to 19. Didn't work.
When a new major version of any o/s is released, I have found it best to save what application data I can, delete all partitions on the target boot disk, and then install from scratch.
I learned years ago to keep application data out of system directories, ideally on a separate drive that can be mounted on the new installation. Yes, you do loose your settings, but that's why it would be wise to stick with the defaults, if possible. Yes, the database is always in a system directory by default, so that's why you do a dump before the upgrade. My "cheat-sheet" of things to do during an upgrade is about 10 pages long.
If you do have to restore from a backup, be sure you do not restore any system directories (like /etc/fstab). I made this mistake, once!
System admins must learn to bite the bullet on this part of their job.
Todd Merriman
On Tue, 1 Oct 2019 at 14:00, MAILIST mailist@toolz.com wrote:
Your answer has nothing to do with the original question which is related to upgrade method and not condition for reinstalling without loosing data.
After 40 years of upgrading many different operating systems, Windows (from 3.1 to 10), CentOS 6 to 8, Ubuntu, Fedora, Red Hat, AT&T Unix, VAX VMS; I have never observed an upgrade from one major version to the next to work. The last one I tried using their "upgrade process" was Ubuntu 18 to 19. Didn't work.
I would mostly agree with the added caveat.. it can be made to work, but you need to do a LOT of work continually to make it happen. Upgrade programs are usually tested for each Unix and Linux in the following manner:
For A in Arch; do For B in Hardware-Type; do For X in Oldest_Supported_Major to Youngest_Supported_Major; do For Y from Oldest_Support_Minor to Youngest_Supported_Minor; do Install the OS-X.Y from original media. (maybe) Make changes as listed in manual (if you are lucky) Make known changes which broke major customer last time Run upgrade to OS-N.0 Reboot. If system boots; Pass else Fail; fi Done; Done; Done; Done;
Fix all the Fails that you can.. or document that they can't be fixed in tech support. That still probably takes several QA people days of work to go through for an upgrade. Most systems that are lived in quickly fall outside of the scope of what the upgrade tests can find OR what the upgrade program can determine what to do. This is the main reason why you should do a rollout of a new operating system with a plan beyond yum --upgrade-system --YOLO
So to make it work, what you normally have to do is continually treat your system like it could be nuked at any moment and you need to rebuild it from whatever is latest. That takes a lot of controls and work which most of us don't have time for. I have seen someone who has incredibly strict rules on their CM upgrade a box from Red Hat Linux 5 to Red Hat Enterprise Linux 5 to show it can be done..[this was a box with databases, website tools, etc etc.. the CM was larger than the database dump]
When a new major version of any o/s is released, I have found it best to save what application data I can, delete all partitions on the target boot disk, and then install from scratch.
I learned years ago to keep application data out of system directories, ideally on a separate drive that can be mounted on the new installation. Yes, you do loose your settings, but that's why it would be wise to stick with the defaults, if possible. Yes, the database is always in a system directory by default, so that's why you do a dump before the upgrade. My "cheat-sheet" of things to do during an upgrade is about 10 pages long.
If you do have to restore from a backup, be sure you do not restore any system directories (like /etc/fstab). I made this mistake, once!
System admins must learn to bite the bullet on this part of their job.
Todd Merriman _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 10/1/19 10:57 AM, MAILIST wrote:
Your answer has nothing to do with the original question which is related to upgrade method and not condition for reinstalling without loosing data.
After 40 years of upgrading many different operating systems, Windows (from 3.1 to 10), CentOS 6 to 8, Ubuntu, Fedora, Red Hat, AT&T Unix, VAX VMS; I have never observed an upgrade from one major version to the next to work. The last one I tried using their "upgrade process" was Ubuntu 18 to 19. Didn't work.
Not trying to undermine what you said. I totally believe that different situations deserve different solutions.
In my career, I've managed many Debian, Ubuntu, Fedora, and CentOS systems, and I found that in-situ upgrading of Debian, Ubuntu, and Fedora are usually easy and convenient. If you are using 3rd party repos/PPAs you sometimes need to disable them and/or remove some packages, but nothing can't be solved by a few apt/yum/dnf commands.
Most of my Debian/Ubuntu servers only need to be installed once when we got the hardware, and they are upgraded through several major versions before being retired. Debian has especially well written documentation for each release on how to upgrade from previous versions.
I've about three dozen shared and heavily used Fedora workstations that haven't been reinstalled since 2012? And we have upgraded them through each Fedora release using yum/dnf. The only problem I could remember was when we found that our initial allocation for the /boot partition turned out to be too small in recent years, when kernels are becoming monstrous. We simply adjusted the partitions and rsync'ed the whole root directory from backup. Still didn't do reinstall. These upgrades were usually done by volunteer student admins following Fedora's documentation, and few of them complained.
Same can be said for our Ubuntu laptops. In most cases, end user just needed to click Upgrade when a new major version was released, and most of them went through without much trouble. Although the new versions were usually buggy in many ways, it usually wasn't the upgrade process to be blamed.
However, that can't be said for CentOS/RHEL. You are totally right that CentOS are better reinstalled/imaged rather than upgraded.
On Tue, Oct 1, 2019 at 1:32 PM Elliot elliot.li.tech@gmail.com wrote:
In my career, I've managed many Debian, Ubuntu, Fedora, and CentOS systems, and I found that in-situ upgrading of Debian, Ubuntu, and Fedora are usually easy and convenient.
I'll concur in my experience. I've upgraded a number of Ubuntu servers through major version updates. The longest jump I have is on Fedora Server. One particularly central and critical server was built before I arrived, with Fedora 18. I have personally upgraded that on every release starting from 21 on up to the current 30. It's certainly possible to have major version upgrades be reliable. The big trick is to read release notes for any software you are using and note any issues they mention.
On Tue, 1 Oct 2019 13:57:19 -0400 "MAILIST" mailist@toolz.com wrote:
Your answer has nothing to do with the original question which is related to upgrade method and not condition for reinstalling without loosing data.
After 40 years of upgrading many different operating systems, Windows (from 3.1 to 10), CentOS 6 to 8, Ubuntu, Fedora, Red Hat, AT&T Unix, VAX VMS; I have never observed an upgrade from one major version to the next to work. The last one I tried using their "upgrade process" was Ubuntu 18 to 19. Didn't work.
It is not true for the VAX/VMS. My first version was 1.0. And it was working (sometimes) for Fedora. BR, Bob
On 2019-10-01 12:57, MAILIST wrote:
Your answer has nothing to do with the original question which is related to upgrade method and not condition for reinstalling without loosing data.
After 40 years of upgrading many different operating systems, Windows (from 3.1 to 10), CentOS 6 to 8, Ubuntu, Fedora, Red Hat, AT&T Unix, VAX VMS; I have never observed an upgrade from one major version to the next to work. The last one I tried using their "upgrade process" was Ubuntu 18 to 19. Didn't work.
I routinely upgrade FreeBSD. Last time it was 11.3 to 12.0. Always smooth. Maybe I'm just lucky...
Valeri
When a new major version of any o/s is released, I have found it best to save what application data I can, delete all partitions on the target boot disk, and then install from scratch.
I learned years ago to keep application data out of system directories, ideally on a separate drive that can be mounted on the new installation. Yes, you do loose your settings, but that's why it would be wise to stick with the defaults, if possible. Yes, the database is always in a system directory by default, so that's why you do a dump before the upgrade. My "cheat-sheet" of things to do during an upgrade is about 10 pages long.
If you do have to restore from a backup, be sure you do not restore any system directories (like /etc/fstab). I made this mistake, once!
System admins must learn to bite the bullet on this part of their job.
Todd Merriman _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Am 01.10.2019 um 22:19 schrieb Valeri Galtsev galtsev@kicp.uchicago.edu:
I routinely upgrade FreeBSD. Last time it was 11.3 to 12.0. Always smooth. Maybe I'm just lucky...
No, it works very well.
But it’s designed with an eventual upgrade in mind.
Le 01/10/2019 à 19:57, MAILIST a écrit :
After 40 years of upgrading many different operating systems, Windows (from 3.1 to 10), CentOS 6 to 8, Ubuntu, Fedora, Red Hat, AT&T Unix, VAX VMS; I have never observed an upgrade from one major version to the next to work. The last one I tried using their "upgrade process" was Ubuntu 18 to 19. Didn't work.
OpenSUSE Leap upgrades from one major version to the next work fine, provided you know what you're doing.
* https://www.microlinux.fr/opensuse-leap-update-15-1/
In the past, I also performed major upgrades on Slackware servers, which were always perfectly documented by the distributor and worked without drama.
Cheers,
Niki
On Tue, 01 Oct, 2019 at 13:57:19 -0400, MAILIST wrote:
After 40 years of upgrading many different operating systems, Windows (from 3.1 to 10), CentOS 6 to 8, Ubuntu, Fedora, Red Hat, AT&T Unix, VAX VMS; I have never observed an upgrade from one major version to the next to work. The last one I tried using their "upgrade process" was Ubuntu 18 to 19. Didn't work.
I've been running Debian stable on various machines over the course of about 17 years. I have *never* had to reinstall.
On 01/10/19 23:38, Liam O'Toole wrote:
On Tue, 01 Oct, 2019 at 13:57:19 -0400, MAILIST wrote:
After 40 years of upgrading many different operating systems, Windows (from 3.1 to 10), CentOS 6 to 8, Ubuntu, Fedora, Red Hat, AT&T Unix, VAX VMS; I have never observed an upgrade from one major version to the next to work. The last one I tried using their "upgrade process" was Ubuntu 18 to 19. Didn't work.
I've been running Debian stable on various machines over the course of about 17 years. I have *never* had to reinstall. _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Hi to all members, I never upgraded from major to major, always preferred a new install by default. In the last months I'm seeing upgrade between major release under another view.
CentOS does not support (at least C7) the upgrade to 8 and I think that will remain so for many years. First of all I think that if we can upgrade from major to major, 10 years of support would not be needed but I think also that the mainstream supports releases for 10 years to avoid this type of problem (upgrade between major release).
For a distro like CentOS,Fedora,Debian,OpenSUSE (based on community) there would be no problem, without support you are alone and you could do all what you want: You broke your server? It's a your problem.
Also if I never upgraded to a new major release (like in fedora, debian, ubuntu) I think that the to perform a successfull upgrade you must avoid to install third party repo, app, custom rpm and so on: you need to stay as much as possible in the repositories and CentOS has a small repository (in fact we need EPEL that is considered third repo). Consider also the great changes between each centos release. In this release we get podman, nftables, appstreams, many packages removed and others changed version and other. Those are big changes. How the system will reacts to this?
For example my C7 workstation have kde plasma 4 installed. What would happen if I upgrade to C8 when kde is deprecated on EL8? I could have a no working workstation and this could be a problem. This is a stupid example, take for example the change from docket to podman, or better an external rpm compiled for C7 and try to run on 8. A pita.
Now, for a moment, imagine that RH will permit upgrade between major releases. Every supported customers probably would be need support for this process. Considering also that every customer could have his packages etc, how can RH support manage this? It's too risky when you have corps as customers.
best regards.
KM info4km@yahoo.com wrote:
if it's not easy to actually increase it,
It's possible to resize partitions. I use System Rescue CD, http://www.system-rescue-cd.org/
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of KM Sent: den 10 oktober 2017 15:55 To: CentOS Mailing List centos@centos.org Subject: [CentOS] /boot partition too small
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates. if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance.
Been there done that.
A simple solution is to edit /etc/yum.conf and change the line
installonly_limit=5
to e.g.
installonly_limit=3
and see if that's enough with the existing boot partition size.
A "yum update" should delete the two oldest kernel images.
-- //Sorin
On 10/10/17 15:55, KM wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates. if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance.
Hi,
Since a lot of people seem to say none of the above can be done, I'm starting to feel slightly unsure, but I though gparted could extend, shrink and move partitions while preserving data. You'd have to use the "live" version when operating on system partitions. See https://gparted.org
- T
KM _______________________________________________ CentOS mailing list CentOS@centos.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.centos.org_mailma...
On 10/11/2017 12:04 AM, Toralf Lund wrote:
On 10/10/17 15:55, KM wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates. if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance.
Hi,
Since a lot of people seem to say none of the above can be done, I'm starting to feel slightly unsure, but I though gparted could extend, shrink and move partitions while preserving data. You'd have to use the "live" version when operating on system partitions. See https://gparted.org
I would prefer boot up in single, and partition a new boot device, with the larger /dev/sda1, and whatever else lvm stuff, then copy the file systems across with dump or xfsdump or whatever, swap the devices and boot. this way the old disk is a safe backup. heck, /boot can be a SD card or USB stick :-p
On 10/11/2017 02:04 AM, Toralf Lund wrote:
On 10/10/17 15:55, KM wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates. if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance.
Hi,
Since a lot of people seem to say none of the above can be done, I'm starting to feel slightly unsure, but I though gparted could extend, shrink and move partitions while preserving data.
You would be asking gparted to: 1. Reach inside an LVM PV and shrink one filesystem and its LV, 2. Rearrange the extents inside the PV to make free space at the beginning, 3. Move the start of the PV and adjust all of the starting offsets for the LVs, 4. Finally, enlarge partition 1 into the freed-up space.
Even if gparted was willing to attempt that, there is no way I would trust it to do it correctly.
On 11/10/17 15:22, Robert Nichols wrote:
On 10/11/2017 02:04 AM, Toralf Lund wrote:
On 10/10/17 15:55, KM wrote:
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates. if it's not easy to actually increase it, is it safe to take a chunk in my root filesystem (like /new.boot or something) and just mount it as /boot from now on so it uses the space or is that not a good idea? I am sure I could easily copy the rpms/kernel stuff over to it and then unmounts the real /boot and mount this new area as /boot. Can you administrators let me know what you think of all this? Thanks in advance.
Hi,
Since a lot of people seem to say none of the above can be done, I'm starting to feel slightly unsure, but I though gparted could extend, shrink and move partitions while preserving data.
You would be asking gparted to: 1. Reach inside an LVM PV and shrink one filesystem and its LV, 2. Rearrange the extents inside the PV to make free space at the beginning, 3. Move the start of the PV and adjust all of the starting offsets for the LVs, 4. Finally, enlarge partition 1 into the freed-up space.
Even if gparted was willing to attempt that, there is no way I would trust it to do it correctly.
Quite. I'd never try this without a backup, of course. In fact, I've only ever used gparted in situations where I had a system dump already. Still, it could save you from a bit of work, as in, if it does succeed, you won't have to do a full recovery. Also, I'm not really sure about the state of the LVM support, now that you mention it. (But there is supposed to be *something* in that area.)
- Toralf
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Toralf Lund Sent: den 12 oktober 2017 10:15 To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] [External] /boot partition too small
Since a lot of people seem to say none of the above can be done, I'm starting to feel slightly unsure, but I though gparted could extend, shrink and move partitions while preserving data.
You would be asking gparted to: 1. Reach inside an LVM PV and shrink one filesystem and its LV, 2. Rearrange the extents inside the PV to make free space at the beginning, 3. Move the start of the PV and adjust all of the starting offsets for the LVs, 4. Finally, enlarge partition 1 into the freed-up space.
Even if gparted was willing to attempt that, there is no way I would trust it to do it correctly.
Quite. I'd never try this without a backup, of course. In fact, I've only ever used gparted in situations where I had a system dump already. Still, it could save you from a bit of work, as in, if it does succeed, you won't have to do a full recovery. Also, I'm not really sure about the state of the LVM support, now that you mention it. (But there is supposed to be *something* in that area.)
Supposedly the below tool should be able to handle LVM volumes, and is bootable from CD. It costs though.
https://www.partitionwizard.com/partition-wizard-bootable-cd.html
Maybe helps a bit? -- //Sorin
Stupid question: can't you do
rpm -qa | grep ^kernel
and then
rpm -e <kernel file>
On Thu, Oct 12, 2017 at 4:24 AM, Sorin Srbu Sorin.Srbu@orgfarm.uu.se wrote:
-----Original Message----- From: CentOS [mailto:centos-bounces@centos.org] On Behalf Of Toralf Lund Sent: den 12 oktober 2017 10:15 To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] [External] /boot partition too small
Since a lot of people seem to say none of the above can be done, I'm starting to feel slightly unsure, but I though gparted could extend, shrink and move partitions while preserving data.
You would be asking gparted to: 1. Reach inside an LVM PV and shrink one filesystem and its LV, 2. Rearrange the extents inside the PV to make free space at the beginning, 3. Move the start of the PV and adjust all of the starting offsets for the LVs, 4. Finally, enlarge partition 1 into the freed-up space.
Even if gparted was willing to attempt that, there is no way I would trust it to do it correctly.
Quite. I'd never try this without a backup, of course. In fact, I've only ever used gparted in situations where I had a system dump already. Still, it could save you from a bit of work, as in, if it does succeed, you won't have to do a full recovery. Also, I'm not really sure about the state of the LVM support, now that you mention it. (But there is supposed to be *something* in that area.)
Supposedly the below tool should be able to handle LVM volumes, and is bootable from CD. It costs though.
https://www.partitionwizard.com/partition-wizard-bootable-cd.html
Maybe helps a bit?
//Sorin _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Thu, 12 Oct 2017, Mauricio Tavares wrote:
Stupid question: can't you do
rpm -qa | grep ^kernel
and then
rpm -e <kernel file>
With 100Mbyte /boot on a non-EFI system, I wouldn't have enough room for two kernels, so updates would be tricky.
jh
On Thu, Oct 12, 2017 at 8:38 AM, John Hodrien J.H.Hodrien@leeds.ac.uk wrote:
On Thu, 12 Oct 2017, Mauricio Tavares wrote:
Stupid question: can't you do
rpm -qa | grep ^kernel
and then
rpm -e <kernel file>
With 100Mbyte /boot on a non-EFI system, I wouldn't have enough room for two kernels, so updates would be tricky.
You have a point there. I was thinking the OP's situation was /boot is a reasonable size but just got filled up because it was not being monitored. And, as a result, he made yum sad. So now all he wants is to clean it up just enough to use other stuff, and then as mentioned before reconfigure grub2.cfg to keep only a couple of 3 kernels around.
Not going to say that happened to me in ubuntu before. O:)
jh
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Le 10/10/2017 à 15:55, KM a écrit :
First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I can't do yum updates.
Here's a possible solution to your problem:
# yum install yum-utils # package-cleanup --oldkernels --count=1 # yum update
Prevent this from happening again by editing /etc/yum.conf:
installonly_limit=2 (default value 5, reduce to 2)
Cheers,
Niki
-
Alessandro Baggi -
Alice Wonder -
Bob Marcan -
Elliot -
Fred Smith -
John Hodrien -
John R Pierce -
Jon Pruente -
KM -
LAHAYE Olivier -
Lamar Owen -
Liam O'Toole -
m.roth＠5-cent.us -
MAILIST -
mark
-
Mauricio Tavares -
Nicolas Kovacs -
Pete Biggs -
Phil Perry -
Rainer Duffner -
Robert Nichols -
Sorin Srbu -
Stephen John Smoogen -
Toralf Lund -
Valeri Galtsev -
Vanhorn, Mike -
Yves Bellefeuille