Discuss

discuss@lists.centos.org

34758 discussions

CentOS 6 (G)parted re-aligning existing partitions?
by Ljubomir Ljubojevic 16 Jan '12

16 Jan '12

I used Hiren Boot CD (Some tool on it) to create 8 partitions for Windows XP and CentOS 6. Now, CentOS6 Disk Utility reports for first partition: "Warning: The partition is misaligned by 512 bytes. This may result in very poor performances. Repartitioning is suggested.", and similar warnings almost all other partitions. Since I already have both Windows (NTFS) and CentOS 6 installed, I was wondering is there any easy way of re-alligning them, maybe via parted? Can someone write short to-the-point howto for repartitioning ext4 partitions (/boot especially)? NTFS partitions I can ghost without a problem and resize them when I returnin it on the HDD. It would be nice to experiment, but I am out of time. I did fdisk -l /dev/sda > file and I can do dd to image file, but how about resizing/repartitioning? I read somewhere that it is good to leave 1MB free before first partition, so it can be aligned? Thanks, -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant

2 1

6.2 install fails on HP 6200pro (Intel Q65X chipset).
by Bryan Hodgson 16 Jan '12

16 Jan '12

CentOS 5.6 x64 installs successfully on HP 6200pro SFF box with Intel Q65X Express chipset (including HD graphics), Core i5 and added NVS300 graphics card. Actually, it works great. HP lists "RedHat Enterprise x64" as a supported OS. The 6200pro is a "business desktop" that became available in early summer 2011. CentOS 6.2 x64 install halts during initial boot, with boot messages stopping at "Detecting hardware". I'm clueless on this one. Suggestions appreciated. Does anyone have CentOS running on this hardware or this chipset? Bryan Hodgson Lehigh University

3 4

Re: [CentOS] VirtIO disk 'leakage' across guests?
by James B. Byrne 16 Jan '12

16 Jan '12

On Mon, January 16, 2012 13:05, James B. Byrne wrote: > How is it even possible for an > application running under a httpd service on one guest to > see anything at all besides the VirtIO storage assigned to > that guest? > > Has anyone else encountered this anomaly? > I just cloned a guest instance. The clone prototype was set up with a single VirtIO disk of 8Gbs, divided into a 500 Mb boot and a ~7.1Gb root partition. The root partition was entirely assigned to the basic vg and two lv were created, one for swap and one for the actual root partition. When the guest was cloned there was only one VirtIO disk of 8 Gb assigned to it and this was cloned and given a new name. When I look at the newly cloned guest instance with pvdisplay this is what I see: # pvdisplay Couldn't find device with uuid umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De. --- Physical volume --- PV Name /dev/vda2 VG Name vg_vm_centos_6 PV Size 7.32 GiB / not usable 3.00 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 1874 Free PE 0 Allocated PE 1874 PV UUID djM23m-6Yeb-BQ2x-gPh9-ORMt-dX2i-Ou9xBQ --- Physical volume --- PV Name unknown device VG Name vg_vm_centos_6 PV Size 31.25 GiB / not usable 3.97 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 7999 Free PE 0 Allocated PE 7999 PV UUID umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De When I look at it using vgdisplay then this is what I see: # vgdisplay Couldn't find device with uuid umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De. --- Volume group --- VG Name vg_vm_centos_6 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 10 VG Access read/write VG Status resizable MAX LV 0 Cur LV 4 Open LV 2 Max PV 0 Cur PV 2 Act PV 1 VG Size 38.57 GiB PE Size 4.00 MiB Total PE 9873 Alloc PE / Size 9873 / 38.57 GiB Free PE / Size 0 / 0 VG UUID qa6jwq-5gTp-6mMH-IWl9-OrEK-HjWc-pbaFsa What is going on and how do I fix this? The size of the ghost pv (31Gb) is showing up as the size of the clone's vg whereas the pv for the cloned instance is only 8Gb. I am only using virt-manager to manage disk storage for these guests and I have no idea why or how this mismash is happening. Any ideas? -- *** E-Mail is NOT a SECURE channel *** James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

2 2

CentOS 6 and glib 2.24
by Grendel 16 Jan '12

16 Jan '12

Hi all, when will be glib 2.24 in CnetOS 6 releases? grendel

3 2

CentOS-announce Digest, Vol 83, Issue 6
by centos-announce-request＠centos.org 16 Jan '12

