BRRABill's Field Report With Linux
-
Yours is about 50% smaller then the others posted.
Maybe consider extending it?
-
I've run into this on two of the last 3 systems I've tried to upgrade... I just remove all but the most recent kernel files, and then run the upgrade again.
Ubuntu 15.10 at initial Install
Filesystem Size Used Avail Use% Mounted on /dev/vda1 236M 111M 113M 50% /bootUbuntu 14.04 at initial install
Filesystem Size Used Avail Use% Mounted on /dev/sda1 134M 72M 53M 58% /bootKVM Server on Ubuntu 15.10: No separate /boot partition (root FS is ext4)
OpenSuSE Tumbleweed: No separate /boot partition (root FS is btrfs)
-
@dafyre said in BRRABill's Field Report With Linux:
I've run into this on two of the last 3 systems I've tried to upgrade... I just remove all but the most recent kernel files, and then run the upgrade again.
That's what I am doing, though only the absolute oldest, as the Google said not remove too many recent ones in case anything depends on them.
But, you are saying it's safe to delete everything except the one running? (Obviously.)
-
I've run into this multiple times in the past with Ubuntu. For some reason old kernel images aren't removed when space is running low. To check your current image use
uname -r. Then you can uninstall the older images. -
@stacksofplates said in BRRABill's Field Report With Linux:
I've run into this multiple times in the past with Ubuntu. For some reason old kernel images aren't removed when space is running low. To check your current image use
uname -r. Then you can uninstall the older images.And I can delete every kernel image I am not using?
-
@BRRABill said in BRRABill's Field Report With Linux:
@stacksofplates said in BRRABill's Field Report With Linux:
I've run into this multiple times in the past with Ubuntu. For some reason old kernel images aren't removed when space is running low. To check your current image use
uname -r. Then you can uninstall the older images.And I can delete every kernel image I am not using?
I ask because I did an "autopurge" and it left two of them.
-
You can but I'd keep one or two extra to fall back on.
-
@BRRABill said in BRRABill's Field Report With Linux:
@dafyre said in BRRABill's Field Report With Linux:
I've run into this on two of the last 3 systems I've tried to upgrade... I just remove all but the most recent kernel files, and then run the upgrade again.
That's what I am doing, though only the absolute oldest, as the Google said not remove too many recent ones in case anything depends on them.
But, you are saying it's safe to delete everything except the one running? (Obviously.)
Essentially,. that's what I do... But I copy the /boot directory somewhere else on my main partition just in case I need to put it back, lol.
-
Advanced OS. Bah!
-
@BRRABill said in BRRABill's Field Report With Linux:
@stacksofplates said in BRRABill's Field Report With Linux:
I've run into this multiple times in the past with Ubuntu. For some reason old kernel images aren't removed when space is running low. To check your current image use
uname -r. Then you can uninstall the older images.And I can delete every kernel image I am not using?
Can, yes. Best practice is to always keep at least one old one. But if you've been using the current one for a while, that's unnecessary.
-
@BRRABill said in BRRABill's Field Report With Linux:
Advanced OS. Bah!
No one ever claimed Ubuntu was advanced.
-
-
@BRRABill said in BRRABill's Field Report With Linux:
Advanced OS. Bah!
Advanced? More like a mishmash of old and new that ends up breaking lots of things.
-
So, was having some issues with my GrayLog instance. I have a feeling that it has run out of space. Would you agree?
I think LVM is confusing me again.
ubuntu@graylog:~$ df -h Filesystem Size Used Avail Use% Mounted on udev 2.0G 12K 2.0G 1% /dev tmpfs 395M 420K 395M 1% /run /dev/dm-0 15G 15G 0 100% / none 4.0K 0 4.0K 0% /sys/fs/cgroup none 5.0M 0 5.0M 0% /run/lock none 2.0G 0 2.0G 0% /run/shm none 100M 0 100M 0% /run/user /dev/xvda1 236M 70M 154M 32% /boot overflow 1.0M 284K 740K 28% /tmp -
Yes, /dev/dm-o is full, which completely breaks graylog.
I had this happen to me as well, and just built a new vm. Once the VM was operational I reduced the indices by half.
-
@BRRABill said in BRRABill's Field Report With Linux:
So, was having some issues with my GrayLog instance. I have a feeling that it has run out of space. Would you agree?
I think LVM is confusing me again.
ubuntu@graylog:~$ df -h Filesystem Size Used Avail Use% Mounted on /dev/dm-0 15G 15G 0 100% /Yes you're out of space on your root directory.
-
@DustinB3403 said in BRRABill's Field Report With Linux:
Yes, /dev/dm-o is full, which completely breaks graylog.
I had this happen to me as well, and just built a new vm. Once the VM was operational I reduced the indices by half.
I figure this would be a good Linux learning experience.
I was thinking of following this link. It's for VMWare, but most of the Ubuntu commands should be the same, I would think.
http://docs.graylog.org/en/1.3/pages/installation/graylog_ctl.html#extend-disk-space
-
@DustinB3403 said in BRRABill's Field Report With Linux:
Yes, /dev/dm-o is full, which completely breaks graylog.
I had this happen to me as well, and just built a new vm. Once the VM was operational I reduced the indices by half.
What does that do to storage size?
I had a Splunk instance running for weeks and never had any issues like this, which is why it surprised me.
-
@BRRABill Yeah I was in the middle of bigger issues, and just didn't care to "fix" it.
I can copy the MAC address to make the same reservation, so no issues from my point.
The logs just sit on XS I believe if the log server can't be reached.
-
@BRRABill said in BRRABill's Field Report With Linux:
@DustinB3403 said in BRRABill's Field Report With Linux:
Yes, /dev/dm-o is full, which completely breaks graylog.
I had this happen to me as well, and just built a new vm. Once the VM was operational I reduced the indices by half.
I figure this would be a good Linux learning experience.
I was thinking of following this link. It's for VMWare, but most of the Ubuntu commands should be the same, I would think.
http://docs.graylog.org/en/1.3/pages/installation/graylog_ctl.html#extend-disk-space
In these directions, it says ...
"In order to extend the disk space mount a second drive on this path. Make sure to move old data to the new drive before and give the graylog user permissions to read and write here."Couldn't you also just extend the (whatever) ?
