|
This is my /boot on the Fedora laptop I'm currently typing on:code:I run 'dnf check-update ; dnf update' just about every day, so Redhat must be doing something right about cleaning up old kernels.
|
#
?
Jul 7, 2018 18:24
|
|
|
|
| # ? Jun 10, 2024 15:21 |
|
|
Anyway, I want to learn how to set up kerberos auth on my home network. It's something that gets used at work, so I feel that a homelab version will stand me in good stead. I've got a small CentOS VM running on my home server. What can I do to get basic kerberos working that's not gonna blow my mind too much? I'm thinking maybe setting up a samba share on another VM and authing it using kerberos. Do I need to start dicking around with LDAP too? Most of my home network is Linux. Just one Windows box. I don't mind about leaving the Windows box out of this. I just want to get samba/kerberos auth working on two or three Linux machines and then tear it down and do it again for good practice.
|
|
#
?
Jul 7, 2018 18:34
|
|
|
Fedora cleans up old kernels. For KRB, it's pretty easy. You need ntp working, though (hopefully a local server). It's better with DNS and dynamic DHCP. Honestly, I'd set up a VM with AD and use that. Or IPA. Or if you want to do it yourself, use smb4 and follow https://www.kania-online.de/wp-content/uploads/2017/06/ddns.pdf There are a lot of moving parts to make it bulletproof, and dynamic dns+DHCP is gold no matter what
|
|
#
?
Jul 7, 2018 19:03
|
|
|
apropos man posted:Is it possible that you've upgraded the kernel so many times that /boot has become full of kernel config files? autoclean spat out a whole bunch of 'Del ...' lines, but when I re-ran the df command there wasn't any extra space. autoremove tried to clear up stuff, but evidently there's not enough space for it to do what it needs: pre:Do you want to continue? [Y/n] y (Reading database ... 513577 files and directories currently installed.) Removing linux-image-extra-4.13.0-43-generic (4.13.0-43.48~16.04.1) ... depmod: FATAL: could not load /boot/System.map-4.13.0-43-generic: No such file or directory run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.13.0-43-generic /boot/vmlinuz-4.13.0-43-generic run-parts: executing /etc/kernel/postinst.d/dkms 4.13.0-43-generic /boot/vmlinuz-4.13.0-43-generic run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.13.0-43-generic /boot/vmlinuz-4.13.0-43-generic update-initramfs: Generating /boot/initrd.img-4.13.0-43-generic Warning: No support for locale: en_US.utf8 depmod: WARNING: could not open /var/tmp/mkinitramfs_KKsR5c/lib/modules/4.13.0-43-generic/modules.order: No such file or directory depmod: WARNING: could not open /var/tmp/mkinitramfs_KKsR5c/lib/modules/4.13.0-43-generic/modules.builtin: No such file or directory gzip: stdout: No space left on device E: mkinitramfs failure cpio 141 gzip 1 update-initramfs: failed for /boot/initrd.img-4.13.0-43-generic with 1. run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 dpkg: error processing package linux-image-extra-4.13.0-43-generic (--remove): subprocess installed post-removal script returned error exit status 1 Removing mokutil (0.3.0-0ubuntu3) ... Processing triggers for man-db (2.7.5-1) ... Errors were encountered while processing: linux-image-extra-4.13.0-43-generic E: Sub-process /usr/bin/dpkg returned an error code (1)
|
|
#
?
Jul 7, 2018 19:35
|
|
|
evol262 posted:Fedora cleans up old kernels. Cool. I'll look into doing it that way. Cheers. Does CentOS not clear up its kernels also? Here's the boot part on one of my longstanding CentOS hosts: code:code:
|
|
#
?
Jul 7, 2018 19:39
|
|
|
hooah posted:autoclean spat out a whole bunch of 'Del ...' lines, but when I re-ran the df command there wasn't any extra space. autoremove tried to clear up stuff, but evidently there's not enough space for it to do what it needs: I'm no expert on this, but I'd look into manually removing a kernel or two (and associated configs for those particular kernels), then running autoclean again when the system has more space. Reboot after cleaning your kernels, of course.
|
|
#
?
Jul 7, 2018 19:42
|
|
|
rhel and derivatives do clean up old kernels, but they didn't always. Don't remember anymore when they fixed it. These days they keep the kernel the system was installed with, the previous kernel and the most recently installed kernel.
|
|
#
?
Jul 7, 2018 19:43
|
|
|
Yeah, explains why I get a choice of three (from memory) when I boot my laptop: initial kernel which was F27 but now F28, last working one and current one. I don't get to see my CentOS boot screens much because all but one are headless and the one that isn't headless rarely sees a reboot. That's a lovely setup on Mint that doesn't appear to clear things up. Last time I used Mint, which was aeons ago, they had a noob friendly GUI to handle updates if you didn't want to use the package manager directly, so gawd knows whether hooah is having problems resulting from using the GUI updater or the shell.
|
|
#
?
Jul 7, 2018 20:03
|
|
|
xzzy posted:rhel and derivatives do clean up old kernels, but they didn't always. Don't remember anymore when they fixed it. my centos 7.2 box has like 6 kernels in grub, i think. been a while since i looked tho, since it has no kvm attached
|
|
#
?
Jul 7, 2018 20:54
|
|
|
In both fedora and CentOS (and RH) you can change the number of kernels it keeps by changing the installonly_limit param in yum.conf (or dnf.conf for fedora). By default it can be rather large, but 3 is a nice , small enough number.
|
|
#
?
Jul 7, 2018 21:08
|
|
|
Ubuntu packages purge-old-kernels.sh into the OS on 14+ as purge-old-kernels, I run it on cron with no issues. If boot is totally full and autoremove/update fails, you can do uname -r, then pick an older kernel that isn't that version and move it into /var/tmp before you run apt install -f; purge-old-kernels; update-grub
|
|
#
?
Jul 7, 2018 22:15
|
|
|
xzzy posted:rhel and derivatives do clean up old kernels, but they didn't always. Don't remember anymore when they fixed it. RHEL (yum) has had the limit since at least 6.0 and probably in 5 as well. It is simply the three (by default) most recently installed versions of the given package. Volguus posted:In both fedora and CentOS (and RH) you can change the number of kernels it keeps by changing the installonly_limit param in yum.conf (or dnf.conf for fedora). By default it can be rather large, but 3 is a nice , small enough number. As above, the default is three out of the box. If you have kernel-debug then that is of course a separate package. And if you are some weird who still uses the rpm command to install poo poo then yeah you could end up with more than expected.
|
|
#
?
Jul 7, 2018 22:26
|
|
Associate Christ
|
apropos man posted:I'm no expert on this, but I'd look into manually removing a kernel or two (and associated configs for those particular kernels), then running autoclean again when the system has more space. Reboot after cleaning your kernels, of course. Alright, I tried manually removing a kernel via the Update Manager, but it spat out all the crap in this pastebin. From what I can see it looks like there's insufficient space to even remove a kernel.
|
|
#
?
Jul 8, 2018 02:14
|
|
|
hooah posted:Alright, I tried manually removing a kernel via the Update Manager, but it spat out all the crap in this pastebin. From what I can see it looks like there's insufficient space to even remove a kernel.
|
|
#
?
Jul 8, 2018 02:37
|
|
|
other people posted:
ah, i have the debug packages installed, which explains why i have 6ish. stupid old hardware
|
|
#
?
Jul 8, 2018 02:43
|
|
|
anthonypants posted:What command did you run? I didn't, I used the UI. Moot point now, though, since for some reason the drat thing had downloaded some newer kernels than it was actually using, so when I manually removed several, I mistakenly just left the newer ones and now I have a brick. What a truly wonderful operating system.
|
|
#
?
Jul 8, 2018 02:49
|
|
|
I’ve started giving /boot like 2gb on new installs just so I never have to think about this dumbass poo poo. When you’re talking about terabytes of storage, that is nothing. If you haven’t entirely given up, you should be able to straight up rm -rf the old kernel files under /boot to recover from the disk full scenario.
|
|
#
?
Jul 8, 2018 03:28
|
|
|
Or, you know, just don't make a separate /boot partition. There are cases when it's useful, but normally, for the regular linux user ... meh, waste of space, partitions and stuff. EFI partition, sure, you kinda need it. I have:code:It's 1000x more important and helpful to have /home as a separate partition than /boot. gently caress boot, you can repair/replace that anytime.
|
|
#
?
Jul 8, 2018 06:24
|
|
|
hooah posted:I didn't, I used the UI. Moot point now, though, since for some reason the drat thing had downloaded some newer kernels than it was actually using, so when I manually removed several, I mistakenly just left the newer ones and now I have a brick. What a truly wonderful operating system. OK. Don't fret. The stock answer is this: Download a reputable Linux ISO file on a different PC and burn it to a blank DVD (or USB stick). The type you want is called a 'live Linux' ISO file and allows you to try out Linux whilst giving you the option to install once it's booted. Boot the bricked PC with the live Linux DVD/stick and you should be able to access all the stuff that is on the hard drive that is personal to you and you want to keep. Use a spare USB stick to make a temporary backup copy of all your personal poo poo. If you're booting from a USB stick this means you'll need a second USB stick to save all your poo poo on. Then remove the USB stick with all your personal stuff on it and reinstall from the menu system on the live Linux environment. I would choose Fedora: the installer is great, really easy to use and it doesn't keep every drat kernel you ever install. You get a little icon on the desktop of the live environment saying "Install Fedora to hard disk" and everything else it taken care of with the graphical interface. To keep Fedora updated you simply have to remember two commands and type them into the terminal about once a week: 1. sudo dnf check-update 2. sudo dnf update ^you probably don't even need the first command, if you aren't a precious nerd like me. https://getfedora.org/ Fedora Workstation is the one to choose for a regular, everyday PC or laptop. apropos man fucked around with this message at 07:23 on Jul 8, 2018 |
|
#
?
Jul 8, 2018 07:19
|
|
|
You don't really need to update manually with the terminal, Fedora defaults to automatically downloading updates through Gnome Software and it asks if you want to install them on shutdown. That's good enough for everyday use.
|
|
#
?
Jul 8, 2018 07:32
|
|
|
In fact you really should not run updates straight from the terminal like that -- if it for some reason crashes (e.g. Gnome crashes because of something in the update process) things can get hosed. It's very rare, but better safe than sorry. Either run it inside tmux or screen (if you're a nerd), or use the software update tool.
|
|
#
?
Jul 8, 2018 07:56
|
|
|
kujeger posted:In fact you really should not run updates straight from the terminal like that -- if it for some reason crashes (e.g. Gnome crashes because of something in the update process) things can get hosed. It's very rare, but better safe than sorry. In almost 20 years of Fedora it never happened to me. Yes, it is theoretically possible. Yes, there are people out there that had this happened to them. But by "very rare" people do actually mean very rare. You will go through life happily and blissfully without this information.
|
|
#
?
Jul 8, 2018 08:20
|
|
|
hooah posted:I didn't, I used the UI. Moot point now, though, since for some reason the drat thing had downloaded some newer kernels than it was actually using, so when I manually removed several, I mistakenly just left the newer ones and now I have a brick. What a truly wonderful operating system. Did you remove every older kernel that is included in grub? Right after POST you should get a grub menu where you can choose different kernels to try to boot, hopefully some of them are still in your computer. May need pressing Shift at the right moment. This relates to Roargasm's advice to use 'uname -r' to find out which kernel version you are using currently.
|
|
#
?
Jul 8, 2018 09:31
|
|
|
Use the grub command line to pick a kernel and boot, or at least list available kernels. It isn't a brick. It downloaded and installed new kernels than you were using not "for some reason", but so they'd be used when you rebooted.
|
|
#
?
Jul 8, 2018 11:45
|
|
|
Volguus posted:In almost 20 years of Fedora it never happened to me. Yes, it is theoretically possible. Yes, there are people out there that had this happened to them. But by "very rare" people do actually mean very rare. You will go through life happily and blissfully without this information. Agreed. I've only been using Fedora since 24/25 but I exclusively update using dnf (and yum in F24) and never experienced such a crash, either. I could see how the package manager might crash if you're using some very experimental/esoteric DE packages but this dude just wants a Linux desktop, so in my experience my advice still stands. We do run installation scripts at work within GNUscreen sessions for the very reason that it helps protect against network disconnects, so it's not bad advice per se, but we're often running a script through a VPN/SSH combo to a server in Eastern Europe or Africa where you might expect a choppy network disconnect, not some dude sitting in his living room on home broadband.
|
|
#
?
Jul 8, 2018 20:05
|
|
|
My group has been doing monthly kernel updates and reboots on 2700-ish servers for 15 years now over a normal ssh connection and have not lost a single system from a corrupted/failed rpm install due to connection drop. I'd certainly be more careful over a choppy globe crossing network connection but on a robust LAN it's a thing no one should put energy into worrying about. Just don't run the update and reboot in the same command and you'll be fine. If your connection drops, you ssh back in and make sure the package installed. Problem solved.
|
|
#
?
Jul 8, 2018 20:30
|
|
|
xzzy posted:My group has been doing monthly kernel updates and reboots on 2700-ish servers for 15 years now over a normal ssh connection and have not lost a single system from a corrupted/failed rpm install due to connection drop. I'd certainly be more careful over a choppy globe crossing network connection but on a robust LAN it's a thing no one should put energy into worrying about. that's what the && separator is for
|
|
#
?
Jul 8, 2018 20:33
|
|
|
Or nohup and reattaching if you can't be hosed with screen/tmux (or they don't fit into existing scripts) Alternatively, do it with a small ansible playbook
|
|
#
?
Jul 8, 2018 20:46
|
|
|
LVM snapshot before running daily update on the 0.0000000000000001% off-chance that bc.x86_64 suffers corruption. I wonder if hooah got 'unbricked'?
|
|
#
?
Jul 8, 2018 20:57
|
|
|
I love how the definition of bricked gets stretched. back in my day it meant 'this is completely unfixable, you can't even get a light to turn on'
|
|
#
?
Jul 8, 2018 20:58
|
|
|
Need a term for "this is hosed beyond my desire to try and fix it even though I admit it certainly is repairable."
|
|
#
?
Jul 8, 2018 21:02
|
|
|
Yeah. I assume they used the term in a way that suggests noob frustration. I tried to keep my solution simple (running a live CD and making a copy of their poo poo before reinstalling) because it seemed like they were struggling with the idea of removing individual kernels. To point them into using emergency boot modes/chroot'ing and/or updating grub might've just piled on the misery. Plus, it seemed possible that Mint had genuinely filled up their /boot with old kernels and I'd rather that they switched to an OS that wasn't likely to induce such future misery upon them.
|
|
#
?
Jul 8, 2018 21:03
|
|
|
Volguus posted:In almost 20 years of Fedora it never happened to me. Yes, it is theoretically possible. Yes, there are people out there that had this happened to them. But by "very rare" people do actually mean very rare. You will go through life happily and blissfully without this information. apropos man posted:Agreed. I've only been using Fedora since 24/25 but I exclusively update using dnf (and yum in F24) and never experienced such a crash, either. I could see how the package manager might crash if you're using some very experimental/esoteric DE packages but this dude just wants a Linux desktop, so in my experience my advice still stands. xzzy posted:My group has been doing monthly kernel updates and reboots on 2700-ish servers for 15 years now over a normal ssh connection and have not lost a single system from a corrupted/failed rpm install due to connection drop. I'd certainly be more careful over a choppy globe crossing network connection but on a robust LAN it's a thing no one should put energy into worrying about. Eh, I've had it happen twice or so when running it from inside a desktop session and that was enough for me to get into the habit of tmux/screen every time. It's also the official recommendtion but, true, it's not an everyday occurrance. edit: for something a little more than just personal anectode: https://lwn.net/Articles/702629/ kujeger fucked around with this message at 23:21 on Jul 8, 2018 |
|
#
?
Jul 8, 2018 23:17
|
|
|
xzzy posted:Need a term for "this is hosed beyond my desire to try and fix it even though I admit it certainly is repairable." "Works as intended"
|
|
#
?
Jul 9, 2018 05:16
|
|
|
kujeger posted:Eh, I've had it happen twice or so when running it from inside a desktop session and that was enough for me to get into the habit of tmux/screen every time. If we're into the anecdotal, I've updated Fedora on this laptop (Thinkpad) and previous laptop (lovely Toshiba Satellite) every day since Fedora 24 using 'dnf update'. I would give it roughly 300 days a year, missing out days I've been busy or days I've been on holiday. 2016-06-07 was F24 release, so that's just over two years and one month of dnf updates, let's say 630 times. Added to that, I've been running Fedora on my HTPC during the same time but it doesn't get used on a daily basis like my laptop. I'd go with roughly half as many updates. Maybe once every three days, actually. So I've run dnf update about 800 times without a problem. There have been a couple of occasions where a single package was stuck due to a mismatch with the version number in the repository, but that resolved itself on both occasions within a few days when the package/dep versions were adjusted in the repos.
|
|
#
?
Jul 9, 2018 06:29
|
|
|
xzzy posted:Just don't run the update and reboot in the same command and you'll be fine. If your connection drops, you ssh back in and make sure the package installed. Problem solved. Think the only time I’ve ran into something like this was during a yum update that pulled the VMware tool kmod drivers at the same time that caused a panic during initrd generation. Recovery CD + grub update fixed but a weird issue. We just VMware snapshot as a part of the process now to roll back on failure.
|
|
#
?
Jul 9, 2018 12:30
|
|
|
apropos man posted:If we're into the anecdotal, I've updated Fedora on this laptop (Thinkpad) and previous laptop (lovely Toshiba Satellite) every day since Fedora 24 using 'dnf update'. I would give it roughly 300 days a year, missing out days I've been busy or days I've been on holiday. 2016-06-07 was F24 release, so that's just over two years and one month of dnf updates, let's say 630 times. man I even gave a link to point out that it's not just about personal anecdote
|
|
#
?
Jul 9, 2018 12:58
|
|
|
kujeger posted:man I even gave a link to point out that it's not just about personal anecdote You also snidedly pointed out that using screen was for nerds vs using tmux. What was that for?
|
|
#
?
Jul 9, 2018 13:12
|
|
|
apropos man posted:You also snidedly pointed out that using screen was for nerds vs using tmux. What was that for? I was making a joke that both screen AND tmux are for nerds that use the terminal as opposed to "normal" people that use the GUI/Software Center. I'm definitely not trying to be snide or anything like that -- screen and tmux are both excellent tools I use every day. Hell, I've been idling on irc for decades with them. edit: we're arguing about tmux, screen and dnf in a linux thread on an internet forum ityool 2018, we're all nerds kujeger fucked around with this message at 13:43 on Jul 9, 2018 |
|
#
?
Jul 9, 2018 13:33
|
|
|
|
| # ? Jun 10, 2024 15:21 |
|
|
Ah well. I thought you'd brought attitude to the discussion and thought I'd sling some back. I regret going off belligerently. I hear you that the software centre thingy (whatever it's called from like the one time I opened it) is probably the way that the distro is pointing you to upgrade. I just don't see why it should be. I remember first using Linux and thinking "fucks sake, I have to learn how this terminal thing works?" like it was an insurmountable task, or something that I'd never use frequently. As time went on I find myself using the terminal more and more and find it much more gratifying than point and click in most cases. Not all. Once of those cases is where I can see in detail what's been upgraded. I think what I got annoyed was that I thought I'd dispensed some decent enough advice to hooah, who seems to be lost behind a bootloader, still ;-)
|
|
#
?
Jul 9, 2018 14:32
|
|