16 Jan '12

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CEBA-2012:0021 CentOS 5 procinfo Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Mon, 16 Jan 2012 13:44:56 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2012:0021 CentOS 5 procinfo Update To: centos-announce(a)centos.org Message-ID: <20120116134456.GA2489(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2012:0021 Upstream details at : https://rhn.redhat.com/errata/RHBA-2012-0021.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: d0d097e023686ff61086924618037ec38117d77b0022ddc3172ae45f6c514f7e procinfo-18-19.el5_7.2.i386.rpm x86_64: 5173bd1e3c161cba6a9b5958029e4ad4a8b2f80099241cb1272aebe9caf3cb08 procinfo-18-19.el5_7.2.x86_64.rpm Source: 4e49b85b4f804dd35ae31e87d7a6fa294cc1c7e94d925f7a5762e7a3fa6e0934 procinfo-18-19.el5_7.2.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 83, Issue 6 **********************************************

1 0

ia32-libs for 64 bit CentOS
by Elijah Karari 16 Jan '12

16 Jan '12

Hi, I've been trying to install Zimbra Desktop 7 on CentOS 5.5 using the usual perl script provided. The issue is, I get a warning that my system does not have ia32 libs. I dug a bit on google and found out that 'there is no such package as ia32 libs for Centos'. I also tried all the suggested work arounds like glibc & stuff, can anyone shed more light on this? Oh, the zimbra package is a .i686 package. Please help if you can. Regards, EK.

4 7

SELinux and rsh+xauth
by Philippe Naudin 16 Jan '12

16 Jan '12

Hello, I have a strange (for me) problem with these two machines : - Client, a CentOS-5.7 workstation ; - Server, a CentOS-6.2 headless, up-to-date server. From Client, I want to use xauth on Server with the help of rsh (yes, I know, ssh and all this sort of things... another time.) When SELinux is in permissive mode on Server, all these commands perform as expected : rsh Server /usr/bin/xauth info rsh Server /usr/bin/xauth list xauth nextract - Client:0.0 | rsh Server /usr/bin/xauth nmerge - But when SELinux is in enforcing mode on Server, the commands fail with this message : bash: /usr/bin/xauth: Permission denied and /var/log/audit/audit.log shows the following errors : type=SELINUX_ERR msg=audit(1326381080.364:610): security_compute_sid: invalid context system_u:system_r:xauth_t:s0-s0:c0.c1023 for scontext=system_u:system_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xauth_exec_t:s0 tclass=process type=AVC msg=audit(1326381080.364:610): avc: denied { write } for pid=3487 comm="xauth" path="pipe:[21744]" dev=pipefs ino=21744 scontext=system_u:system_r:xauth_t:s0-s0:c0.c1023 tcontext=system_u:system_r:rshd_t:s0-s0:c0.c1023 tclass=fifo_file type=AVC msg=audit(1326381080.369:611): avc: denied { getattr } for pid=3487 comm="xauth" path="socket:[21700]" dev=sockfs ino=21700 scontext=system_u:system_r:xauth_t:s0-s0:c0.c1023 tcontext=system_u:system_r:inetd_t:s0-s0:c0.c1023 tclass=tcp_socket The output from audit2allow is here : $ grep AVC /var/log/audit/audit.log | audit2allow libsepol.context_from_record: invalid security context: "system_u:system_r:xauth_t:s0-s0:c0.c1023" libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:system_r:xauth_t:s0-s0:c0.c1023 to sid (these 4 lines are repeated 2 times) On Server, after creating a new authority file (with rsh again, while Server is in permissive mode), I find : $ ls -Z .Xauthority -rw-------. naudin biom system_u:object_r:xauth_home_t:s0 .Xauthority I don't have this problem on a CentOS-5.7 server with the same configuration. Any idea (other than ssh) on how to solve it ? Thanks, -- Philippe Naudin

2 1

URL pour les logiciels du campus
by Philippe Naudin 16 Jan '12

16 Jan '12

https://www1.montpellier.inra.fr/intranet/intracampus/logiciels/consult/

1 0

with Centos6 i cant Partition on 3TB Disks, problem
by Marko Weber 16 Jan '12

16 Jan '12

Hello List, i try to install Centos 6 on a Server with 2x 3TB Disks. When anaconda is showing up the disk partitioner i cant do more then 3 "normal Partitions" or more then 3 "Raid Partitions". Even when u choose that each partition is 200mb, u cant do more then 3 "normal" or "raid" partitions. is this a bug of anaconda installer? thanks marko

3 2

[CENTOS6] mtrr_cleanup: can not find optimal value - during server startup
by no.spa＠o2.pl 15 Jan '12

15 Jan '12

After fresh installation of CentOS 6.2 on my server, I get following errors in my dmesg output: ------- MTRR default type: uncachable MTRR fixed ranges enabled: 00000-9FFFF write-back A0000-BFFFF uncachable C0000-D7FFF write-protect D8000-E7FFF uncachable E8000-FFFFF write-protect MTRR variable ranges enabled: 0 base 000000000 mask C00000000 write-back 1 base 400000000 mask FC0000000 write-back 2 base 0CB800000 mask FFF800000 uncachable 3 base 0CC000000 mask FFC000000 uncachable 4 base 0D0000000 mask FF0000000 uncachable 5 base 0E0000000 mask FE0000000 uncachable 6 base 42FE00000 mask FFFE00000 uncachable 7 base 430000000 mask FF0000000 uncachable 8 disabled 9 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 original variable MTRRs reg 0, base: 0GB, range: 16GB, type WB reg 1, base: 16GB, range: 1GB, type WB reg 2, base: 3256MB, range: 8MB, type UC reg 3, base: 3264MB, range: 64MB, type UC reg 4, base: 3328MB, range: 256MB, type UC reg 5, base: 3584MB, range: 512MB, type UC reg 6, base: 17150MB, range: 2MB, type UC reg 7, base: 17152MB, range: 256MB, type UC total RAM covered: 16310M gran_size: 64K chunk_size: 64K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 128K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 256K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 512K num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 1M num_reg: 10 lose cover RAM: 126M gran_size: 64K chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 64K chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 64K chunk_size: 8M num_reg: 10 lose cover RAM: -2M gran_size: 64K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 64K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 64K chunk_size: 512M num_reg: 10 lose cover RAM: -256M gran_size: 64K chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 64K chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 128K chunk_size: 128K num_reg: 10 lose cover RAM: 126M gran_size: 128K chunk_size: 256K num_reg: 10 lose cover RAM: 126M gran_size: 128K chunk_size: 512K num_reg: 10 lose cover RAM: 126M gran_size: 128K chunk_size: 1M num_reg: 10 lose cover RAM: 126M gran_size: 128K chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 128K chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 128K chunk_size: 8M num_reg: 10 lose cover RAM: -2M gran_size: 128K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 128K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 128K chunk_size: 512M num_reg: 10 lose cover RAM: -256M gran_size: 128K chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 128K chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 256K chunk_size: 256K num_reg: 10 lose cover RAM: 126M gran_size: 256K chunk_size: 512K num_reg: 10 lose cover RAM: 126M gran_size: 256K chunk_size: 1M num_reg: 10 lose cover RAM: 126M gran_size: 256K chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 256K chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 256K chunk_size: 8M num_reg: 10 lose cover RAM: -2M gran_size: 256K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 256K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 256K chunk_size: 512M num_reg: 10 lose cover RAM: -256M gran_size: 256K chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 256K chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 512K chunk_size: 512K num_reg: 10 lose cover RAM: 126M gran_size: 512K chunk_size: 1M num_reg: 10 lose cover RAM: 126M gran_size: 512K chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 512K chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 512K chunk_size: 8M num_reg: 10 lose cover RAM: -2M gran_size: 512K chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 512K chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 512K chunk_size: 512M num_reg: 10 lose cover RAM: -256M gran_size: 512K chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 512K chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 1M chunk_size: 1M num_reg: 10 lose cover RAM: 126M gran_size: 1M chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 1M chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 1M chunk_size: 8M num_reg: 10 lose cover RAM: -2M gran_size: 1M chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 1M chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 1M chunk_size: 512M num_reg: 10 lose cover RAM: -256M gran_size: 1M chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 1M chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 2M chunk_size: 2M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 2M chunk_size: 4M num_reg: 10 lose cover RAM: -2M *BAD*gran_size: 2M chunk_size: 8M num_reg: 10 lose cover RAM: -2M gran_size: 2M chunk_size: 16M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 32M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 64M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 128M num_reg: 10 lose cover RAM: 0G gran_size: 2M chunk_size: 256M num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 2M chunk_size: 512M num_reg: 10 lose cover RAM: -256M gran_size: 2M chunk_size: 1G num_reg: 10 lose cover RAM: 0G *BAD*gran_size: 2M chunk_size: 2G num_reg: 10 lose cover RAM: -1G gran_size: 4M chunk_size: 4M num_reg: 10 lose cover RAM: 126M *BAD*gran_size: 4M chunk_size: 8M num_reg: 10 lose cover RAM: -2M gran_size: 4M chunk_size: 16M num_reg: 10 lose cover RAM: 2M gran_size: 4M chunk_size: 32M num_reg: 10 lose cover RAM: 2M gran_size: 4M chunk_size: 64M num_reg: 10 lose cover RAM: 2M gran_size: 4M chunk_size: 128M num_reg: 10 lose cover RAM: 2M gran_size: 4M chunk_size: 256M num_reg: 10 lose cover RAM: 2M *BAD*gran_size: 4M chunk_size: 512M num_reg: 10 lose cover RAM: -254M gran_size: 4M chunk_size: 1G num_reg: 10 lose cover RAM: 2M *BAD*gran_size: 4M chunk_size: 2G num_reg: 10 lose cover RAM: -1022M gran_size: 8M chunk_size: 8M num_reg: 10 lose cover RAM: 126M gran_size: 8M chunk_size: 16M num_reg: 10 lose cover RAM: 6M gran_size: 8M chunk_size: 32M num_reg: 10 lose cover RAM: 6M gran_size: 8M chunk_size: 64M num_reg: 10 lose cover RAM: 6M gran_size: 8M chunk_size: 128M num_reg: 10 lose cover RAM: 6M gran_size: 8M chunk_size: 256M num_reg: 10 lose cover RAM: 6M *BAD*gran_size: 8M chunk_size: 512M num_reg: 10 lose cover RAM: -250M gran_size: 8M chunk_size: 1G num_reg: 10 lose cover RAM: 6M *BAD*gran_size: 8M chunk_size: 2G num_reg: 10 lose cover RAM: -1018M gran_size: 16M chunk_size: 16M num_reg: 10 lose cover RAM: 70M gran_size: 16M chunk_size: 32M num_reg: 10 lose cover RAM: 22M gran_size: 16M chunk_size: 64M num_reg: 10 lose cover RAM: 22M gran_size: 16M chunk_size: 128M num_reg: 10 lose cover RAM: 22M gran_size: 16M chunk_size: 256M num_reg: 10 lose cover RAM: 22M *BAD*gran_size: 16M chunk_size: 512M num_reg: 10 lose cover RAM: -234M gran_size: 16M chunk_size: 1G num_reg: 10 lose cover RAM: 22M *BAD*gran_size: 16M chunk_size: 2G num_reg: 10 lose cover RAM: -1002M gran_size: 32M chunk_size: 32M num_reg: 10 lose cover RAM: 54M gran_size: 32M chunk_size: 64M num_reg: 10 lose cover RAM: 54M gran_size: 32M chunk_size: 128M num_reg: 10 lose cover RAM: 54M gran_size: 32M chunk_size: 256M num_reg: 10 lose cover RAM: 54M *BAD*gran_size: 32M chunk_size: 512M num_reg: 10 lose cover RAM: -202M gran_size: 32M chunk_size: 1G num_reg: 10 lose cover RAM: 54M *BAD*gran_size: 32M chunk_size: 2G num_reg: 10 lose cover RAM: -970M gran_size: 64M chunk_size: 64M num_reg: 8 lose cover RAM: 118M gran_size: 64M chunk_size: 128M num_reg: 8 lose cover RAM: 118M gran_size: 64M chunk_size: 256M num_reg: 9 lose cover RAM: 118M gran_size: 64M chunk_size: 512M num_reg: 10 lose cover RAM: 118M gran_size: 64M chunk_size: 1G num_reg: 9 lose cover RAM: 118M gran_size: 64M chunk_size: 2G num_reg: 10 lose cover RAM: 118M gran_size: 128M chunk_size: 128M num_reg: 7 lose cover RAM: 182M gran_size: 128M chunk_size: 256M num_reg: 9 lose cover RAM: 182M gran_size: 128M chunk_size: 512M num_reg: 10 lose cover RAM: 182M gran_size: 128M chunk_size: 1G num_reg: 9 lose cover RAM: 182M gran_size: 128M chunk_size: 2G num_reg: 10 lose cover RAM: 182M gran_size: 256M chunk_size: 256M num_reg: 5 lose cover RAM: 438M gran_size: 256M chunk_size: 512M num_reg: 5 lose cover RAM: 438M gran_size: 256M chunk_size: 1G num_reg: 6 lose cover RAM: 438M gran_size: 256M chunk_size: 2G num_reg: 7 lose cover RAM: 438M gran_size: 512M chunk_size: 512M num_reg: 5 lose cover RAM: 438M gran_size: 512M chunk_size: 1G num_reg: 6 lose cover RAM: 438M gran_size: 512M chunk_size: 2G num_reg: 7 lose cover RAM: 438M gran_size: 1G chunk_size: 1G num_reg: 4 lose cover RAM: 950M gran_size: 1G chunk_size: 2G num_reg: 4 lose cover RAM: 950M gran_size: 2G chunk_size: 2G num_reg: 3 lose cover RAM: 1974M mtrr_cleanup: can not find optimal value please specify mtrr_gran_size/mtrr_chunk_size -------------- use 16 GB ECC Ram on this server, all modules are the same (speed, manufacuer - Kingston, etc). Here are my questions: 1. o you know what disadventages this could make on server installation 2. what should I modify in server configuration to solve this problem?

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss