12:08 p.m.
I want to install FC6 on my laptop. When I install I usually do a
complete new install instead of an update. For example when going from
FC4 to FC5, I did a new install. how can I partition my hd so that I
can keep /home and not overwrite it? Do I make it a separate
partition? What is the consensus on the best partition scheme and size?
Ed
12:54 p.m.
linux wrote:
I want to install FC6 on my laptop. When I install I usually do a
complete new install instead of an update. For example when going from
FC4 to FC5, I did a new install. how can I partition my hd so that I
can keep /home and not overwrite it? Do I make it a separate
partition? What is the consensus on the best partition scheme and size?
I like to use just 2 partitions: one for '/', typically 10G or so, and
one for '/home' for the rest of the disk (plus the swap partition of
course). That way you can reinstall without touching /home, though be
sure to backup your /etc directory and/or any emails in /var/spool.
1:01 p.m.
linux wrote:
I want to install FC6 on my laptop. When I install I usually do a
complete new install instead of an update. For example when going from
FC4 to FC5, I did a new install. how can I partition my hd so that I
can keep /home and not overwrite it? Do I make it a separate
partition? What is the consensus on the best partition scheme and size?
There's probably as many partition schemes as there are people to think
of them. There isn't a consensus but some rules of thumb are around. I
will tell you my preferences and you can go from there when others post
theirs.
Desktop/Laptop
==============
/
/boot
/home
Server
======
/
/boot
/home
/usr
/usr/local
/var
/var/spool
And, OC, the swap partition on both.
One thing to remember when doing an "upgrade" by reinstalling is that
you might want to save /etc/* somewhere so you don't have to fight with
configuring everything again.
--
Boring Home Page - http://www.webtrek.com/joe
See my blog, sumo game ranks and other interesting junk
1:17 p.m.
On Wed, 25 Oct 2006, Joe Klemmer wrote:
linux wrote:
> I want to install FC6 on my laptop. When I install I usually do a
> complete new install instead of an update. For example when going from
> FC4 to FC5, I did a new install. how can I partition my hd so that I
> can keep /home and not overwrite it? Do I make it a separate
> partition? What is the consensus on the best partition scheme and size?
There's probably as many partition schemes as there are people to think
of them. There isn't a consensus but some rules of thumb are around. I
will tell you my preferences and you can go from there when others post
theirs.
Desktop/Laptop
==============
/
/boot
/home
Server
======
/
/boot
/home
/usr
/usr/local
/var
/var/spool
And, OC, the swap partition on both.
personally, i lay out my laptop a lot closer to your server
suggestion but, then again, my laptop *is* my primary system. that
said, here are a couple of other thoughts:
1) a separate /tmp to protect the root filesystem from /tmp overflow
has always seemed to me like a good idea.
2) and speaking of /tmp, i'm pondering the idea of moving /tmp under
/var and symlinking /tmp -> /var/tmp. i could have sworn that there
was something in the FHS that suggested that /tmp really belonged
under /var because of its dynamic nature.
3) if i'm feeling bold and daring, i'll mount /usr read-only (as the
FHS suggests it has the right to be). AFAIK, there's nothing in
fedora core that requires /usr to be mounted read-write in normal
operation, and i can always remount briefly when i'm installing or
updating SW.
rday
1:49 p.m.
What is the FHS?
E
Robert P. J. Day wrote:
personally, i lay out my laptop a lot closer to your server
suggestion but, then again, my laptop *is* my primary system. that
said, here are a couple of other thoughts:
1) a separate /tmp to protect the root filesystem from /tmp overflow
has always seemed to me like a good idea.
2) and speaking of /tmp, i'm pondering the idea of moving /tmp under
/var and symlinking /tmp -> /var/tmp. i could have sworn that there
was something in the FHS that suggested that /tmp really belonged
under /var because of its dynamic nature.
3) if i'm feeling bold and daring, i'll mount /usr read-only (as the
FHS suggests it has the right to be). AFAIK, there's nothing in
fedora core that requires /usr to be mounted read-write in normal
operation, and i can always remount briefly when i'm installing or
updating SW.
rday
1:47 p.m.
On Wed, 25 Oct 2006, linux wrote:
What is the FHS?
E
filesystem hierarchy standard: www.pathname.com/fhs
rday
4:22 p.m.
Robert P. J. Day wrote:
1) a separate /tmp to protect the root filesystem from /tmp overflow
has always seemed to me like a good idea.
I can't remember why but there was some reason for not mounting /tmp as
a separate filesystem. It's probably buried along with "sync sync sync".
3) if i'm feeling bold and daring, i'll mount /usr read-only
(as the
FHS suggests it has the right to be). AFAIK, there's nothing in
fedora core that requires /usr to be mounted read-write in normal
operation, and i can always remount briefly when i'm installing or
updating SW.
That is the proper and correct way to have /usr mounted.
--
Boring Home Page - http://www.webtrek.com/joe
See my blog, sumo game ranks and other interesting junk
4:57 p.m.
On Wed, Oct 25, 2006 at 02:17:28PM -0400, Robert P. J. Day wrote:
2) and speaking of /tmp, i'm pondering the idea of moving /tmp
under
/var and symlinking /tmp -> /var/tmp. i could have sworn that there
was something in the FHS that suggested that /tmp really belonged
under /var because of its dynamic nature.
I like /tmp to be fast, and /var/tmp to be large, so I create a large swap
and use tmpfs for /tmp:
/etc/fstab:
/tmp /tmp tmpfs defaults 0 0
- or -
/tmp /tmp tmpfs size=xxxM 0 0
Regards,
Bill Rugolsky
2:15 a.m.
On 10/25/2006 11:57 PM, Bill Rugolsky Jr. wrote:
I like /tmp to be fast, and /var/tmp to be large, so I create a large
swap
and use tmpfs for /tmp:
I have never thought about this. Could you define large. What is
generally needed in a situation where /tmp is tmpfs?
Lars
--
Lars E. Pettersson <lars(a)homer.se>
http://www.sm6rpz.se/
1:13 p.m.
On Thu, Oct 26, 2006 at 09:15:50AM +0200, Lars E. Pettersson wrote:
On 10/25/2006 11:57 PM, Bill Rugolsky Jr. wrote:
>I like /tmp to be fast, and /var/tmp to be large, so I create a large swap
>and use tmpfs for /tmp:
I have never thought about this. Could you define large. What is
generally needed in a situation where /tmp is tmpfs?
It's not a great idea on boxes with little memory, but the typical
new box these days has 512M-1G of RAM or more. I've long been a fan
of loading up Linux boxes with RAM, since Linux makes excellent use of it.
I generally have swap of 1-3 times RAM. tmpfs defaults to using half of
RAM, but I sometimes reduce that to a quarter of RAM. So on a 1GB box,
that's a "mere" 256MB. Which means, for example, that a CD image will
not fit there.
I find that this works well on headless servers, less well on the
desktop, because desktop apps can create large temporary files, that are
not necessarily short-lived, and any space used in tmpfs is competing
with page cache for those bloated desktop apps. It's possible to set
TMPDIR=/var/tmp in your GUI session environment, but that kind of defeats
the purpose, and not every app honors that.
Why use tmpfs?
Traditionally, Linux Ext2 /tmp performance was great due to the
asynchronous meta-data writeback of Ext2, so there was no reason to do
anything fancy. Files could come and go in /tmp, and the typical
effect was to dirty some blocks that got written back every thirty
seconds on average.
Journaling changed this, because Ext3 (and Reiserfs) in the default
data=ordered mode rather eagerly flushes data to disk ahead of meta-data
updates (such as extending the file length of a freshly created file).
The default Ext3 commit interval is five seconds, so if temporary data
persists for a few seconds, a bunch of blocks are flushed to disk:
the allocation bitmap, file data, the file inode, the directory, and
the directory inode. Deleting the file is going to again require
flushing the allocation bitmap, the file inode, and the directory.
This is exacerbated by having atime updates enabled on /tmp.
I first took note of and understood this while using an early release of
Ext3 for Linux 2.2 (which at first only operated in data=journal mode) on
a laptop with a pathetically slow hard disk, but plenty of RAM.
At the time I toyed with the idea of making /tmp an Ext2 filesystem,
and just running a fresh mkfs on each boot.
When Ext3 was ported to Linux 2.4, using tmpfs seemed the natural choice.
As I mentioned, whether putting /tmp in tmpfs actually performs better
depends on hardware and workload; traditional unix tools that dominate
jobs on our servers generally have a small memory footprint (hundreds
of kilobytes) and operate on streams of data that are quickly consumed,
e.g., sorting two files before comm/join/diff. In that case, there is
little point in flushing the data to disk.
On the other hand, Ext3 does block-based journaling (not logical journaling),
which has the virtue of only writing a block once, regardless of how
many times it was modified/reused during the commit interval. So it
is possible that if files in /tmp are very short-lived, the overhead
is not that great, due to reuse.
These days one can use Jens Axboe's "blktrace" and "fio" tools to
get
a good handle on real-world performance.
Regards,
Bill Rugolsky
7:19 a.m.
Bill Rugolsky Jr. wrote:
I like /tmp to be fast, and /var/tmp to be large, so I create a large
swap
and use tmpfs for /tmp:
Lars E. Pettersson replied:
I have never thought about this. Could you define large. What is
generally
needed in a situation where /tmp is tmpfs?
Well, if you were going to allocate 512 MB for /tmp and 1 GB for swap,
then a 1.5 GB swap is certainly large enough...
One obvious thing to note: data in /tmp gets wiped each time you reboot
the machine. I actually find this really helpful -- I find I do create a
number of temporary files which won't need to last beyond a reboot.
The File Hierarchy Standard (which defines Linux directory names and
uses) declares that any Linux program that expects anything to stay in
/tmp from one run to the next is broken.
Basically, it just works.
James.
--
E-mail: james@ | They say that every cloud has a silver lining, which must
aprilcottage.co.uk | be a bit alarming for airline pilots...
| -- "I'm Sorry, I Haven't A Clue", BBC Radio 4
7:47 a.m.
James Wilkinson wrote:
One obvious thing to note: data in /tmp gets wiped each time you
reboot
the machine. I actually find this really helpful -- I find I do create a
number of temporary files which won't need to last beyond a reboot.
This certainly isn't true on my laptop, which I boot daily, eg
[tim@martha ~]$ ls -ls /tmp/gfaq.pdf
344 -rw------- 1 tim tim 344131 Oct 10 12:56 /tmp/gfaq.pdf
Is there some setting for this?
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
8:08 a.m.
James Wilkinson:
> One obvious thing to note: data in /tmp gets wiped each time you
reboot
> the machine. I actually find this really helpful -- I find I do create a
> number of temporary files which won't need to last beyond a reboot.
Timothy Murphy:
This certainly isn't true on my laptop, which I boot daily, eg
[tim@martha ~]$ ls -ls /tmp/gfaq.pdf
344 -rw------- 1 tim tim 344131 Oct 10 12:56 /tmp/gfaq.pdf
Wasn't it James who said he used tmpfs for his /tmp? That's using RAM,
not disk, for /tmp, so theirs would go away on a reboot.
Is there some setting for this?
Ordinarily, /tmp file get cleared by a cron job that checks for files
that haven't been accessed recently. There's a configurable time period
for when something is considered old enough to be deleted.
--
(Currently testing FC5, but still running FC4, if that's important.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
8:44 a.m.
Tim wrote:
James Wilkinson:
>> One obvious thing to note: data in /tmp gets wiped each time you reboot
>> the machine. I actually find this really helpful -- I find I do create a
>> number of temporary files which won't need to last beyond a reboot.
Timothy Murphy:
> This certainly isn't true on my laptop, which I boot daily, eg
>
> [tim@martha ~]$ ls -ls /tmp/gfaq.pdf
> 344 -rw------- 1 tim tim 344131 Oct 10 12:56 /tmp/gfaq.pdf
Wasn't it James who said he used tmpfs for his /tmp? That's using RAM,
not disk, for /tmp, so theirs would go away on a reboot.
OK, I probably mis-understood the posting.
I know that a lot of Unix systems do delete the contents of /tmp
on re-booting, and I was just pointing out that this is not true of Fedora.
> Is there some setting for this?
Ordinarily, /tmp file get cleared by a cron job that checks for files
that haven't been accessed recently. There's a configurable time period
for when something is considered old enough to be deleted.
Yes, I don't have any very old files in /tmp,
so that seems to be working fine for me.
Maybe I should apply it to some other directories, eg Desktop!
Thanks for the enlightenment.
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
11:47 a.m.
New subject: tmpfs and /tmp
Bill Rugolsky Jr. wrote:
I like /tmp to be fast, and /var/tmp to be large, so I create a large
swap
and use tmpfs for /tmp:
Lars E. Pettersson replied:
I have never thought about this. Could you define large. What is
generally
needed in a situation where /tmp is tmpfs?
I commented:
One obvious thing to note: data in /tmp gets wiped each time you
reboot
the machine. I actually find this really helpful -- I find I do create a
number of temporary files which won't need to last beyond a reboot.
Timothy Murphy replied (without quoting Bill and Lars):
This certainly isn't true on my laptop, which I boot daily, eg
[tim@martha ~]$ ls -ls /tmp/gfaq.pdf
344 -rw------- 1 tim tim 344131 Oct 10 12:56 /tmp/gfaq.pdf
Is there some setting for this?
As you can see from the context, Timothy, the setting is using tmpfs for
/tmp. See Bill's post for details.
Maybe I should have changed the subject...
James.
--
E-mail: james@ | "Drums must never stop. Very bad if drums stop."
aprilcottage.co.uk | "Why? What will happen if the drums ever stop?"
| "Bass solo."
10:54 a.m.
On Wed, 2006-10-25 at 17:57 -0400, Bill Rugolsky Jr. wrote:
I like /tmp to be fast, and /var/tmp to be large, so I create a
large
swap and use tmpfs for /tmp:
Bear in mind that if you use some CD/DVD burning software, like the one
built into Nautilus, it creates images for the burns (by default)
inside /tmp. It needs to be big enough to hold them, or you need to
work out how to make them somewhere else.
--
(Currently testing FC5, but still running FC4, if that's important.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
1:18 p.m.
by the way, is there any reason *not* to encourage folks to use LVM
rather than simple primary/extended/logical partitions?
rday
1:25 p.m.
On Wed, 25 Oct 2006, Andy Green wrote:
Robert P. J. Day wrote:
> by the way, is there any reason *not* to encourage folks to use LVM
> rather than simple primary/extended/logical partitions?
If the LVM header area in front of the actual filesystem gets
damaged, it ain't pretty.
well, yes, there's that, but is the extra flexibility that comes with
logical volumes worth the extra (albeit slight) risk? i have folks
ask me my opinion occasionally (yeah, that's frightening), and i
typically suggest that it's worth it to use LVM. but i'm always
willing to listen to dissenting arguments.
rday
1:49 p.m.
Robert P. J. Day wrote:
On Wed, 25 Oct 2006, Andy Green wrote:
> Robert P. J. Day wrote:
>
>> by the way, is there any reason *not* to encourage folks to use LVM
>> rather than simple primary/extended/logical partitions?
> If the LVM header area in front of the actual filesystem gets
> damaged, it ain't pretty.
well, yes, there's that, but is the extra flexibility that comes with
logical volumes worth the extra (albeit slight) risk? i have folks
ask me my opinion occasionally (yeah, that's frightening), and i
typically suggest that it's worth it to use LVM. but i'm always
willing to listen to dissenting arguments.
I also advised folks to use LVM because of the flexibility, and in some
cases (eg, we had some boxes with 12 SATA drive slots that were not
initially fully popuplated but would be filled over time) I'd still say
the same as you propose, especially as they were raided underneath in
this case.
But on a box like this laptop, what does LVM being on by default really
get you? I don't use separate partitions for /home and such, for the
single user laptop situation it's not beneficial. So short of going
nuts and taping a USB drive on top of the laptop and superglueing its
lead in, for me at least LVM only enables the possibility of downsides
while giving nothing good.
I did get an LVM header area damaged a few months ago on another machine
(turned out the HDD was dying) that made it more difficult than it
should have been to recover the filesystem behind it: after that I
stopped being an automatic LVM fan.
On the original question what I normally do is have everything on a
single /. Usually what can fill up /home and /var is typically not done
under root rights, and the default 5% reservation for root only on
ext2/3 means you can then still ssh in as root to fix problems in most
of the circumstances that you were trying to avoid with fixed sized
separate partitions. But none of the choices are inherently dumb and it
depends on the exact usage scenario.
-Andy
2:20 p.m.
On 10/25/06, Andy Green <andy(a)warmcat.com> wrote:
Robert P. J. Day wrote:
> On Wed, 25 Oct 2006, Andy Green wrote:
>
>> Robert P. J. Day wrote:
>>
>>> by the way, is there any reason *not* to encourage folks to use LVM
>>> rather than simple primary/extended/logical partitions?
>> If the LVM header area in front of the actual filesystem gets
>> damaged, it ain't pretty.
>
> well, yes, there's that, but is the extra flexibility that comes with
> logical volumes worth the extra (albeit slight) risk? i have folks
> ask me my opinion occasionally (yeah, that's frightening), and i
> typically suggest that it's worth it to use LVM. but i'm always
> willing to listen to dissenting arguments.
I also advised folks to use LVM because of the flexibility, and in some
cases (eg, we had some boxes with 12 SATA drive slots that were not
initially fully popuplated but would be filled over time) I'd still say
the same as you propose, especially as they were raided underneath in
this case.
But on a box like this laptop, what does LVM being on by default really
get you? I don't use separate partitions for /home and such, for the
single user laptop situation it's not beneficial. So short of going
nuts and taping a USB drive on top of the laptop and superglueing its
lead in, for me at least LVM only enables the possibility of downsides
while giving nothing good.
I did get an LVM header area damaged a few months ago on another machine
(turned out the HDD was dying) that made it more difficult than it
should have been to recover the filesystem behind it: after that I
stopped being an automatic LVM fan.
On the original question what I normally do is have everything on a
single /. Usually what can fill up /home and /var is typically not done
under root rights, and the default 5% reservation for root only on
ext2/3 means you can then still ssh in as root to fix problems in most
of the circumstances that you were trying to avoid with fixed sized
separate partitions. But none of the choices are inherently dumb and it
depends on the exact usage scenario.
-Andy
No one mentioned partition size. If you are planing on installing
multiple operating systems (e.g. dual boot) and doing a "everything
plus the kitchen sink" Fedora install, make sure that you have enough
disk space to hold all the packages, a Fedora DVD iso image or two
(that's 5 GB for two DVD images), and user files. A 20 GB partition
is barely adequate.
5:47 p.m.
Andy Green wrote:
But on a box like this laptop, what does LVM being on by default
really
get you? I don't use separate partitions for /home and such, for the
single user laptop situation it's not beneficial.
That's an extraordinary view.
There are overwhelming arguments for a separate /home partition,
whether using LVM or not.
To start with, it makes the installation
(whether by clean install or upgrade)
of a new version of Fedora far simpler.
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
6:32 p.m.
That's an extraordinary view.
There are overwhelming arguments for a separate /home partition,
whether using LVM or not.
To start with, it makes the installation
(whether by clean install or upgrade)
of a new version of Fedora far simpler.
I tend to agree. Putting everything in one partition is just a bad idea.
For what its worth I favor having a few partitions.
/boot : Small, 100M
/ : System files. Currently FC5. About 10G (usually around 60-70 %
full)
/home : User areas. About 30G .
/other_os : 10 G again
This scheme has worked really well for me, since RH9 was the first install and
through FC1 to FC5. It allows me to keep /home and also to install and try
new OSes cleanly without deleting the main one.
When I upgrade, or just try out a new OS I install that in /other_os. In this
way I can boot either to my main system (FC5) or other_os. /home has has not
been formatted since RH9.
Soon I will try out FC6, by installing it on "/other_os" (although of course
when booted to this system it thinks it is /). Once I'm happy its working OK
and I have everything, I can purge the old "/" partition (the one with FC5 on
it) ready for other things to try, or eventually FC7 :)
cheers Chris
4:11 a.m.
New subject: What is the consensus on the best partition scheme and size?/Keeping home separate
Timothy Murphy wrote:
Andy Green wrote:
> But on a box like this laptop, what does LVM being on by default really
> get you? I don't use separate partitions for /home and such, for the
> single user laptop situation it's not beneficial.
That's an extraordinary view.
There are overwhelming arguments for a separate /home partition,
whether using LVM or not.
To start with, it makes the installation
(whether by clean install or upgrade)
of a new version of Fedora far simpler.
I am not overwhelmed by this "overwhelming argument": I do clean
installs and upgrades just fine with /home in /.
The only thing I miss out on from not having a separate partition for
/home is the hassle of trying to guess how much space I should assign
for it before I know what my usage will look like, and running out of
space pointlessly because of bogus artificial barriers. Or having to
grow (not shrink!) my filesystem with LVM and ext2 tools because I
guessed the proportions wrong.
Like I said in some usage cases it makes sense. On my laptop it makes
no sense to me so I don't do it. But of course if it makes you happier
to have a separate /home then by all means continue to use it.
-Andy
1:51 p.m.
New subject: in-place clean installs (was Re: What is the consensus on the best partition scheme)
Andy Green <andy(a)warmcat.com> writes:
I am not overwhelmed by this "overwhelming argument": I do
clean
installs and upgrades just fine with /home in /.
Please do tell us how you do this.
I have an FC5 system with 4 200G disks and 2 logical volumes spread
over all 4 of them. I need to figure out how to just nuke the fc5
bits while retaining the second volume group.
I was going to try to boot the install dvd, mount the volume 00 (say
on /mnt), mkdir /mnt/fc5 ; mv /mnt/* /mnt/fc5
Is this what you do? Is there a better way? Backing up ~800GB of
data is going to take one heck of a big pile of DVD's.
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
11:37 p.m.
New subject: in-place clean installs with one / partition
Wolfgang S. Rupprecht wrote:
Andy Green <andy(a)warmcat.com> writes:
> I am not overwhelmed by this "overwhelming argument": I
do clean
> installs and upgrades just fine with /home in /.
Please do tell us how you do this.
The last time I needed to actually get distribution media packages on to
a box was when I took that box off Development a couple of years ago.
Neither an upgrade install nor a "install" (which I was thinking of as a
"clean install", actually, but it doesn't matter) over that filesystem
did anything useful, because anaconda/rpm saw that to its mind "later"
packages were already in there and did not update them, despite it was
asked to perform an "install".
What I did then was to boot in linux rescue from the install media,
mount the / filesystem and
rm -rf /usr/* /var/* ...
then I umounted the / filesystem and did the "install" (sans format!),
which worked fine and my box was off the at that time extremely shaky
Development stuff.
I have an FC5 system with 4 200G disks and 2 logical volumes spread
over all 4 of them. I need to figure out how to just nuke the fc5
bits while retaining the second volume group.
Why must the FC5 bits get nuked? I didn't get what the driving force
for the effort is.
I was going to try to boot the install dvd, mount the volume 00 (say
on /mnt), mkdir /mnt/fc5 ; mv /mnt/* /mnt/fc5
Is this what you do? Is there a better way? Backing up ~800GB of
data is going to take one heck of a big pile of DVD's.
Well without a backup your data is in a fragile way anyway. A good way
if faced with something tricky is to buy a new, bigger HDD, so the old
implementation becomes the backup and the data is migrated to the new
HDD. You can get a 750GB HDD nowadays that replaces your four drives in
one: unless your drives were raided your reliability actually goes up.
-Andy
1:09 a.m.
New subject: in-place clean installs with one / partition
Andy Green <andy(a)warmcat.com> writes:
The last time I needed to actually get distribution media packages
on
to a box was when I took that box off Development a couple of years
ago. Neither an upgrade install nor a "install" (which I was thinking
of as a "clean install", actually, but it doesn't matter) over that
filesystem did anything useful, because anaconda/rpm saw that to its
mind "later" packages were already in there and did not update them,
despite it was asked to perform an "install".
I did try an upgrade install, but a damaged yum/rpm database file
really confused the upgrade logic. That left me with a half fc5 half
fc6 system that had non-working xterms. I didn't really expect it to
work, I was just curious what would happen.
After that, I did poke at the fs a bit from the rescue mode on the
install dvd, and then it hit me I really only had vg00 on the first
disk and the other vg spaning the other 3 disks. I could safely do a
clean install on the first disk leaving the other 3 disks untouched.
Why must the FC5 bits get nuked? I didn't get what the driving
force
for the effort is.
A few months ago I did a "yum -y update ; shutdown -r now". I don't
know if the yum database needs a few 10's of seconds to get flushed
cleanly, or what, but it got royally scrambled. A "yum list" after
the reboot showed that the set of *.db files was corrupted. I could
rebuild some of it from the yum cache directory, but roughly 1/3 of
the rpm headers (~400) were no longer in the cache. Nuking all of fc5
would be a good way to make sure that everything in the filesystem is
accounted for with no stragglers.
Well without a backup your data is in a fragile way anyway. A good
way if faced with something tricky is to buy a new, bigger HDD, so the
old implementation becomes the backup and the data is migrated to the
new HDD. You can get a 750GB HDD nowadays that replaces your four
drives in one: unless your drives were raided your reliability
actually goes up.
Agreed. Its a combination of machine generated data and crap loaded
from the net, so losing it wouldn't be the end of the world. In the
past I've always bought a newer bigger disk whenever I installed a new
OS. I also used to unplug the old disks just to prevent mishaps
during the install.
I'm still waiting for price parity before I pick up one of the 750GB
ones. They still want $100 too much vs. buying 3 of the same series
drives populated with 250GB worth of heads and platters.
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
4:49 a.m.
New subject: in-place clean installs with one / partition
Wolfgang S. Rupprecht wrote:
A few months ago I did a "yum -y update ; shutdown -r now".
I don't
know if the yum database needs a few 10's of seconds to get flushed
cleanly, or what, but it got royally scrambled. A "yum list" after
the reboot showed that the set of *.db files was corrupted. I could
rebuild some of it from the yum cache directory, but roughly 1/3 of
the rpm headers (~400) were no longer in the cache. Nuking all of fc5
would be a good way to make sure that everything in the filesystem is
accounted for with no stragglers.
Yum does have some kind of database down /var/cache/yum/, but it is just
holding what it last heard was available from the repos AIUI and can
very safely be nuked with yum clean all and re-running yum.
RPM (yum uses the rpm libs to do the actual install/upgrade/erase) on
the other hand holds a database of everything that is installed on the
box, this one is down /var/lib/rpm. RPM has a longstanding bug where
some kind of internal db4 database cache files, /var/lib/rpm/__db*, can
get left in an inconsistent state, until these are deleted rpm then
hangs or chokes. I don't know if that was the problem but with any
funny behaviour from rpm that is the first port of call.
A nice shutdown like you did syncs stuff to disc and umounts your drives
cleanly before restarting, being the textbook thing to do it should not
have made any trouble.
I guess if it was my box I would muse about how important the data in
the LVMs was to me, and take steps to back it up if it was that
important. Then I would use the rescue mode method to destroy /usr,
/etc and /var at least and do an "install" of FC6 (without formatting,
and taking care to list your LVMs in the fdisk part of anaconda). I
think that will work fine, but then my most deodorant-challenging
adventures usually start that way.
past I've always bought a newer bigger disk whenever I installed
a new
OS. I also used to unplug the old disks just to prevent mishaps
during the install.
Yes, it's a very cautious and satisfying way, especially if you find
yourself installing Linux for an eager yet fretful Windows convert.
Knowing they can go back makes it easier, nobody has gone back to their
old drive yet though ;-) But it allows for the fact that given a random
machine from a random year with a random chipset and random video, one
is never quite sure how much of it Linux will be able to bring up (I
take a pile of outdated but supported video cards with me), given random
BIOS versions, no Internet access until the box is working again, etc.
Usually it is everything important, but if you are visiting and only
have limited time at least you can know for certain you can back out
100% to the old drive with 1 minute's notice. If your life isn't
exciting enough trying to grapple someone else's old machine into a good
Linux shape with limited time will change that!
I'm still waiting for price parity before I pick up one of the
750GB
ones. They still want $100 too much vs. buying 3 of the same series
drives populated with 250GB worth of heads and platters.
ACK - 750GB are not at the $/MB sweetspot where one should buy.
-Andy
2:37 p.m.
New subject: in-place clean installs with one / partition
On Fri, 2006-10-27 at 10:49 +0100, Andy Green wrote:
Wolfgang S. Rupprecht wrote:
> A few months ago I did a "yum -y update ; shutdown -r now". I don't
> know if the yum database needs a few 10's of seconds to get flushed
> cleanly, or what, but it got royally scrambled. A "yum list" after
> the reboot showed that the set of *.db files was corrupted. I could
> rebuild some of it from the yum cache directory, but roughly 1/3 of
> the rpm headers (~400) were no longer in the cache. Nuking all of fc5
> would be a good way to make sure that everything in the filesystem is
> accounted for with no stragglers.
Yum does have some kind of database down /var/cache/yum/, but it is just
holding what it last heard was available from the repos AIUI and can
very safely be nuked with yum clean all and re-running yum.
RPM (yum uses the rpm libs to do the actual install/upgrade/erase) on
the other hand holds a database of everything that is installed on the
box, this one is down /var/lib/rpm. RPM has a longstanding bug where
some kind of internal db4 database cache files, /var/lib/rpm/__db*, can
get left in an inconsistent state, until these are deleted rpm then
hangs or chokes. I don't know if that was the problem but with any
funny behaviour from rpm that is the first port of call.
A nice shutdown like you did syncs stuff to disc and umounts your drives
cleanly before restarting, being the textbook thing to do it should not
have made any trouble.
I guess if it was my box I would muse about how important the data in
the LVMs was to me, and take steps to back it up if it was that
important. Then I would use the rescue mode method to destroy /usr,
/etc and /var at least and do an "install" of FC6 (without formatting,
and taking care to list your LVMs in the fdisk part of anaconda). I
think that will work fine, but then my most deodorant-challenging
adventures usually start that way.
This is a dangerous way to go.
A clean install using the same partitions, but doing a format as part of
the install process does the same as you have been saying, except it
totally blows away everything on the partition instead of leaving some
possibly inconsistent parts as you are doing.
I personally recommend a clean install since with an upgrade it is
possible for some lingering bits of FC5 to be left hanging that can
later cause nightmares.
> past I've always bought a newer bigger disk whenever I
installed a new
> OS. I also used to unplug the old disks just to prevent mishaps
> during the install.
Yes, it's a very cautious and satisfying way, especially if you find
yourself installing Linux for an eager yet fretful Windows convert.
Knowing they can go back makes it easier, nobody has gone back to their
old drive yet though ;-) But it allows for the fact that given a random
machine from a random year with a random chipset and random video, one
is never quite sure how much of it Linux will be able to bring up (I
take a pile of outdated but supported video cards with me), given random
BIOS versions, no Internet access until the box is working again, etc.
Usually it is everything important, but if you are visiting and only
have limited time at least you can know for certain you can back out
100% to the old drive with 1 minute's notice. If your life isn't
exciting enough trying to grapple someone else's old machine into a good
Linux shape with limited time will change that!
> I'm still waiting for price parity before I pick up one of the 750GB
> ones. They still want $100 too much vs. buying 3 of the same series
> drives populated with 250GB worth of heads and platters.
ACK - 750GB are not at the $/MB sweetspot where one should buy.
-Andy
4:02 a.m.
New subject: in-place clean installs with one / partition
Jeff Vian wrote:
> I guess if it was my box I would muse about how important the
data in
> the LVMs was to me, and take steps to back it up if it was that
> important. Then I would use the rescue mode method to destroy /usr,
> /etc and /var at least and do an "install" of FC6 (without formatting,
> and taking care to list your LVMs in the fdisk part of anaconda). I
> think that will work fine, but then my most deodorant-challenging
> adventures usually start that way.
This is a dangerous way to go.
A clean install using the same partitions, but doing a format as part of
the install process does the same as you have been saying, except it
totally blows away everything on the partition instead of leaving some
possibly inconsistent parts as you are doing.
Well, /usr is gone, /var and /etc... there are a limited number of
places for "possibly inconsistent parts" to be hiding out. At some
point as that rm -rf line grows longer, the hideouts reach zero, if you
allow that /home is allowed to remain as-was. So I don't see why it is
so "dangerous" other than you need to know what you are doing enough to
run the rescue mode.
Even the "danger" of hacking out large parts of the install must be
balanced against the "danger" of telling newbies to use a separate /home
with LVM, and then guiding them through the potential
filesystem-trashing complexity of changing partition and LVM sizes and
growing the filesystem, all because the ran out of space due to the
artificial limit of their unnecessary partitioning.
For me normally simple upgrade installs have been fine on a normal
system, or needed minimal fixing up afterwards, and I have not needed
really clean installs at all with the exception of the case of trying to
get off Development.
-Andy
9:24 p.m.
New subject: What is the consensus on the best partition scheme and size?/Keeping home separate
Andy Green wrote:
I am not overwhelmed by this "overwhelming argument": I do
clean
installs and upgrades just fine with /home in /.
How?
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
6:48 a.m.
New subject: What is the consensus on the best partition scheme and size?/Keeping home separate
I am not overwhelmed by this "overwhelming argument": I do
clean
installs and upgrades just fine with /home in /.
Please tell me how you do a clean install into / (i.e. reformat) without
losing /home when /home is in / ? As far as I know this is impossible, but I
might be wrong ...
Chris
7:37 a.m.
New subject: What is the consensus on the best partition scheme and size?/Keeping home separate
On Sat, 2006-10-28 at 12:48 +0100, Chris Jones wrote:
Please tell me how you do a clean install into / (i.e. reformat)
without losing /home when /home is in / ?
They didn't...
They didn't "format" the drive, but they did remove the files before the
installation. That gives you a "clean install".
--
(Currently running FC4, in case that's important to the thread)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
2 p.m.
New subject: What is the consensus on the best partition scheme and size?/Keeping home separate
On Sat, 2006-10-28 at 22:07 +0930, Tim wrote:
On Sat, 2006-10-28 at 12:48 +0100, Chris Jones wrote:
> Please tell me how you do a clean install into / (i.e. reformat)
> without losing /home when /home is in / ?
They didn't...
They didn't "format" the drive, but they did remove the files before the
installation. That gives you a "clean install".
That seems like it would be (almost) the same as a clean install.
However, it is still much harder than having /home on a separate
partition and then just letting the installer format the entire /
filesystem (along with whatever other partitions you are using for the
OS).
Doing it that way means you have to do an rm -rf /<directory> for each
directory that you want to nuke, and having to also remove any files
in / itself... All the while making sure you do not remove /home.
Is there more than one way to skin that cat? Sure.
Some are simple and others are needlessly complex.
This problem is the reason a _lot_ of us have repeatedly recommended
that /home be on its own partition.
--
(Currently running FC4, in case that's important to the thread)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
1:53 a.m.
New subject: What is the consensus on the best partition scheme and size?/Keeping home separate
Tim:
> They didn't "format" the drive, but they did remove
the files before the
> installation. That gives you a "clean install".
Jeff Vian:
That seems like it would be (almost) the same as a clean install.
However, it is still much harder than having /home on a separate
partition and then just letting the installer format the entire /
filesystem (along with whatever other partitions you are using for the
OS).
I don't disagree. I'd rather use partitions, myself. But if one were
faced with updating/re-installing a system without partitions, and
without the ability to backup data (another bad position to be in),
that'd be a way to go about doing it.
--
(Currently testing FC5, but still running FC4, if that's important.)
Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.
6:20 a.m.
New subject: What is the consensus on the best partition scheme and size?/Keeping home separate
That seems like it would be (almost) the same as a clean install.
However, it is still much harder than having /home on a separate
partition and then just letting the installer format the entire /
filesystem (along with whatever other partitions you are using for the
OS).
Doing it that way means you have to do an rm -rf /<directory> for each
directory that you want to nuke, and having to also remove any files
in / itself... All the while making sure you do not remove /home.
Is there more than one way to skin that cat? Sure.
Some are simple and others are needlessly complex.
Also, to do things this (tedious) way, you need some other OS to boot from in
order to mount / whilst you wipe from it the things you want to...
Its so much easier to just stick /home on a seperate partition, I really don't
understand those who recommend this way, but each to their own I guess...
Chris
10:36 a.m.
Also, to do things this (tedious) way, you need some other OS to boot from
in
order to mount / whilst you wipe from it the things you want to...
Enters the rescue disk. Pop your install dvd in the drive and start with
"linux rescue". Not that complicated, and you win a lot knowing how to work
in rescue mode.
3:25 a.m.
New subject: What is the consensus on the best partition scheme and size?/Keeping home separate
Chris Jones wrote:
> Is there more than one way to skin that cat? Sure.
> Some are simple and others are needlessly complex.
Right.
Also, to do things this (tedious) way, you need some other OS to boot
from in
order to mount / whilst you wipe from it the things you want to...
Booting off the original install media in Fedora, with "linux rescue",
will allow you to do this without "some other OS", so that's not an issue.
Its so much easier to just stick /home on a seperate partition, I
really don't
understand those who recommend this way, but each to their own I guess...
Not having a separate /home partition has the advantage that on a single
storage device, the allocation of storage is automatically optimal
between any directories that need it. Need to store big video files in
/home all of a sudden? All you have to worry about is if you have
enough global disc space. Dealing with changing partition and
filesystem sizes because you guessed wrong what size you needed for what
directory is in no way "much easier" than just saving the file. But as
you say, each to their own.
-Andy
3:42 a.m.
On 30/10/06, Andy Green <andy(a)warmcat.com> wrote:
Not having a separate /home partition has the advantage that on a
single
storage device, the allocation of storage is automatically optimal
between any directories that need it. Need to store big video files in
/home all of a sudden? All you have to worry about is if you have
enough global disc space. Dealing with changing partition and
filesystem sizes because you guessed wrong what size you needed for what
directory is in no way "much easier" than just saving the file. But as
you say, each to their own.
-Andy
Actually, inside /home/user I have /home/user/videos which is it's own
partition, that I use to store large files such as videos. This does
take some planning on the part of the user, however.
Dotan Cohen
http://what-is-what.com/what_is/xhtml.html
http://gmail-com.com/
7:03 a.m.
I use /usr/local as a separate partition which is where my user account is also
located. I like the idea of not losing my old local execurables when I install
OS's. Selinux is not very happy about it, though...
HTH.
Trotter
--- Dotan Cohen <dotancohen(a)gmail.com> wrote:
On 30/10/06, Andy Green <andy(a)warmcat.com> wrote:
> Not having a separate /home partition has the advantage that on a single
> storage device, the allocation of storage is automatically optimal
> between any directories that need it. Need to store big video files in
> /home all of a sudden? All you have to worry about is if you have
> enough global disc space. Dealing with changing partition and
> filesystem sizes because you guessed wrong what size you needed for what
> directory is in no way "much easier" than just saving the file. But as
> you say, each to their own.
>
> -Andy
Actually, inside /home/user I have /home/user/videos which is it's own
partition, that I use to store large files such as videos. This does
take some planning on the part of the user, however.
Dotan Cohen
http://what-is-what.com/what_is/xhtml.html
http://gmail-com.com/
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
____________________________________________________________________________________
We have the perfect Group for you. Check out the handy changes to Yahoo! Groups
(http://groups.yahoo.com)
4:06 p.m.
On 30/10/06, Globe Trotter <itsme_410(a)yahoo.com> wrote:
I use /usr/local as a separate partition which is where my user
account is also
located. I like the idea of not losing my old local execurables when I install
OS's. Selinux is not very happy about it, though...
Why is your user account not under /home?
Dotan Cohen
http://lyricslist.com/
http://what-is-what.com/what_is/love.html
2:29 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andy Green wrote:
But on a box like this laptop, what does LVM being on by default really
get you? I don't use separate partitions for /home and such, for the
single user laptop situation it's not beneficial. So short of going
nuts and taping a USB drive on top of the laptop and superglueing its
lead in, for me at least LVM only enables the possibility of downsides
while giving nothing good.
I will agree to disagree here. I am in a single user laptop situation
and I _always_ have a separate /home partition. As I upgrade my system I
never worry about losing my personal files etc.
The benefit is obvious compared to the small hassle of having to fix
some minor tidbits like symlinks and similar.
The benefits of LVM are not that obvious, I will agree there but a
sensible partition scheme is a must for me as I am not willing to
reinvent the wheel with my home-brew scripts that all reside in ~/bin
my email etc.
my $.02
Thierry
- --
(o< Thierry Sayegh de Bellis, RHCE
//\ http://glossolalie.com
V_/_ Fingerprint: F565 3D05 A01F 9948 E4F4 32EA 2C2D 7CB6 6D57 1FD6
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFFQGPuLC18tm1XH9YRArwfAJ9nt4AlPgBtWP/Vx51TyKTa3z7GSACfejJD
SIWjquO7QW0lSu3OX1fovHM=
=vuUK
-----END PGP SIGNATURE-----
7:23 p.m.
Robert P. J. Day wrote:
by the way, is there any reason *not* to encourage folks to use
LVM
rather than simple primary/extended/logical partitions?
Whenever I try to use LVM the install program always complains about
not having any drives to install to. But then is there any benefit to
using LVM if you only have one HD?
--
Boring Home Page - http://www.webtrek.com/joe
See my blog, sumo game ranks and other interesting junk
9:21 p.m.
Joe Klemmer wrote:
Whenever I try to use LVM the install program always complains about
not having any drives to install to. But then is there any benefit to
using LVM if you only have one HD?
The usual advantage claimed is that it is easier to alter partition sizes.
--
Timothy Murphy
e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
10:30 p.m.
New subject: What is the consensus on the best partition scheme and size?/Keeping home separate
Timothy Murphy wrote:
> Whenever I try to use LVM the install program always complains
about
> not having any drives to install to. But then is there any benefit to
> using LVM if you only have one HD?
The usual advantage claimed is that it is easier to alter partition sizes.
That's what bigger drives and "find . -print | cpio -0pduma
{destination}" are for. ;-)
--
Boring Home Page - http://www.webtrek.com/joe
See my blog, sumo game ranks and other interesting junk
6394
days inactive
6400
days old
44 comments
18 participants
participants (18)
-
Andy Green -
Bill Rugolsky Jr. -
Chris Jones -
Denis Leroy -
Dotan Cohen -
Globe Trotter -
James Wilkinson -
Jeff Vian -
Joe Klemmer -
Kam Leo -
Lars E. Pettersson -
linux -
Philippe A. -
Robert P. J. Day -
Thierry -
Tim -
Timothy Murphy -
Wolfgang S. Rupprecht