search for: 371g

On Tue, Oct 10, 2017 at 10:36:16AM -0400, Stephen John Smoogen wrote: > On 10 October 2017 at 09:55, KM <info4km at 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

...ze? 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...

...ted 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. -- john r pierce, recycling bits in santa cruz

...vance. 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 at fcshome.stoneham.ma.us> wrote: On Tue, Oct 10, 2017 at 10:36:16AM -0400, Stephen John Smoogen...

...owever. The kernel logs were on a different filesystem. Here is the kern.log:http://fpaste.org/9383/36729191/ My setup is two 2TB hard drives in raid 1. They are both sata drives so as far as I know the USB disconnect line isn''t referring to btrfs. output of df -h: /dev/sdb1 3.7T 3.2T 371G 90% /mount/point I haven''t figured out how to reproduce the bug. -- Stephen -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

...64 close(3) = 0 open("/dev/urandom", O_RDONLY) = 3 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 read(3, "\340\232\354\204\366\215{\31\216\302\264o\303\324fx\3679P^\2045\346N\267^\371G\252\206\23\225"..., 64) = 64 close(3) = 0 futex(0xb6db61d8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 gettimeofday({1420299769, 765521}, NULL) = 0 gettimeofday({1420299769, 766695}, NULL) = 0 gettimeofday({1420299769, 768022}, NULL) = 0 gettimeofday({1420299769, 769054...

...>> open("/dev/urandom", O_RDONLY) = 3 >> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 >> fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 >> read(3, >> "\340\232\354\204\366\215{\31\216\302\264o\303\324fx\3679P^\2045\346N\267^\371G\252\206\23\225"..., >> 64) = 64 >> close(3) = 0 >> futex(0xb6db61d8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 >> gettimeofday({1420299769, 765521}, NULL) = 0 >> gettimeofday({1420299769, 766695}, NULL) = 0 >> gettimeofday({14202997...

...m", O_RDONLY) = 3 >>>> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 >>>> fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 >>>> read(3, >>>> "\340\232\354\204\366\215{\31\216\302\264o\303\324fx\3679P^\2045\346N\267^\371G\252\206\23\225"..., >>>> 64) = 64 >>>> close(3) = 0 >>>> futex(0xb6db61d8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 >>>> gettimeofday({1420299769, 765521}, NULL) = 0 >>>> gettimeofday({1420299769, 766695}, N...

...= 0 > open("/dev/urandom", O_RDONLY) = 3 > fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 > fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 > read(3, > "\340\232\354\204\366\215{\31\216\302\264o\303\324fx\3679P^\2045\346N\267^\371G\252\206\23\225"..., > 64) = 64 > close(3) = 0 > futex(0xb6db61d8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 > gettimeofday({1420299769, 765521}, NULL) = 0 > gettimeofday({1420299769, 766695}, NULL) = 0 > gettimeofday({1420299769, 768022}, NULL) = 0 &...

...quot;/dev/urandom", O_RDONLY) = 3 >>> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 >>> fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 9), ...}) = 0 >>> read(3, >>> "\340\232\354\204\366\215{\31\216\302\264o\303\324fx\3679P^\2045\346N\267^\371G\252\206\23\225"..., >>> 64) = 64 >>> close(3) = 0 >>> futex(0xb6db61d8, FUTEX_WAKE_PRIVATE, 2147483647) = 0 >>> gettimeofday({1420299769, 765521}, NULL) = 0 >>> gettimeofday({1420299769, 766695}, NULL) = 0 >>&gt...

...40K RW GLB NX pte [ 0.035058] 0xffff96a30002a000-0xffff96a300200000 1880K pte [ 0.035062] 0xffff96a300200000-0xffff96a340000000 1022M pmd [ 0.035065] 0xffff96a340000000-0xffff970000000000 371G pud [ 0.035067] 0xffff970000000000-0xffffef0000000000 88T pgd [ 0.035069] 0xffffef0000000000-0xffffef0980000000 38G pud [ 0.035071] 0xffffef0980000000-0xffffef0982000000 32M...