Discuss

discuss@lists.centos.org

34753 discussions

CentOS, linux and kernel version
by Jayadevan Maymala 20 Dec '13

20 Dec '13

Hi, I am using CentOS 6.4. uname -r gives me 3.9.3-x86_64 Kernel version is 2.6.32. My questions - What is 3.9? In Ubuntu, uname -r and /boot give the same version numbers. Do we have a mapping of CentOS versions, the numbers like 3.9 and kernel versions maintained somewhere? Regards, Jayadevan

5 5

RHEL 7 Beta is now public
by Karanbir Singh 19 Dec '13

19 Dec '13

Hi, http://ftp.redhat.com/redhat/rhel/beta/7/ Go get it ( maybe consider using a mirror ), play with it, test it, and file reports. Dont use it in production. As in the past, we highly encourage people to use the official beta builds from Red Hat and to report issues at http://bugzilla.redhat.com/ Within CentOS, we are going to do a CentOS7Beta1 build to match the release upsteam, and do it in a manner that allows lots of people to get involved and track progress. Keep an eye out on posts on the centos-devel list to see how you can get involved and help with the CentOS Builds and testing process. Regards, -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc

23 54

Re: [CentOS] ZFS on Linux testing
by Chuck Munro 19 Dec '13

19 Dec '13

On 12/19/2013, 04:00 , lists(a)benjamindsmith.com wrote: > BackupPC is a great product, and if I knew of it and/or it was available > when I started, I would likely have used it instead of cutting code. Now > that we've got BackupBuddy working and integrated, we aren't going to be > switching as it has worked wonderfully for a decade with very few issues > and little oversight. > > I would differentiate BackupBuddy in that there is no "incremental" and > "full" distinction. All backups are "full" in the truest sense of the > word, and all backups are stored as native files on the backup server. > This works using rsync's hard-link option to minimize wasted disk space. > This means that the recovery process is just copying the files you need. > Also, graceful recovery for downtime and optimistic disk space usage are > both very nice. (it will try to keep as many backup savepoints as it can > disk space depending) > > I'm evaluating ZFS and will likely include some features of ZFS into > BBuddy as we integrate these capabilities into our backup processes. > We're free to do this in part because we have redundant backup sets, so > a single failure wouldn't be catastrophic in the short/medium term. > > -Ben I would agree that BackupPC is a great tool, stable and well respected, and I have to admit I didn't give it a fair chance before moving on to a simple, crude homebrew solution many years ago. One thing I neglected to mention about using inotify+lsync for a near-real-time secondary file server is that if the primary server croaks, I can quickly switch users to the secondary. When the primary server is repaired, a one-shot rsync to it brings it back to the current state of users' files. This conflicts a bit with non-deletion of old files on the secondary, but it keeps users going while repairs are made. I haven't had to use this trick ... yet. ZFS Raid-z3 and disk hot swap have done their jobs well so far. I'm toying with the idea of keeping a marker file on the secondary whose timestamp can be used to limit rsync back to the primary to only those files which got added while the secondary was being used. That would take care of the non-deleted files issue on the secondary. Fortunately there are no database files involved in any of this. Chuck

1 0

CentOS-announce Digest, Vol 106, Issue 11
by centos-announce-request＠centos.org 19 Dec '13

19 Dec '13

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-2013:C001 CentOS 5 firefox Update (Johnny Hughes) 2. CEBA-2013:1856 CentOS 6 libvirt Update (Johnny Hughes) 3. CEBA-2013:C001 CentOS 6 firefox Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Wed, 18 Dec 2013 14:38:53 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2013:C001 CentOS 5 firefox Update To: centos-announce(a)centos.org Message-ID: <20131218143853.GA10305(a)chakra.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2013:C001 Upstream details at : http://bugs.centos.org/view.php?id=6850 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 69ea2073d271e4b8e9bb4cca244633e1a8402f591693f7463d5f05f38dad7a09 firefox-24.2.0-1.0.1.el5.centos.i386.rpm x86_64: 69ea2073d271e4b8e9bb4cca244633e1a8402f591693f7463d5f05f38dad7a09 firefox-24.2.0-1.0.1.el5.centos.i386.rpm 8752daf842a7211d30f5659c14403ec47efa5cd264464d14d25d04c5c3818681 firefox-24.2.0-1.0.1.el5.centos.x86_64.rpm Source: 0a0c769cc50e5f3c6047d1293f8422c7608cb4e1dd6795852291e9948aa06ad9 firefox-24.2.0-1.0.1.el5.centos.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Wed, 18 Dec 2013 14:06:27 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2013:1856 CentOS 6 libvirt Update To: centos-announce(a)centos.org Message-ID: <20131218140627.GA29400(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2013:1856 Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-1856.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 488920f329f234c27ec7e3865c3aedc5370d3dd5ba37944b6bb545fcfb6fdde1 libvirt-0.10.2-29.el6_5.2.i686.rpm b34e8d2233345736748be1117b847f6719d973d6170b689065c356818554ee3d libvirt-client-0.10.2-29.el6_5.2.i686.rpm fba0f8164f5ffc59eb2805e779db698ec2ee89c4f2e26826bd70aede2a46d490 libvirt-devel-0.10.2-29.el6_5.2.i686.rpm f8eba9f7d04ccfc930cdaae2bc31f70194a9b4ec7778ab7d4e23777026f8fb50 libvirt-python-0.10.2-29.el6_5.2.i686.rpm x86_64: c8e9f2955cb51cc7bd9d37d75cfa0dc846a877a6cf2b33aabf09e02bf96aecee libvirt-0.10.2-29.el6_5.2.x86_64.rpm b34e8d2233345736748be1117b847f6719d973d6170b689065c356818554ee3d libvirt-client-0.10.2-29.el6_5.2.i686.rpm 4ad9395728b924dd6310fbdb1fc80e04cfff0fd2436eef2b22de40817a9d98ec libvirt-client-0.10.2-29.el6_5.2.x86_64.rpm fba0f8164f5ffc59eb2805e779db698ec2ee89c4f2e26826bd70aede2a46d490 libvirt-devel-0.10.2-29.el6_5.2.i686.rpm 94c40bc90d0aa1cce0d3a9f0224ea2b1edd75385799a2196b7f620d32b62d530 libvirt-devel-0.10.2-29.el6_5.2.x86_64.rpm f9075f761f1483c1de29d82eca8ce33e984491e29372e000d1589a9af957c642 libvirt-lock-sanlock-0.10.2-29.el6_5.2.x86_64.rpm 649e578b285facb92e4b993283e7bcbd4b42d80a6cb6e5df6206ec196a8522d8 libvirt-python-0.10.2-29.el6_5.2.x86_64.rpm Source: 852ece733b4bfa2de4c280f96b98e9e136a32f5c9b00a23c23943744ae070c25 libvirt-0.10.2-29.el6_5.2.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Wed, 18 Dec 2013 14:37:50 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2013:C001 CentOS 6 firefox Update To: centos-announce(a)centos.org Message-ID: <20131218143750.GA30535(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2013:C001 Upstream details at : http://bugs.centos.org/view.php?id=6850 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: ba44d1947d4da34a51000063c6c00b7795c8ea58e2ac3b0c8fe90d2eda9b8382 firefox-24.2.0-1.0.1.el6.centos.i686.rpm x86_64: ba44d1947d4da34a51000063c6c00b7795c8ea58e2ac3b0c8fe90d2eda9b8382 firefox-24.2.0-1.0.1.el6.centos.i686.rpm ec62fa4dec4087ab4ed84cb624d0f886ac6f018fb666c1bad98538b455048862 firefox-24.2.0-1.0.1.el6.centos.x86_64.rpm Source: 74868b0e7f866bac66e44ded2394912d6a1e311067c7ec53247a5c8f430534c4 firefox-24.2.0-1.0.1.el6.centos.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 106, Issue 11 ************************************************

1 0

Re: [CentOS] ZFS on Linux testing
by Chuck Munro 19 Dec '13

19 Dec '13

