Re: [CentOS] halt versus shutdown
Working with different Linux Distributions makes the life harder. So far I have found out that 'poweroff' & 'reboot' has the same behaviour on Linux/Unix/BSDs. Best Regards, Strahil Nikolov На 15 юни 2020 г. 5:22:28 GMT+03:00, John Pierce написа: >On Sun, Jun 14, 2020 at 6:19 PM Pete Biggs wrote: > >> >> > I'm quite sure that in original Berkeley Unix, as on the VAX >11/780, halt >> > was an immediate halt of the CPU without any process cleanup or >file >> system >> > umounting or anything. Early SunOS (pre-Solaris) was like this, >too. >> > >> The SunOS 4.1.2 man page for halt says >> >>NAME >> halt - stop the processor >>SYNOPSIS >> /usr/etc/halt [ -oqy ] >>DESCRIPTION >> halt writes out any information pending to the disks and then >> stops the processor. >> halt normally logs the system shutdown to the system log >> daemon, syslogd(8), and places a shutdown record in the >> login accounting file Ivar/admlwtmp. >> These actions are inhibited if the -0 or -q options are >present. >> >> The BSD 4.3 (that ran on VAXen) man pages say largely similar things: >> >> >> >https://www.freebsd.org/cgi/man.cgi?query=halt=0=0=4.3BSD+Reno=default=html >> >> >ok, so it does a sync then hard halts, but it doesn't gracefully exit >services, or unmount file systems. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] halt versus shutdown
On Sun, Jun 14, 2020 at 6:19 PM Pete Biggs wrote: > > > I'm quite sure that in original Berkeley Unix, as on the VAX 11/780, halt > > was an immediate halt of the CPU without any process cleanup or file > system > > umounting or anything. Early SunOS (pre-Solaris) was like this, too. > > > The SunOS 4.1.2 man page for halt says > >NAME > halt - stop the processor >SYNOPSIS > /usr/etc/halt [ -oqy ] >DESCRIPTION > halt writes out any information pending to the disks and then > stops the processor. > halt normally logs the system shutdown to the system log > daemon, syslogd(8), and places a shutdown record in the > login accounting file Ivar/admlwtmp. > These actions are inhibited if the -0 or -q options are present. > > The BSD 4.3 (that ran on VAXen) man pages say largely similar things: > > > https://www.freebsd.org/cgi/man.cgi?query=halt=0=0=4.3BSD+Reno=default=html > > ok, so it does a sync then hard halts, but it doesn't gracefully exit services, or unmount file systems. -- -john r pierce recycling used bits in santa cruz ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /etc/networks file
> On Jun 14, 2020, at 19:55, Jay Hart wrote: >> >> I am having some network connectivity issues that manifest itself through >> ping, wget, dnf, >> etc. >> The symptoms are intermittent ability to ping, was wget, or connect to >> repositories. >> >> Where this inquiry is going is: If your internal network is using 192.168.1 >> or 10..50.10, what >> should be in /etc/networks. >> >> My current file contains: >> >> default 0.0.0.0 >> loopback 127.0.0.0 >> link-local 169.254.0.0 >> >> And I'm pretty sure this is the default OS installed contents. >> >> I don't think this is related to my connectivity issue, just curious about >> what this file does. >> >> My old server (which is working just fine) has the same content in its >> /etc/networks file so not >> configuring this does not seem to matter one way or the other. > > > These are CentOS systems, arenât they? CentOS doesnât configure > networking with > /etc/networks. The files they use are in > /etc/sysconfig/network-scripts/ifcfg-*. > Old = C6, new = C8. yes, Centos. I will not worry about this then. Thanks, Jay > > -- > Jonathan Billings > > > ___ > 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] /etc/networks file
On Jun 14, 2020, at 19:55, Jay Hart wrote: > > I am having some network connectivity issues that manifest itself through > ping, wget, dnf, etc. > The symptoms are intermittent ability to ping, was wget, or connect to > repositories. > > Where this inquiry is going is: If your internal network is using 192.168.1 > or 10..50.10, what > should be in /etc/networks. > > My current file contains: > > default 0.0.0.0 > loopback 127.0.0.0 > link-local 169.254.0.0 > > And I'm pretty sure this is the default OS installed contents. > > I don't think this is related to my connectivity issue, just curious about > what this file does. > > My old server (which is working just fine) has the same content in its > /etc/networks file so not > configuring this does not seem to matter one way or the other. These are CentOS systems, aren’t they? CentOS doesn’t configure networking with /etc/networks. The files they use are in /etc/sysconfig/network-scripts/ifcfg-*. -- Jonathan Billings ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Modifying username
This might be of use to somebody. The Readme includes mention of some handy utilities for checking your database files. https://github.com/SpareSimian/user-group-migration ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] halt versus shutdown
> I'm quite sure that in original Berkeley Unix, as on the VAX 11/780, halt > was an immediate halt of the CPU without any process cleanup or file system > umounting or anything. Early SunOS (pre-Solaris) was like this, too. > The SunOS 4.1.2 man page for halt says NAME halt - stop the processor SYNOPSIS /usr/etc/halt [ -oqy ] DESCRIPTION halt writes out any information pending to the disks and then stops the processor. halt normally logs the system shutdown to the system log daemon, syslogd(8), and places a shutdown record in the login accounting file Ivar/admlwtmp. These actions are inhibited if the -0 or -q options are present. The BSD 4.3 (that ran on VAXen) man pages say largely similar things: https://www.freebsd.org/cgi/man.cgi?query=halt=0=0=4.3BSD+Reno=default=html Everything is somewhere on the net :-) P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-virt] very low performance of Xen guests
On 15-06-2020 4:49, Manuel Wolfshant wrote: [...] The testing machines are IBM blades, model H21 and H21XM. Initial tests were performed on the H21 with 16 GB RAM; during the last 6=7 weeks I've been using the H21XM with 64 GB. In all cases the guests were fully updated CentOS 7 -- initially 7.6 ( most recent at the time of the initial tests ), and respectively 7.8 for the tests performed during the last 2 months. As host I used initially CentOS 6 with latest kernel available in the centos virt repo at the time of the tests and CentOS 7 with the latest kernel as well. As xen versions I tested 4.8 and 4.12 ( xl info included below ). The storage for the last tests is a Crucial MX500 but results were similar when using traditional HDD. My problem, in short, is that the guests are extremely slow. For instance , in the most recent tests, a yum install kernel takes cca 1 min on the host and 12-15 (!!!) minutes in the guest, all time being spent in dracut regenerating the initramfs images. I've done rough tests with the storage ( via dd if=/dev/zero of=a_test_file size bs=10M count=1000 ) and the speed was comparable between the hosts and the guests. The version of the kernel in use inside the guest also did not seem to make any difference . OTOH, sysbench ( https://github.com/akopytov/sysbench/ ) as well as p7zip benchmark report for the guests a speed which is between 10% and 50% of the host. Quite obviously, changing the elevator had no influence either. Here is the info which I think that should be relevant for the software versions in use. Feel free to ask for any additional info. [root@t7 ~]# xl info host : t7 release: 4.9.215-36.el7.x86_64 version: #1 SMP Mon Mar 2 11:42:52 UTC 2020 machine: x86_64 nr_cpus: 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz: 3000.122 hw_caps: bfebfbff:000ce3bd:20100800:0001:::: virt_caps : pv hvm total_memory : 57343 free_memory: 53620 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 12 xen_extra : .2.39.g3536f8dc xen_version: 4.12.2.39.g3536f8dc xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit2 xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : xen_commandline: placeholder dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all ucode=-1 cc_compiler: gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) cc_compile_by : mockbuild cc_compile_domain : centos.org cc_compile_date: Tue Apr 14 14:22:04 UTC 2020 build_id : 24148a191438467f26a9e16089205544a428f661 xend_config_format : 4 [root@t5 ~]# xl info host : t5 release: 4.9.215-36.el6.x86_64 version: #1 SMP Mon Mar 2 10:30:40 UTC 2020 machine: x86_64 nr_cpus: 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz: 2000 hw_caps: b7ebfbff:0004e33d:20100800:0001:::: virt_caps : hvm total_memory : 12287 free_memory: 6955 sharing_freed_memory : 0 sharing_used_memory: 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 8 xen_extra : .5.86.g8db85532 xen_version: 4.8.5.86.g8db85532 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : xen_commandline: dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all cc_compiler: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23) cc_compile_by : mockbuild cc_compile_domain : centos.org cc_compile_date: Thu Dec 12 14:34:48 UTC 2019 build_id : da34ae5b90c82137dcbc466cd66322381bc6fd21 xend_config_format : 4 _Note:_ with all other kernels and xen versions that were published for C6 during the last year, the performance was the same, i.e. slow The test VM is exactly the same, copied among servers: [root@t7 ~]# cat /etc/xen/test7_1 builder = "hvm" xen_platform_pci=1 name = "Test7" memory = 2048 maxmem = 4096 vcpus = 2 vif = [ "mac=00:14:5e:d9:df:50,bridge=xenbr0,model=e1000" ] disk = [ "file:/var/lib/xen/images/test7_1,xvda,w" [1] ] sdl = 0 vnc = 1 bootloader =
Re: [CentOS] halt versus shutdown
On Sun, Jun 14, 2020 at 5:20 PM Pete Biggs wrote: > > > fwiw, i've always used 'init 0' to shut down all sorts of unix/linux > > systems. > > In EL7/EL8, init is now a symlink as well because everything is > controlled by systemd. > > > On old school unix, and I think even early Linux, halt was an > > /immediate/ halt, as in catch fire. might as well hit the power switch. > > > Not quite. Shutdown is a timed thing so you can tell it to shutdown or > reboot at a certain time or after a certain delay and it can broadcast > messages to the users - it's useful on multi-user systems to be able to > warn users that the system is about to go down. Halt is an immediate > thing without any broadcast messages or delay but it does do the halt > cleanly. There is an option to halt to not sync the disks - this is > not a wise thing to do and is an emergency option - certainly the > original man pages for halt said something like "only do this if your > disks are on fire". I'm quite sure that in original Berkeley Unix, as on the VAX 11/780, halt was an immediate halt of the CPU without any process cleanup or file system umounting or anything. Early SunOS (pre-Solaris) was like this, too. -- -john r pierce recycling used bits in santa cruz ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] halt versus shutdown
> fwiw, i've always used 'init 0' to shut down all sorts of unix/linux > systems. In EL7/EL8, init is now a symlink as well because everything is controlled by systemd. > On old school unix, and I think even early Linux, halt was an > /immediate/ halt, as in catch fire. might as well hit the power switch. > Not quite. Shutdown is a timed thing so you can tell it to shutdown or reboot at a certain time or after a certain delay and it can broadcast messages to the users - it's useful on multi-user systems to be able to warn users that the system is about to go down. Halt is an immediate thing without any broadcast messages or delay but it does do the halt cleanly. There is an option to halt to not sync the disks - this is not a wise thing to do and is an emergency option - certainly the original man pages for halt said something like "only do this if your disks are on fire". P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] halt versus shutdown
On Mon, 2020-06-15 at 01:32 +0200, Leon Fauster via CentOS wrote: > Working with different OSs can be quite challenging (mentally :-)). > > I wonder why the command "halt" has not same result between EL6 and EL8. > > To shutdown the vm or workstation in EL8 i must use "shutdown now". > > Who mandates this behavior in terms of configuration file? > It's to do with systemd. EL6 used SysV based init and runlevels, EL7 & EL8 use systemd targets. If you look at the halt and shutdown commands they are symlinks to /usr/bin/systemctl now and they are implemented as shims that replicate the effect of the old SysV processes. So the following have the same effect: "systemctl isolate halt.target" "halt" "shutdown -H now" "systemctl halt" there are equivalents for "poweroff" and "reboot" as well. P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] /etc/networks file
I am having some network connectivity issues that manifest itself through ping, wget, dnf, etc. The symptoms are intermittent ability to ping, was wget, or connect to repositories. Where this inquiry is going is: If your internal network is using 192.168.1 or 10..50.10, what should be in /etc/networks. My current file contains: default 0.0.0.0 loopback 127.0.0.0 link-local 169.254.0.0 And I'm pretty sure this is the default OS installed contents. I don't think this is related to my connectivity issue, just curious about what this file does. My old server (which is working just fine) has the same content in its /etc/networks file so not configuring this does not seem to matter one way or the other. If one were using 192.168.1.x network , assume 'default' should be 192.168.1.0. 'Link-local' should match??? Thanks, Jay ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] halt versus shutdown
On Sun, Jun 14, 2020 at 4:32 PM Leon Fauster via CentOS wrote: > Working with different OSs can be quite challenging (mentally :-)). > > I wonder why the command "halt" has not same result between EL6 and EL8. > > To shutdown the vm or workstation in EL8 i must use "shutdown now". > fwiw, i've always used 'init 0' to shut down all sorts of unix/linux systems. On old school unix, and I think even early Linux, halt was an /immediate/ halt, as in catch fire. might as well hit the power switch. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] halt versus shutdown
Working with different OSs can be quite challenging (mentally :-)). I wonder why the command "halt" has not same result between EL6 and EL8. To shutdown the vm or workstation in EL8 i must use "shutdown now". Who mandates this behavior in terms of configuration file? -- Leon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Modifying username
On 6/14/20 4:41 PM, Richard wrote:
Date: Sunday, June 14, 2020 17:26:42 -0400
From: Jay Hart
On 6/14/20 1:39 PM, Jay Hart wrote:
You may need to modify /etc/shadow for consistency.
I don't know what to do here. Need some guidance please.
Run "vipw -s" and make the same change to that file's record for
ABCLast.
In /etc/passwd the directory was shown in plain text. So I just
moved over in the line and changed /home/ABCLast to /home/ALast.
Saved file, and exited.
I don't see a directory name in /etc/shadow using 'vipw -s'
The /etc/shadow file doesn't have the user directory information,
rather the username and the password (and some other bits - man
shadow for the details). With the /etc/passwd and /etc/shadow out of
sync - having different versions of the username - I suspect that the
user can't log in. You should also fix the shadow group file
(gshadow). Look at the man page for vipw for the command for doing
that.
Whenever you are attempting to edit UNIX user related files manually,
keep in mind that information in the following files should be changed
(not necessarily in all, depending on what you change):
/etc/passwd
/etc/shadow
/etc/group
/etc/gshadow
There are also "previous versions" of each of these files which have the
same names appended by hyphen ("minus").
Also, keep in mind that permissions for all of these files matter.
I hope, this helps.
Valeri
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
--
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Modifying username
On Sun, 2020-06-14 at 17:26 -0400, Jay Hart wrote: > > On 6/14/20 1:39 PM, Jay Hart wrote: > > > You may need to modify /etc/shadow for consistency. > > > > > > I don't know what to do here. Need some guidance please. > > > > Run "vipw -s" and make the same change to that file's record for ABCLast. > > > > In /etc/passwd the directory was shown in plain text. So I just moved over > in the line and > changed /home/ABCLast to /home/ALast. Saved file, and exited. > > I don't see a directory name in /etc/shadow using 'vipw -s' > No, there's no directory in /etc/shadow, but the username (the first field) will need to be changed to match with the one in /etc/passwd. Apologies if you know this: /etc/passwd contains account information and is world readable because lots of programs need the information in it, the encrypted password use to be in that file (hence the name) but it too was visible and hence available for cracking; /etc/shadow is not world readable and holds all the "secret" password info; the only thing linking the two databases is the username, hence that has to match in the two files. P. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Modifying username
> > >> Date: Sunday, June 14, 2020 17:26:42 -0400 >> From: Jay Hart >> >>> On 6/14/20 1:39 PM, Jay Hart wrote: You may need to modify /etc/shadow for consistency. I don't know what to do here. Need some guidance please. >>> >>> >>> Run "vipw -s" and make the same change to that file's record for >>> ABCLast. >>> >> >> In /etc/passwd the directory was shown in plain text. So I just >> moved over in the line and changed /home/ABCLast to /home/ALast. >> Saved file, and exited. >> >> I don't see a directory name in /etc/shadow using 'vipw -s' >> > > The /etc/shadow file doesn't have the user directory information, > rather the username and the password (and some other bits - man > shadow for the details). With the /etc/passwd and /etc/shadow out of > sync - having different versions of the username - I suspect that the > user can't log in. You should also fix the shadow group file > (gshadow). Look at the man page for vipw for the command for doing > that. > All files seem to have the correct updated username, and the user can login. Jay > > ___ > 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] Modifying username
> Date: Sunday, June 14, 2020 17:26:42 -0400 > From: Jay Hart > >> On 6/14/20 1:39 PM, Jay Hart wrote: >>> You may need to modify /etc/shadow for consistency. >>> >>> I don't know what to do here. Need some guidance please. >> >> >> Run "vipw -s" and make the same change to that file's record for >> ABCLast. >> > > In /etc/passwd the directory was shown in plain text. So I just > moved over in the line and changed /home/ABCLast to /home/ALast. > Saved file, and exited. > > I don't see a directory name in /etc/shadow using 'vipw -s' > The /etc/shadow file doesn't have the user directory information, rather the username and the password (and some other bits - man shadow for the details). With the /etc/passwd and /etc/shadow out of sync - having different versions of the username - I suspect that the user can't log in. You should also fix the shadow group file (gshadow). Look at the man page for vipw for the command for doing that. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Modifying username
> On 6/14/20 1:39 PM, Jay Hart wrote: >> You may need to modify /etc/shadow for consistency. >> >> I don't know what to do here. Need some guidance please. > > > Run "vipw -s" and make the same change to that file's record for ABCLast. > In /etc/passwd the directory was shown in plain text. So I just moved over in the line and changed /home/ABCLast to /home/ALast. Saved file, and exited. I don't see a directory name in /etc/shadow using 'vipw -s' Jay > ___ > 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] Modifying username
On 6/14/20 1:39 PM, Jay Hart wrote: You may need to modify /etc/shadow for consistency. I don't know what to do here. Need some guidance please. Run "vipw -s" and make the same change to that file's record for ABCLast. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Modifying username
I modified a users name on my system. From ABCLast, to ALast (used as an example). I modified the username, then the group name of the user (to align with the new name), and then I moved the users home directory from /home/ABCLast, to /home/ALast. Then using vipw, edited the home directory to use /home/ALast. When I got finished editing the passwd file, I got the following message: You have modified /etc/passwd. You may need to modify /etc/shadow for consistency. I don't know what to do here. Need some guidance please. lastly, did I miss anything here? Any other steps I need to do to get this user squared away due to the name change? Thanks, Jay ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Updating microcode_ctl froze Centos7
On Sun, 2020-06-14 at 17:39 +0100, Phil Perry wrote: > yum --enablerepo=\* clean all Thanks, that worked ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS-virt] very low performance of Xen guests
Hello For the past months I've been testing upgrading my Xen hosts to CentOS 7 and I face an issue for which I need your help to solve. The testing machines are IBM blades, model H21 and H21XM. Initial tests were performed on the H21 with 16 GB RAM; during the last 6=7 weeks I've been using the H21XM with 64 GB. In all cases the guests were fully updated CentOS 7 -- initially 7.6 ( most recent at the time of the initial tests ), and respectively 7.8 for the tests performed during the last 2 months. As host I used initially CentOS 6 with latest kernel available in the centos virt repo at the time of the tests and CentOS 7 with the latest kernel as well. As xen versions I tested 4.8 and 4.12 ( xl info included below ). The storage for the last tests is a Crucial MX500 but results were similar when using traditional HDD. My problem, in short, is that the guests are extremely slow. For instance , in the most recent tests, a yum install kernel takes cca 1 min on the host and 12-15 (!!!) minutes in the guest, all time being spent in dracut regenerating the initramfs images. I've done rough tests with the storage ( via dd if=/dev/zero of=a_test_file size bs=10M count=1000 ) and the speed was comparable between the hosts and the guests. The version of the kernel in use inside the guest also did not seem to make any difference . OTOH, sysbench ( https://github.com/akopytov/sysbench/ ) as well as p7zip benchmark report for the guests a speed which is between 10% and 50% of the host. Quite obviously, changing the elevator had no influence either. Here is the info which I think that should be relevant for the software versions in use. Feel free to ask for any additional info. [root@t7 ~]# xl info host : t7 release : 4.9.215-36.el7.x86_64 version : #1 SMP Mon Mar 2 11:42:52 UTC 2020 machine : x86_64 nr_cpus : 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz : 3000.122 hw_caps : bfebfbff:000ce3bd:20100800:0001:::: virt_caps : pv hvm total_memory : 57343 free_memory : 53620 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 12 xen_extra : .2.39.g3536f8dc xen_version : 4.12.2.39.g3536f8dc xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit2 xen_pagesize : 4096 platform_params : virt_start=0x8000 xen_changeset : xen_commandline : placeholder dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all ucode=-1 cc_compiler : gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39) cc_compile_by : mockbuild cc_compile_domain : centos.org cc_compile_date : Tue Apr 14 14:22:04 UTC 2020 build_id : 24148a191438467f26a9e16089205544a428f661 xend_config_format : 4 [root@t5 ~]# xl info host : t5 release : 4.9.215-36.el6.x86_64 version : #1 SMP Mon Mar 2 10:30:40 UTC 2020 machine : x86_64 nr_cpus : 8 max_cpu_id : 7 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz : 2000 hw_caps : b7ebfbff:0004e33d:20100800:0001:::: virt_caps : hvm total_memory : 12287 free_memory : 6955 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 8 xen_extra : .5.86.g8db85532 xen_version : 4.8.5.86.g8db85532 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0x8000 xen_changeset : xen_commandline : dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all cc_compiler : gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23) cc_compile_by : mockbuild cc_compile_domain : centos.org cc_compile_date : Thu Dec 12 14:34:48 UTC 2019 build_id : da34ae5b90c82137dcbc466cd66322381bc6fd21 xend_config_format : 4 /Note:/ with all other kernels and xen versions that were published for C6 during the last year, the performance was the same, i.e. slow The test VM is exactly the same, copied among servers: [root@t7 ~]# cat /etc/xen/test7_1 builder = "hvm" xen_platform_pci=1 name = "Test7" memory = 2048 maxmem = 4096 vcpus = 2 vif = [
Re: [CentOS] Updating microcode_ctl froze Centos7
On 14/06/2020 17:09, Robin Lee wrote: On Fri, 2020-06-12 at 09:20 +0200, Robin Lee wrote: Today when I ran yum update two packages came up microcode_ctl and unbound-libs. The updating process went fine until it outputted Running transaction Updating : 2:microcode_ctl-2.1-61.6.el7_8.x86_64 then it just froze. I could no longer ssh to the machine and the console was just blank. I had to shut down it hard. It came back up seemingly fine. But yum update doesn't work anymore. It says "Error importing repomd.xml from base/7/x86_64: Damaged repomd.xml file" I looked at the logs, but journalctl only shows the latest boot on this machine. So I guess I have three questions - Any idea what happened with the update process? - How can I repair repomd.xml? No suggestions about the best way to restore repomd.xml? /Robin Try: yum --enablerepo=\* clean all ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Updating microcode_ctl froze Centos7
On Fri, 2020-06-12 at 09:20 +0200, Robin Lee wrote: > Today when I ran yum update two packages came up microcode_ctl > and unbound-libs. The updating process went fine until it outputted > > Running transaction > Updating : 2:microcode_ctl-2.1-61.6.el7_8.x86_64 > > then it just froze. I could no longer ssh to the machine and the > console was just blank. I had to shut down it hard. It came back up > seemingly fine. But yum update doesn't work anymore. It says "Error > importing repomd.xml from base/7/x86_64: Damaged repomd.xml file" > I looked at the logs, but journalctl only shows the latest boot on > this > machine. > > So I guess I have three questions > - Any idea what happened with the update process? > - How can I repair repomd.xml? No suggestions about the best way to restore repomd.xml? /Robin ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS runs on six cores.
Il 12/06/20 18:59, Gordon Messmer ha scritto: On 6/12/20 2:16 AM, Thomas Stephen Lee wrote: Do we need an upgrade ? Can you restate your question so that it's clear what version you are running, what hardware you are running it on, what you expect to happen, and what is happening instead? Hi, I think that Stephen is referring about the number of developer of the core team that is of 6 members (from this "Do we need an upgrade?"). My first question for Stephen is: why do you think that the core team needs more dev? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
