Re: [CentOS] I do not love thee, kernel-3.10.0-693.2.2.el7.x86_64
On 10/11/2017 04:30 PM, m.r...@5-cent.us wrote: > J Martin Rushton wrote: >> On 11/10/17 19:28, m.r...@5-cent.us wrote: >>> I've been having a lot of issues with video, for example. However, this >>> one... I have a user with a Dell R730. I install kernel and kernel >>> devel, and the rest of the full update, and rebooted. >>> >>> Nope. 100% kernel panic, right around the time it switches root. I even >>> rebuilt the initramfs, nope. >>> >>> And speaking of kernel panics, has *anyone* ever considered that all the >>> data dumped to the console during one results in NOT BEING ABLE TO READ >>> ANYTHING BUT THE LAST 24 or less, mostly less, lines? >>> >>> mark, frustrated, removed that kernel >> >> Ah, the good old days of running a VAXcluster with hardcopy consoles. >> > Smartass. I never had that But, really, what's the point of dumping > many, many lines of data... when it cannot be read? Why not assume that > it's going to happen on a normal terminal, and dump no more than 25 > 80-char lines? So the admin might maybe possibly have a clue as to what > caused it? Surely you do realize there are SEVERAL other display options besides just the video console, right? You can use kdump, you can use a serial console .. you can use google and the search term 'capture kernel oops' to get more than 10 full search page results on how to capture the output of a kernel oops. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /var/run/... being deleted :((
On 10/11/2017 03:42 PM, Alice Wonder wrote: When I need daemon (or other not human user) produced data to persist a reboot, I use /srv - I don't know if that is technically correct or not, but it seems highly unlikely /srv would ever be a candidate for wipe on boot. Perhaps the package in question could simply be patched to use /srv ?? Hmm, not a bad idea actually, although historically with 'Old Unix (TM)' I would probably use /usr or /var/lib (if it's new enough to have /var/lib). Yes, /usr, not /usr/lib or /usr/share; my first Unix system place user home directores right off of /usr (I had my /usr/lowen from my Tandy 6000 Xenxi system on 30 8-inch floppies once; kindof wish I had those again, although enough of them would probably be unreadable so I would lose some segments of the multi-floppy tar; but the readable segments could still be restored, since it was an uncompressed tar.). Today I would say a directory tree right off of /var or /srv wouldn't be inappropriate. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I do not love thee, kernel-3.10.0-693.2.2.el7.x86_64
On Wed, Oct 11, 2017 at 6:30 PM, wrote: > > J Martin Rushton wrote: > > On 11/10/17 19:28, m.r...@5-cent.us wrote: > >> I've been having a lot of issues with video, for example. However, this > >> one... I have a user with a Dell R730. I install kernel and kernel > >> devel, and the rest of the full update, and rebooted. > >> > >> Nope. 100% kernel panic, right around the time it switches root. I even > >> rebuilt the initramfs, nope. > >> > >> And speaking of kernel panics, has *anyone* ever considered that all the > >> data dumped to the console during one results in NOT BEING ABLE TO READ > >> ANYTHING BUT THE LAST 24 or less, mostly less, lines? > >> > >> mark, frustrated, removed that kernel > > > > Ah, the good old days of running a VAXcluster with hardcopy consoles. > > > Smartass. I never had that But, really, what's the point of dumping > many, many lines of data... when it cannot be read? Why not assume that > it's going to happen on a normal terminal, and dump no more than 25 > 80-char lines? So the admin might maybe possibly have a clue as to what > caused it? mark, if you have kdump enabled, you can see the full log in /var/crash (after next boot). -- Marcelo "¿No será acaso que esta vida moderna está teniendo más de moderna que de vida?" (Mafalda) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Flame war police
On 10/11/2017 04:05 PM, Mark Haney wrote: On 10/11/2017 02:44 PM, Lamar Owen wrote: Hi Mark, been a while since I saw you last in Asheville. Hey Lamar, long time no see. ... [snip] Yeah, too long. Come by and visit some time. The core issue in the /var/run thread is one of lack of civility. ... I do agree, to a point. Being Irish, my temper is always simmering, usually over ignorance or willful stupidity. I'm Irish, too, and that's why I have to set the protocol for myself that I do, and many times I'll let a post sit in a compose window half the day before I cancel it (or send it, as the case may be). I've had to perform podondectomies too many times. (surgical removal of foot from mouth.) If you never put the foot in your mouth, you never have to remove it. But, sometimes you just have to be the bad guy when people are recalcitrant. ... Right or wrong, I stand by it. Ok, fair enough. And I wasn't singling you out by any means; since I actually know you personally I figured you wouldn't mind my using your post as the reply point. I get it. I really do. And there were times I probably should have walked away from the entire thread. But, I want people to learn, and learn the right way (regardless of the multitude of 'right ways' in our line of work) and you just have to be very firm with those digging their heels in, if, for instance, they are in a position to do real harm, to data or otherwise. People tend to dig in their heels when they're being dragged a direction they don't want to go But, again, I'm not by any means singling you out. Some people, as I have learned the hard way with my eldest two children, just have to learn things the hard way. I'll share my experience; but in the end some people have to lose data to understand why some things are they way they are. And I might be doing them a favor in the long run by letting them. But maybe I'm just too fatigued these days. I just get tired of dragging anchors and pushing chains. Anyway, hope all is well with you and PARI. I need to get back down there with telescope sometime, the light pollution in RDU is just awful. Thanks; let me know when you come up and I'll show you around at some of things that have changed (like our Redstone rocket engine on display, and the ATS-6 satellite on loan from the Smithsonian). Just don't try to get any information right now from our website; it's down due to a double failure on our ISP's fiber ring; redundancy works great, until you get two trees 50 miles apart that decide to crash down on your fiber within two hours of each other, taking out connectivity in both directions. Give it a few hours. Let's take any more replies off-list, though. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I do not love thee, kernel-3.10.0-693.2.2.el7.x86_64
J Martin Rushton wrote: > On 11/10/17 19:28, m.r...@5-cent.us wrote: >> I've been having a lot of issues with video, for example. However, this >> one... I have a user with a Dell R730. I install kernel and kernel >> devel, and the rest of the full update, and rebooted. >> >> Nope. 100% kernel panic, right around the time it switches root. I even >> rebuilt the initramfs, nope. >> >> And speaking of kernel panics, has *anyone* ever considered that all the >> data dumped to the console during one results in NOT BEING ABLE TO READ >> ANYTHING BUT THE LAST 24 or less, mostly less, lines? >> >> mark, frustrated, removed that kernel > > Ah, the good old days of running a VAXcluster with hardcopy consoles. > Smartass. I never had that But, really, what's the point of dumping many, many lines of data... when it cannot be read? Why not assume that it's going to happen on a normal terminal, and dump no more than 25 80-char lines? So the admin might maybe possibly have a clue as to what caused it? mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] I do not love thee, kernel-3.10.0-693.2.2.el7.x86_64
On 11/10/17 19:28, m.r...@5-cent.us wrote: > I've been having a lot of issues with video, for example. However, this > one... I have a user with a Dell R730. I install kernel and kernel devel, > and the rest of the full update, and rebooted. > > Nope. 100% kernel panic, right around the time it switches root. I even > rebuilt the initramfs, nope. > > And speaking of kernel panics, has *anyone* ever considered that all the > data dumped to the console during one results in NOT BEING ABLE TO READ > ANYTHING BUT THE LAST 24 or less, mostly less, lines? > > mark, frustrated, removed that kernel Ah, the good old days of running a VAXcluster with hardcopy consoles. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Flame war police
On 10/11/2017 02:44 PM, Lamar Owen wrote: On 10/10/2017 11:22 AM, Mark Haney wrote: We have this discussion on every list I've ever been, or currently are on about every 6 months or so. I do my best to contribute to the list as often as I can, but I can't help people when they are deadset on doing dangerous things. Posts like his, and posts like yours make it harder for me to bother trying to help those unwilling to listen. I don't take it from my children, and I certainly won't from adults who won't listen. Hi Mark, been a while since I saw you last in Asheville. Hey Lamar, long time no see. It's been a real long time actually, left ERC in late 2009 after 3 surgeries on my feet and couldn't walk enough to do anything useful (ended up having 2 more, an elbow rebuilt and just had surgery #7 to reconstruct a knee). We moved to Durham in 2013 and have been here since. Just got my last 2 daughters off to Virginia Tech this fall and it's empty nest time. I still don't know what to do with all my free time. The core issue in the /var/run thread is one of lack of civility. There is a civil way of calling someone to see their need for further thought and investigation; calling someone 'stupid' or 'an idiot' over something as small as /var/run directory persistence is, to my mind at least, its own brand of immaturity and will typically cause the person so being attacked to go on the defensive and harden their stance, and this is the textbook genesis of a flame. I do agree, to a point. Being Irish, my temper is always simmering, usually over ignorance or willful stupidity. But, sometimes you just have to be the bad guy when people are recalcitrant. Hence my stance in this thread. I honestly have no problem being the bad guy if I have to be. In this case, it was a situation where OP was already on the defensive after the first posts. My input was much later, and was civil, even if not completely polite. The fact remains trying slam that square peg into that round hole, despite repeated attempts to explain /why not to do it/ seems to me to be willfully stupid (or stubborn). I made my case in my replies that forcing this issue absolutely will result in lost data and few people who get paid to do this for a living will countenance such a thing. In a lot of ways, we view things from the perspective of our own jobs/environment/culture, putting ourselves in their position as it were. A lot of people join the list simply to get a question answered, a lot more hang out and help when they can. I think no one wants to see anyone put their data, or livelihood in jeopardy and certainly not with advice given by (other) professionals. Sometimes you just have to be the 'disappointed parent', and that's how I replied after a while. Right or wrong, I stand by it. I've been involved in Unix and related pursuits long enough to know that different people consider different things to be polite. And I've said my share of impolite things, especially back in the day when I had a Usenet leaf node over uucp and participated in news.admin and alt.flame, so I'm not being self-righteous here, just practical and realistic. I've been plonked before, and I've plonked before. (If anyone isn't familiar with the term 'plonk' it means to put in your killfile or ignore list, and there are a few people that have been on this list that I have killfiled in the past, several especially right around the releases of CentOS 5.6 and CentOS 6.0). Heh. I haven't seen that word in a long time. Plonk and netiquette are widely unused words these days. So, for the last several years, I have set a protocol for myself where, if words that would be considered uncivil by most people were present in my post, or if my wording became too much of an attack over the person, I simply don't send it. My wife and I have five children, so I'm more than a little familiar with a certain rabbit named Thumper and his famous adage "f you can't say something nice, don't say nothin' at all." Now, I don't agree with that adage as written, as I would rather use the word 'civil' instead of 'nice,' because 'civil' doesn't mean nice. Civil just means 'not nasty' even when you need to have 'Radical Candor.' But I reserve that sort of 'harsh civility' for my staff here when necessary, who get a much more civil tone than my children at home would, incidentally. But my staff aren't children. And the members of this list aren't my staff, and I will be civil to everyone on this list. I'll drop a brief note about my opinion of /var/run later, so that anyone who wants to ignore that thread before I post can do so. I get it. I really do. And there were times I probably should have walked away from the entire thread. But, I want people to learn, and learn the right way (regardless of the multitude of 'right ways' in our line of work) and you just have to be very firm with those digging their h
Re: [CentOS] /var/run/... being deleted :((
On 10/11/2017 12:20 PM, Lamar Owen wrote: On 09/21/2017 08:14 AM, hw wrote: what keeps deleting files and directories under /var/run? Having them deleted is extremely annoying because after a reboot, things are suddenly broken because services don´t start. *snip* The fact of the matter is that the EL7 behavior is to store /var/run in a temporary way, and that's not at all likely to be changed in EL7, *snip* When I need daemon (or other not human user) produced data to persist a reboot, I use /srv - I don't know if that is technically correct or not, but it seems highly unlikely /srv would ever be a candidate for wipe on boot. Perhaps the package in question could simply be patched to use /srv ?? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /var/run/... being deleted :((
On 09/21/2017 08:14 AM, hw wrote: what keeps deleting files and directories under /var/run? Having them deleted is extremely annoying because after a reboot, things are suddenly broken because services don´t start. You've received a lot of advice, criticism, and information from this original post, and I'm not going to rehash any of those things. If you're not expecting it,the current CentOS 7 behavior could easily be jarring, to say the least. I empathize with your situation; the release notes are large, dense, and it's easy to miss something that has been changed, like this behavior (or like the need to 'yum downgrade' a packge to get a 'yum update' to complete). However, whether we like it or not, CentOS is a rebuild of the sources for the upstream enterprise Linux. The underlying issue is one of two different package maintainers having differing ideas (as well as two differing interpretations of admittedly ambiguous standards) of what the system should do. If I see two reasonable, competent, system administrators disagreeing about the interpretation of a standard, then the standard is ambiguous. Now, I'm not going to pass judgment on whether it's a bug or a feature, nor am I going to say which I think it is, because what I think or feel about it won't change the reality of the situation; this distribution is way too far down the development curve now -- the time to express those opinions where such expression might have made a difference in the reality of the situtaion was back while the change was being considered for Fedora, and that was a long time ago. The fact of the matter is that the EL7 behavior is to store /var/run in a temporary way, and that's not at all likely to be changed in EL7, regardless of the opinions I have or express about it or what expletives I choose to call it. EL7 includes mechanisms so that files, directories, sockets, named pipes, or whatever that need to look like they persisted across a reboot in /var/run can be recreated at boot as needed, and the packages you use do not yet use that mechanism. If the maintainers of packages that want to run well on CentOS 7 need to have /var/run/$some-file persistence (or pseudo-persistence, which is the current behavior enabled by re-creating said files) then those maintainers will need to change their packages to match actual behavior or file a bug report with upstream to change the behavior. Upstream will probably close with a 'WONTFIX' and the package maintainer will either change packaging or stop supporting CentOS 7. Of course, stranger things have happened, and upstream might relent on the decision. But my gut feel is that upstream will keep the current behavior and the packages will eventually be changed to support it, but I always reserve the right to be wrong. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Flame war police
On 10/10/2017 11:22 AM, Mark Haney wrote: We have this discussion on every list I've ever been, or currently are on about every 6 months or so. I do my best to contribute to the list as often as I can, but I can't help people when they are deadset on doing dangerous things. Posts like his, and posts like yours make it harder for me to bother trying to help those unwilling to listen. I don't take it from my children, and I certainly won't from adults who won't listen. Hi Mark, been a while since I saw you last in Asheville. The core issue in the /var/run thread is one of lack of civility. There is a civil way of calling someone to see their need for further thought and investigation; calling someone 'stupid' or 'an idiot' over something as small as /var/run directory persistence is, to my mind at least, its own brand of immaturity and will typically cause the person so being attacked to go on the defensive and harden their stance, and this is the textbook genesis of a flame. I've been involved in Unix and related pursuits long enough to know that different people consider different things to be polite. And I've said my share of impolite things, especially back in the day when I had a Usenet leaf node over uucp and participated in news.admin and alt.flame, so I'm not being self-righteous here, just practical and realistic. I've been plonked before, and I've plonked before. (If anyone isn't familiar with the term 'plonk' it means to put in your killfile or ignore list, and there are a few people that have been on this list that I have killfiled in the past, several especially right around the releases of CentOS 5.6 and CentOS 6.0). So, for the last several years, I have set a protocol for myself where, if words that would be considered uncivil by most people were present in my post, or if my wording became too much of an attack over the person, I simply don't send it. My wife and I have five children, so I'm more than a little familiar with a certain rabbit named Thumper and his famous adage "f you can't say something nice, don't say nothin' at all." Now, I don't agree with that adage as written, as I would rather use the word 'civil' instead of 'nice,' because 'civil' doesn't mean nice. Civil just means 'not nasty' even when you need to have 'Radical Candor.' But I reserve that sort of 'harsh civility' for my staff here when necessary, who get a much more civil tone than my children at home would, incidentally. But my staff aren't children. And the members of this list aren't my staff, and I will be civil to everyone on this list. I'll drop a brief note about my opinion of /var/run later, so that anyone who wants to ignore that thread before I post can do so. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] I do not love thee, kernel-3.10.0-693.2.2.el7.x86_64
I've been having a lot of issues with video, for example. However, this one... I have a user with a Dell R730. I install kernel and kernel devel, and the rest of the full update, and rebooted. Nope. 100% kernel panic, right around the time it switches root. I even rebuilt the initramfs, nope. And speaking of kernel panics, has *anyone* ever considered that all the data dumped to the console during one results in NOT BEING ABLE TO READ ANYTHING BUT THE LAST 24 or less, mostly less, lines? mark, frustrated, removed that kernel ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /boot partition too small
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. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /boot partition too small
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 -- Microlinux - Solutions informatiques durables 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [External] /boot partition too small
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. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Location of grub.conf etc. with UEFI boot (CentOS 6)
On Oct 11, 2017, at 8:38 AM, Toralf Lund wrote: > What's the proper/normal way of setting up GRUB for a CentOS 6 installation > that boots using UEFI? I've recently set up such a system, but for technical > reasons I mentioned in an earlier post, I booted in "legacy" mode during > installation, which meant I didn't get the correct UEFI boot configuration, > and had to set it up subsequently "by hand". I've managed to get the system > to start up, but I had to place grub.conf under "/EFI/redhat/" on the EFI > partition; without it, the system only boots into the grub shell. Is this > normal, or is GRUB supposed to be able to find grub.conf under /boot? If not, > how are updates on kernel upgrade etc. supposed to get done? Do I need a > symlink from /boot/grub/grub.conf to the EFI parition? And will grub-install > help with some of this? I haven't dared to try it, as I'm afraid it may break > everything because it assumes an "MBR" configuration, or something. > > Also, how is /boot supposed to be set up anyway? Will it still normally be > configured as a separate partition? > > Yeah, I know, I could re-install in UEFI mode (as I think I know how now), > but I'm hoping you will save me from the effort. I also have a workable > system anyhow, but kernel upgrades could be an issue, and it's nice to know > the "right" way of setting up. Yes, UEFI boots with a UEFI grub executable, and it looks for a grub.cfg in the /EFI/redhat/ directory, next to the grub executable. Typically, you have the UEFI partition mounted as /boot/efi, and grub knows to find the grub.cfg in the subdirectory there. The kernel package runs ‘grubby’ which knows how to update grub if there’s an EFI partition mounted. My experiences have been only with CentOS7 and RHEL7 with UEFI, which uses grub2. However, the RHEL6 documentation confirms these paths: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s2-grub-whatis-booting-uefi.html -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Location of grub.conf etc. with UEFI boot (CentOS 6)
Hi, What's the proper/normal way of setting up GRUB for a CentOS 6 installation that boots using UEFI? I've recently set up such a system, but for technical reasons I mentioned in an earlier post, I booted in "legacy" mode during installation, which meant I didn't get the correct UEFI boot configuration, and had to set it up subsequently "by hand". I've managed to get the system to start up, but I had to place grub.conf under "/EFI/redhat/" on the EFI partition; without it, the system only boots into the grub shell. Is this normal, or is GRUB supposed to be able to find grub.conf under /boot? If not, how are updates on kernel upgrade etc. supposed to get done? Do I need a symlink from /boot/grub/grub.conf to the EFI parition? And will grub-install help with some of this? I haven't dared to try it, as I'm afraid it may break everything because it assumes an "MBR" configuration, or something. Also, how is /boot supposed to be set up anyway? Will it still normally be configured as a separate partition? Yeah, I know, I could re-install in UEFI mode (as I think I know how now), but I'm hoping you will save me from the effort. I also have a workable system anyhow, but kernel upgrades could be an issue, and it's nice to know the "right" way of setting up. Thanks, -Toralf ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How can I disable at-spi-bus-launcher
try to start gnome-session-properties and uncheck launching at-spi d-bus launcher at system startup On Wed, Oct 11, 2017 at 9:00 AM, Frank Cox wrote: > I have a laptop that hangs up on shutdown saying that at-spi-bus-launcher > is still running. > > Since I have no use for at-spi-bus-launcher anyway, I would like to get > rid of it, but attempting to remove the at-spi2-core rpm wants to remove > 99% of my desktop as well. > > The only way that I can see to get rid of it is to make > /usr/libexec/at-spi-bus-launcher non-executable, but that's a pretty > horrible hack. > > Can I permanently disable it without resorting to that? > > > -- > MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [External] /boot partition too small
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 -- john r pierce, recycling bits in santa cruz ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [External] /boot partition too small
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_mailman_listinfo_centos&d=DwIGaQ&c=KV_I7O14pmwRcmAVyJ1eg4Jwb8Y2JAxuL5YgMGHpjcQ&r=Q0oqxzgUp3xCCIiJDwS-RbNDndQ-KZDhj8wwveNoqU4&m=nLs0WJ6kZnQCcGRXR2LX8ssZUKMhx-U1cQI8WOrVWGI&s=UK49u-sb55j-VQMkNwZkYYYe1fGSEm_ug0xk9kLfscc&e= ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] How can I disable at-spi-bus-launcher
I have a laptop that hangs up on shutdown saying that at-spi-bus-launcher is still running. Since I have no use for at-spi-bus-launcher anyway, I would like to get rid of it, but attempting to remove the at-spi2-core rpm wants to remove 99% of my desktop as well. The only way that I can see to get rid of it is to make /usr/libexec/at-spi-bus-launcher non-executable, but that's a pretty horrible hack. Can I permanently disable it without resorting to that? -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