On 12/18/2013, 04:00 , lists(a)benjamindsmith.com wrote: > I may be being presumptuous, and if so, I apologize in advance... > > It sounds to me like you might consider a disk-to-disk backup solution. > I could suggest dirvish, BackupPC, or our own home-rolled rsync-based > solution that works rather well:http://www.effortlessis.com/backupbuddy/ > > Note that with these solutions you get multiple save points that are > deduplicated with hardlinks so you can (usually) keep dozens of save > points in perhaps 2x the disk space of a single copy. Also, because of > this, you can go back a few days / weeks / whatever when somebody > deletes a file. In our case, we make the backed up directories available > via read-only ftp so that end users can recover their files. > > I don't know if dirvish offers this, but backupbuddy also allows you to > run pre and post backup shell scripts, which we use (for example) for > off-site archiving to permanent storage since backup save points expire. > > -Ben Not presumptuous at all! I have not heard of backupbuddy (or dirvish), so I should investigate. Your description makes it sound somewhat like OS-X Time Machine, which I like a lot. I did try backuppc but it got a bit complex to manage IMHO. Thanks for the tip! Chuck

4 6

Why the huge shmmax default setting?
by Lists 18 Dec '13

18 Dec '13

Fresh load of Centos6/64 from new ISO (downloaded 2 weeks ago?) and getting set up with PostgreSQL, one of the typical steps is to increase shmmax from its normal, conservative value (eg: 32 MB or something) to something far more aggressive. But in recent installs of CentOS 6, this value is generally huge, typically larger than the RAM installed on the machine! For example, fresh installs on systems with 32 GB of RAM, this is already set to 68719476736 (64 GB) This large value doesn't really make sense to me - can somebody explain why the change to such a large value? -Ben

3 2

How can I disable PostFix maillog ( /var/log/maillog )
by JEWEL AHMMED 18 Dec '13

18 Dec '13

How can I disable PostFix maillog ( /var/log/maillog ) ?

5 9

CentOS-announce Digest, Vol 106, Issue 10
by centos-announce-request＠centos.org 18 Dec '13

18 Dec '13

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-2013:1848 CentOS 6 pcs Update (Johnny Hughes) 2. CEBA-2013:1845 CentOS 6 yum Update (Johnny Hughes) 3. CESA-2013:1850 Important CentOS 6 openjpeg Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Tue, 17 Dec 2013 13:24:08 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2013:1848 CentOS 6 pcs Update To: centos-announce(a)centos.org Message-ID: <20131217132408.GA5165(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2013:1848 Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-1848.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 8974a573add7ed9ccc28907b4440c129f6c563c008119c0fc921afa74c02b8fd pcs-0.9.90-2.el6.centos.2.noarch.rpm x86_64: 8974a573add7ed9ccc28907b4440c129f6c563c008119c0fc921afa74c02b8fd pcs-0.9.90-2.el6.centos.2.noarch.rpm Source: 9f6a2fa5284420650151fa23a8cf8b589e130cf2f2412f314208204ee825a39b pcs-0.9.90-2.el6.centos.2.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Tue, 17 Dec 2013 13:25:07 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2013:1845 CentOS 6 yum Update To: centos-announce(a)centos.org Message-ID: <20131217132507.GA5401(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2013:1845 Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-1845.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 476bad28a5dced0c6b3b72a70a48403fec460b5f23d4df1ae15540c173e31589 yum-3.2.29-43.el6.centos.noarch.rpm b1458f563272a2383e40c1daf228639c0da11951d126c65ebe469e5e6a753463 yum-cron-3.2.29-43.el6.centos.noarch.rpm x86_64: 476bad28a5dced0c6b3b72a70a48403fec460b5f23d4df1ae15540c173e31589 yum-3.2.29-43.el6.centos.noarch.rpm b1458f563272a2383e40c1daf228639c0da11951d126c65ebe469e5e6a753463 yum-cron-3.2.29-43.el6.centos.noarch.rpm Source: 2d25b4dd627dc061b477bbdb67b35d5eff9505f6f93db40fb7ad41f32546969b yum-3.2.29-43.el6.centos.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Tue, 17 Dec 2013 19:00:24 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CESA-2013:1850 Important CentOS 6 openjpeg Update To: centos-announce(a)centos.org Message-ID: <20131217190024.GA13186(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2013:1850 Important Upstream details at : https://rhn.redhat.com/errata/RHSA-2013-1850.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: bf46dacfe6f46d1ae7ec457f2a093075bc8714425a48f5d064a5252a9e7c558b openjpeg-1.3-10.el6_5.i686.rpm 47449f0180e8fe40a44367ab784a6dd6bed91003a885d077cbe662009f8ee11a openjpeg-devel-1.3-10.el6_5.i686.rpm 4150898842f70f3986a72fbcc77fa93366b20d80296c083266f0c146780aaa8b openjpeg-libs-1.3-10.el6_5.i686.rpm x86_64: 82c082404fb499270130185c9bf3cda3d3ccf6f9ab2c88afaeb3588d960fb7a8 openjpeg-1.3-10.el6_5.x86_64.rpm 47449f0180e8fe40a44367ab784a6dd6bed91003a885d077cbe662009f8ee11a openjpeg-devel-1.3-10.el6_5.i686.rpm 80881bb501c3c94c625f20caef02d9c048c2e52a8cfbf0330a85e13ca5d284b2 openjpeg-devel-1.3-10.el6_5.x86_64.rpm 4150898842f70f3986a72fbcc77fa93366b20d80296c083266f0c146780aaa8b openjpeg-libs-1.3-10.el6_5.i686.rpm 42d3d8454f4518436c9c89c12a60cebbf66aa8870a6f32c5c20bf9924946b74f openjpeg-libs-1.3-10.el6_5.x86_64.rpm Source: 5f2877ff81d6510fbd776d4932e8f97c97aef3a554776b683eac8d9a76e21949 openjpeg-1.3-10.el6_5.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 106, Issue 10 ************************************************

1 0

Re: [CentOS] ZFS on Linux testing
by Chuck Munro 18 Dec '13

18 Dec '13

On 12/14/2013, 04:00 , lists(a)benjamindsmith.com wrote: > We checked lsyncd out and it's most certainly an very interesting tool. > I*will* be using it in the future! > > However, we found that it has some issues scaling up to really big file > stores that we haven't seen (yet) with ZFS. > > For example, the first thing it has to do when it comes online is a > fully rsync of the watched file area. This makes sense; you need to do > this to ensure integrity. But if you have a large file store, EG: many > millions of files and dozens of TB then this first step can take days, > even if the window of downtime is mere minutes due to a restart. Since > we're already at this stage now (and growing rapidly!) we've decided to > keep looking for something more elegant and ZFS appears to be almost an > exact match. We have not tested the stability of lsyncd managing the > many millions of inode write notifications in the meantime, but just > trying to satisfy the write needs for two smaller customers (out of > hundreds) with lsyncd led to crashes and the need to modify kernel > parameters. > > As another example, lsyncd solves a (highly useful!) problem of > replication, which is a distinctly different problem than backups. > Replication is useful, for example as a read-only cache for remote > application access, or for disaster recovery with near-real-time > replication, but it's not a backup. If somebody deletes a file > accidentally, you can't go to the replicated host and expect it to be > there. And unless you are lsyncd'ing to a remote file system with it's > own snapshot capability, there isn't an easy way to version a backup > short of running rsync (again) on the target to create hard links or > something - itself a very slow, intensive process with very large > filesystems. (days) > > I'll still be experimenting with lsyncd further to evaluate its real > usefulness and performance compared to ZFS and report results. As said > before, we'll know much more in another month or two once our next stage > of roll out is complete. > > -Ben Hi Ben, Yes, the initial replication of a large filesystem is *very* time consuming! But it makes sleeping at night much easier. I did have to crank up the inotify kernel parameters by a significant amount. I did the initial replication using rsync directly, rather than asking lsyncd to do it. I notice that if I reboot the primary server, it takes a while for the inotify tables to be rebuilt ... after that it's smooth sailing. If you want to prevent deletion of files from your replicated filesystem (which I do), you can modify the rsync{} array in the lsyncd.lua file by adding the line 'delete = false' to it. This has saved my butt a few times when a user has accidentally deleted a file on the primary server. I agree that filesystem replication isn't really a backup, but for now it's all I have available, but at least the replicated fs is on a separate machine. As a side note for anyone using a file server for hosting OS-X Time Machine backups, the 'delete' parameter in rsync{} must be set to 'true' in order to prevent chaos should a user need to point their Mac at the replicate filesystem (which should be a very rare event). I put all TM backups in a separate ZFS sub-pool for this reason. Chuck

2 1

Virtual Machine converted from physical : Kernel Panic at boot .
by Gregory Machin 18 Dec '13

18 Dec '13

Hi. I used VMware Standalone converter 5.5 to convert a CentOS 5.3 machine from a Physical server to a Virtaul Machine on ESXi 5.1 . Thus far with every attempt to convert this machine I get a "Kernel panic" mount: could not find filesystem '/dev/root' setuproot: moving /dev failed: No such file or directory setuproot: error mounting /proc failed: No such file or directory setuproot: error mounting /sys failed: No such file or directory switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init!-220000 I have follows the VMware provided solution for this situation but the results are the same http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=di… http://blog.edgoad.com/2010/03/vmware-no-volume-groups-found.html I have re-installed the CentOS kernel but that didn't make any difference. I have tried installing disk labels but that didn't make any difference. I have installed a clean install of 5.3 into a new vm , I even did a custom disk configuration to match that created by VMware Converter and that worked fine with most of the configuration being the same with the exception that it used disk labels. I'm at a loss at this point , I'm open to suggestions. Here are my configs as shown when using a rescue disk and chroot into /mnt/sysimage [root@localhost /]# cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00 console=ttyS0,9600n8 console=tty0 # initrd /initrd-version.img #boot=/dev/sda default=0 timeout=5 #splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu # (removed by Converter) title Memtest86+ (1.65) # (removed by Converter) root (hd0,0) # (removed by Converter) kernel /memtest86+-1.65 ro root=/dev/VolGroup00/LogVol00 rhgb quiet title CentOS (2.6.18-128.7.1.el5) root (hd0,0) kernel /vmlinuz-2.6.18-128.7.1.el5 ro root=/dev/sdb1 rhgb quiet # kernel /vmlinuz-2.6.18-128.7.1.el5 ro root=LABEL=/ initrd /initrd-2.6.18-128.7.1.el5.img #title CustomKernel (2.6.18-128.7.1.el5) # root (hd0,0) # kernel /vmlinuz-2.6.18-128.7.1.el5 ro root=/dev/sdb1 rhgb quiet # initrd /initrd-2.6.18-128.7.1.el5.img [root@localhost /]# [root@localhost /]# cat /boot/grub/device.map (hd0) /dev/sda (hd1) /dev/sdb [root@localhost /]# [root@localhost /]# cat /etc/fstab /dev/sdb1 / ext3 defaults,noatime 1 2 #LABEL=/ / ext3 defaults,noatime 1 2 LABEL=/boot /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 [root@localhost /]# [root@localhost /]# fdisk -l /dev/sda Disk /dev/sda: 108 MB, 108134400 bytes 4 heads, 32 sectors/track, 1650 cylinders Units = cylinders of 128 * 512 = 65536 bytes Device Boot Start End Blocks Id System /dev/sda1 * 2 1633 104448 83 Linux [root@localhost /]# fdisk -l /dev/sdb Disk /dev/sdb: 159.9 GB, 159921602560 bytes 143 heads, 28 sectors/track, 78008 cylinders Units = cylinders of 4004 * 512 = 2050048 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 78009 156172288 83 Linux [root@localhost /]# [root@localhost /]# mount /dev/sdb1 on / type ext3 (rw,noatime) /dev/sda1 on /boot type ext3 (rw) devpts on /dev/pts type devpts (rw) tmpfs on /dev/shm type tmpfs (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) [root@localhost /]# Thank you. G

4 4

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