Re: Good fdisk Practices
David Brodbeck [EMAIL PROTECTED] wrote: There may be good reason for it still in terms of security. /boot doesn't need to be mounted on a running system. I'm not sure if that adds a lot of security though. I'm thinking no. To alter any of the kernel files you'd need root privileges, and if you have that, you can do 'mount /boot'. I read an installation doc a long time ago that suggested mounting boot read-only for security - have done so ever since. It's not every day I need to update the kernel. -- Jamin @ Home: Chester UK -[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
Ron Johnson [EMAIL PROTECTED] wrote: I'm a big proponent of swap *files*. Once you allocate the whole disk, there no room left over if you want to add another swap partition, whereas you can add as many swap files as your heart desires, whenever you need them. After reading this thread I switched from using two swap partitions to swapfiles. It may sound obvious but the docs I read didn't mention permissions on the swapfile which should be 0600.. don't want a world-readable swap :) -- Jamin @ Home: Chester UK -[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
On Aug 25, 2007, at 8:52 PM, Douglas A. Tutty wrote: On the other hand, having /boot separate could be more robust in the event of an unclean shutdown. The system won't boot at all if the kernel file gets corrupted, so having /boot separate, and perhaps mounted ro helps protect it. I suppose, but I've never had an unclean shutdown corrupt a filesystem that wasn't being written to. So I'm not sure if it matters whether it's ro or rw, as long as you aren't writing to it at the time of the crash. Also, if the root filesystem is corrupt, the system won't boot whether the kernel file is OK or not; you have to get far enough to load init and a shell for anything useful to happen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
* Ron Johnson [EMAIL PROTECTED] [2007-08-24 16:40:08 -0500]: Or go out on Ebay and buy some replacement RAM chips. If the chips on your Hell aren't soldered onto the mobo. Yep, good point. -- Regards, Klein. Hey, what do you expect from a culture that *drives* on *parkways* and *parks* on *driveways*? -- Gallagher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
Ron Johnson [EMAIL PROTECTED]: On 08/24/07 11:16, David Brodbeck wrote: Also, is there any good reason to have a separate /boot on a modern system? I always thought /boot was just a kludge to get around old BIOSes that couldn't load anything that wasn't on the first part of the I doubt it. I still do it, though, from tradition I guess. There may be good reason for it still in terms of security. /boot doesn't need to be mounted on a running system. I'm not sure if that adds a lot of security though. -- Any technology distinguishable from magic is insufficiently advanced. (*)http://blinkynet.net/comp/uip5.html Linux Counter #80292 - -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
On Aug 25, 2007, at 5:23 PM, s. keeling wrote: Ron Johnson [EMAIL PROTECTED]: On 08/24/07 11:16, David Brodbeck wrote: Also, is there any good reason to have a separate /boot on a modern system? I always thought /boot was just a kludge to get around old BIOSes that couldn't load anything that wasn't on the first part of the I doubt it. I still do it, though, from tradition I guess. There may be good reason for it still in terms of security. /boot doesn't need to be mounted on a running system. I'm not sure if that adds a lot of security though. I'm thinking no. To alter any of the kernel files you'd need root privileges, and if you have that, you can do 'mount /boot'. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
David Brodbeck writes: I'm thinking no. To alter any of the kernel files you'd need root privileges, and if you have that, you can do 'mount /boot'. True for an intelligent cracker, but a trojan trying to patch the kernel isn't going to know to mount anything. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
On Sat, Aug 25, 2007 at 11:59:02AM -0700, David Brodbeck wrote: On Aug 25, 2007, at 5:23 PM, s. keeling wrote: Ron Johnson [EMAIL PROTECTED]: On 08/24/07 11:16, David Brodbeck wrote: Also, is there any good reason to have a separate /boot on a modern system? I always thought /boot was just a kludge to get around old BIOSes that couldn't load anything that wasn't on the first part of the I doubt it. I still do it, though, from tradition I guess. There may be good reason for it still in terms of security. /boot doesn't need to be mounted on a running system. I'm not sure if that adds a lot of security though. I'm thinking no. To alter any of the kernel files you'd need root privileges, and if you have that, you can do 'mount /boot'. On the other hand, having /boot separate could be more robust in the event of an unclean shutdown. The system won't boot at all if the kernel file gets corrupted, so having /boot separate, and perhaps mounted ro helps protect it. Having all the other usual directories split off leaving a 300M / helps to protect / in a similar fashion. I was going to say that its also nice to have a static-linked shell for those times when you need init=/bin/sh, however: # ldd /bin/sash /usr/bin/ldd: line 171: /lib/ld-linux.so.2: No such file or directory ldd: /lib/ld-linux.so.2 exited with unknown exit code (127) IMHO a shared library should not have an unknown exit code; ldd should know all exit codes of shared libraries. So what about busybox-staic? The kernel depends on initramfs-tools which depends on busybox which conflicts with busybox-static. initramfs-tools doesn't give the option of busybox-static. It does give an option of busybox-cvs-static but it doesn't seem to be available on amd64. Sheesh. So perhaps having /boot separate doesn't matter (unless otherwise using LVM) since there's nothing for the kernel to boot if the shared libraries get corrupted. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Good fdisk Practices
It appears after reading the fdisk manual, that it is best to put swap on whats left of the disk after calculating one's other partition needs. The boot image should end up in the lowest sector numbers. Do I understand this right? I am about to reformat a 20-gig hard disk on a 5-year-old Dell laptop that used to run Windows XP. You might say, I am giving it a whole new outlook. The present fdisk report for /dev/hda shows a 32-MB partition 1 and a 19-gig partition 2. I think I will probably make it 19-gigs for partition 1 and 512 MB for partition2 since the system has 256 K of RAM. Partition 1 will be Linux and partition2 will be swap. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Network Operations Group -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
On Fri, Aug 24, 2007 at 08:10:41AM -0500, Martin McCormick wrote: It appears after reading the fdisk manual, that it is best to put swap on whats left of the disk after calculating one's other partition needs. The boot image should end up in the lowest sector numbers. Do I understand this right? I am about to reformat a 20-gig hard disk on a 5-year-old Dell laptop that used to run Windows XP. You might say, I am giving it a whole new outlook. The present fdisk report for /dev/hda shows a 32-MB partition 1 and a 19-gig partition 2. I think I will probably make it 19-gigs for partition 1 and 512 MB for partition2 since the system has 256 K of RAM. Partition 1 will be Linux and partition2 will be swap. A few thoughts: With badblock remapping, you never really know where on a drive a block is. I like to have separate filesystems to prevent some runaway of hosing the system. / 300 M, perhaps a separate /boot of 32 M, /usr 3 G, /var 3G, then separate /home and perhaps /srv for things like chroots and mirrors. If you want to be able to resize them, use LVM even though you only have one drive. You can put swap on LVM. While you're at it you can encrypt swap too. Since its a laptop, you could encrypt the /home directory (password provided at boot up) and put /tmp on tmpfs so its encrypted by swap as needed. All this can be done by the standard Etch installer. As for swap size, don't just go by a simple 'double of ram' formula. Go to an existing Debian system and start up all the apps you usually run concurrently, including the biggest app (e.g. Iceweasel with lots of tabs open). Run top in an xterm and look at how much memory + swap is used and this becomes your memory footprint. Add 20%, subtract the 256M (hopefully not K) and you have the size of your swap. If swap is on LVM, you can resize it as needed. Good luck, Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/07 08:10, Martin McCormick wrote: It appears after reading the fdisk manual, that it is best to put swap on whats left of the disk after calculating one's other partition needs. The boot image should end up in the lowest sector numbers. Do I understand this right? I am about to reformat a 20-gig hard disk on a 5-year-old Dell laptop that used to run Windows XP. You might say, I am giving it a whole new outlook. The present fdisk report for /dev/hda shows a 32-MB partition 1 and a 19-gig partition 2. I think I will probably make it 19-gigs for partition 1 and 512 MB for partition2 since the system has 256 K of RAM. Partition 1 will be Linux and partition2 will be swap. I'm a big proponent of swap *files*. Once you allocate the whole disk, there no room left over if you want to add another swap partition, whereas you can add as many swap files as your heart desires, whenever you need them. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGzunZS9HxQb37XmcRArXIAJ0fkrmKhLJjc1wKFuBR2603Oi9z9ACePbw5 SpNtuefZSjribJxzUIbo66Y= =6sdQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
On Aug 24, 2007, at 7:23 AM, Ron Johnson wrote: I'm a big proponent of swap *files*. Once you allocate the whole disk, there no room left over if you want to add another swap partition, whereas you can add as many swap files as your heart desires, whenever you need them. I'd always heard that swap files are slower than swap partitions. Is that a myth? Also, is there any good reason to have a separate /boot on a modern system? I always thought /boot was just a kludge to get around old BIOSes that couldn't load anything that wasn't on the first part of the disk. I tend to just combine /boot and / on my newer systems -- am I taking some kind of risk by doing so? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/07 11:16, David Brodbeck wrote: On Aug 24, 2007, at 7:23 AM, Ron Johnson wrote: I'm a big proponent of swap *files*. Once you allocate the whole disk, there no room left over if you want to add another swap partition, whereas you can add as many swap files as your heart desires, whenever you need them. I'd always heard that swap files are slower than swap partitions. Is that a myth? That was the definite truth in v2.4 and lower. It was supposed to be fixed in 2.6. Also, is there any good reason to have a separate /boot on a modern system? I always thought /boot was just a kludge to get around old BIOSes that couldn't load anything that wasn't on the first part of the disk. I tend to just combine /boot and / on my newer systems -- am I taking some kind of risk by doing so? I doubt it. I still do it, though, from tradition I guess. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGzw9ES9HxQb37XmcRAqKPAKDWVKYjxK6roMeUbZ2plcA6veRuDQCgpLpJ YbvbJ81FH1CAq3LOhrP7KEs= =KHco -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ron Johnson wrote: On 08/24/07 11:16, David Brodbeck wrote: On Aug 24, 2007, at 7:23 AM, Ron Johnson wrote: I'm a big proponent of swap *files*. Once you allocate the whole disk, there no room left over if you want to add another swap partition, whereas you can add as many swap files as your heart desires, whenever you need them. I'd always heard that swap files are slower than swap partitions. Is that a myth? That was the definite truth in v2.4 and lower. It was supposed to be fixed in 2.6. Also, is there any good reason to have a separate /boot on a modern system? I always thought /boot was just a kludge to get around old BIOSes that couldn't load anything that wasn't on the first part of the disk. I tend to just combine /boot and / on my newer systems -- am I taking some kind of risk by doing so? I doubt it. I still do it, though, from tradition I guess. If you use LVM you're stuck with a separate, non-LVM /boot partition AFAIK. Or is this outated info? Cassiano -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzxRJq4Bz51JiUuERAq0LAKDrxG2z5Ix6fTWTWuIhhQk7FQWDqQCgjLUV zNPlzIXg0uaJzNbuNspaJeU= =EAQs -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
I'm a big proponent of swap *files*. Once you allocate the whole disk, there no room left over if you want to add another swap partition, whereas you can add as many swap files as your heart desires, whenever you need them. I'd always heard that swap files are slower than swap partitions. Is that a myth? Also, is there any good reason to have a separate /boot on a modern system? I always thought /boot was just a kludge to get around old BIOSes that couldn't load anything that wasn't on the first part of the disk. I tend to just combine /boot and / on my newer systems -- am I taking some kind of risk by doing so? All my drives have 2 partitions: a /boot (with ext2 or ext3) of about 100MB and the rest is an partition dedicated to LVM. The reason for the separate /boot is that GRUB does not know how to read files from LVM volumes, so I need to load the kernel and initrd files from an ext[23]. Everything else (/, /home, swap, etc..) is placed in LVM volumes. Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
Cassiano Bertol Leal wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ron Johnson wrote: On 08/24/07 11:16, David Brodbeck wrote: On Aug 24, 2007, at 7:23 AM, Ron Johnson wrote: I'm a big proponent of swap *files*. Once you allocate the whole disk, there no room left over if you want to add another swap partition, whereas you can add as many swap files as your heart desires, whenever you need them. I'd always heard that swap files are slower than swap partitions. Is that a myth? That was the definite truth in v2.4 and lower. It was supposed to be fixed in 2.6. Also, is there any good reason to have a separate /boot on a modern system? I always thought /boot was just a kludge to get around old BIOSes that couldn't load anything that wasn't on the first part of the disk. I tend to just combine /boot and / on my newer systems -- am I taking some kind of risk by doing so? I doubt it. I still do it, though, from tradition I guess. If you use LVM you're stuck with a separate, non-LVM /boot partition AFAIK. Or is this outated info? Also true if you use XFS filesystem for /, as grub has (or had) problems with reading it. Cassiano -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGzxRJq4Bz51JiUuERAq0LAKDrxG2z5Ix6fTWTWuIhhQk7FQWDqQCgjLUV zNPlzIXg0uaJzNbuNspaJeU= =EAQs -END PGP SIGNATURE- -- Bob McGowan smime.p7s Description: S/MIME Cryptographic Signature
Re: Good fdisk Practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/07 12:51, Stefan Monnier wrote: I'm a big proponent of swap *files*. Once you allocate the whole disk, there no room left over if you want to add another swap partition, whereas you can add as many swap files as your heart desires, whenever you need them. I'd always heard that swap files are slower than swap partitions. Is that a myth? Also, is there any good reason to have a separate /boot on a modern system? I always thought /boot was just a kludge to get around old BIOSes that couldn't load anything that wasn't on the first part of the disk. I tend to just combine /boot and / on my newer systems -- am I taking some kind of risk by doing so? All my drives have 2 partitions: a /boot (with ext2 or ext3) of about 100MB and the rest is an partition dedicated to LVM. The reason for the separate /boot is that GRUB does not know how to read files from LVM volumes, so I need to load the kernel and initrd files from an ext[23]. Everything else (/, /home, swap, etc..) is placed in LVM volumes. I read recently on this list that LVM is not portable across CPU architectures, so that you can't just upgrade your mobo to AMD64 and retain your /home. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGzy3eS9HxQb37XmcRAnDpAJ9KEs2wvyB8i+AeUK1B1oaeivM8FwCgk3nt iG1Dfg4nC25bBbsFDgMDwNo= =XxMf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
On Aug 24, 2007, at 10:24 AM, Cassiano Bertol Leal wrote: If you use LVM you're stuck with a separate, non-LVM /boot partition AFAIK. Or is this outated info? I think that's true. I don't usually make the root filesystem an LVM volume, anyway. In most distributions it's quite small and making it a normal partition makes some recovery scenarios easier -- it's just one less thing that has to work for the system to boot into single user mode. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
On Aug 24, 2007, at 12:13 PM, Ron Johnson wrote: I read recently on this list that LVM is not portable across CPU architectures, so that you can't just upgrade your mobo to AMD64 and retain your /home. Well, now you've got me curious. If so, this is potentially a serious issue, because most rescue disks are 32-bit. If it's true, then an LVM created on a 64-bit system wouldn't be readable with a 32- bit rescue disk. It also might have implications for things like USB hard disks. (These are getting big enough where it might start to make sense to LVM them -- I have one USB array that's 1.5 TB.) I happen to have a spare AMD64 system and a couple of spare IA32 systems, all with hot-swap drive bays that take the same sleds, so I may try this and see what happens. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
On Fri, 24 Aug 2007 13:14:42 -0700 David Brodbeck [EMAIL PROTECTED] wrote: On Aug 24, 2007, at 10:24 AM, Cassiano Bertol Leal wrote: If you use LVM you're stuck with a separate, non-LVM /boot partition AFAIK. Or is this outated info? I think that's true. I don't usually make the root filesystem an LVM volume, anyway. In most distributions it's quite small and making it a normal partition makes some recovery scenarios easier -- it's just one less thing that has to work for the system to boot into single user mode. I believe it is actually outdated information; GRUB apparently supports LVM these days: http://grub.enbug.org/LVMandRAID Celejar -- mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
On Fri, 24 Aug 2007 13:51:14 -0400 Stefan Monnier [EMAIL PROTECTED] wrote: All my drives have 2 partitions: a /boot (with ext2 or ext3) of about 100MB and the rest is an partition dedicated to LVM. The reason for the separate /boot is that GRUB does not know how to read files from LVM volumes, so I need to load the kernel and initrd files from an ext[23]. Everything else Apparently no longer true, as I pointed out in another message in this thread. Stefan Celejar -- mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
Celejar wrote: Cassiano Bertol Leal wrote: If you use LVM you're stuck with a separate, non-LVM /boot partition AFAIK. Or is this outated info? I believe it is actually outdated information; GRUB apparently supports LVM these days: http://grub.enbug.org/LVMandRAID Check the version number of grub though. That is only available in the newer versions. You need grub2-pc at the least. I am not sure how mature grub2-pc is at this time. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
* Martin McCormick [EMAIL PROTECTED] [2007-08-24 08:10:41 -0500]: It appears after reading the fdisk manual, that it is best to put swap on whats left of the disk after calculating one's other partition needs. The boot image should end up in the lowest sector numbers. Do I understand this right? Yep. I am about to reformat a 20-gig hard disk on a 5-year-old Dell laptop that used to run Windows XP. You might say, I am giving it a whole new outlook. Got that right. The present fdisk report for /dev/hda shows a 32-MB partition 1 and a 19-gig partition 2. I think I will probably make it 19-gigs for partition 1 and 512 MB for partition2 since the system has 256 K of RAM. Partition 1 will be Linux and partition2 will be swap. Hmm. Consider this: In older machines where hard drive physical speed can be a noticable factor in machine performance, it makes sense to to place your partitions that see the most activity in terms of read/write accesses physically close to each other with swap in between. The head doesn't have to move as far to accomplish the same task. Hanging the swap out at the end can be a detriment. Perhaps a scheme such as this: 50 Mg /boot at the beginning 300 Mg / 5 gig /usr 3 gig /var 384 - 512 Mg swap 480 Mg /tmp and the balance as /home -- Regards, Klein. One doesn't have a sense of humor. It has you. -- Larry Gelbart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/07 16:02, Klein Moebius wrote: [snip] In older machines where hard drive physical speed can be a noticable factor in machine performance, it makes sense to to place your partitions that see the most activity in terms of read/write accesses physically close to each other with swap in between. The head doesn't Or go out on Ebay and buy some replacement RAM chips. If the chips on your Hell aren't soldered onto the mobo. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGz1A4S9HxQb37XmcRAmjtAJ4y9FQVcdJpg7a/7cQxiH7QQeyyXQCeNNsE 6AC7lKbX1GvtO4smBy6PZCA= =r3Tc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
I read recently on this list that LVM is not portable across CPU Don't believe everything you read. Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
LVM volume portability (was: Re: Good fdisk Practices)
On Aug 24, 2007, at 1:18 PM, David Brodbeck wrote: On Aug 24, 2007, at 12:13 PM, Ron Johnson wrote: I read recently on this list that LVM is not portable across CPU architectures, so that you can't just upgrade your mobo to AMD64 and retain your /home. Well, now you've got me curious. If so, this is potentially a serious issue, because most rescue disks are 32-bit. If it's true, then an LVM created on a 64-bit system wouldn't be readable with a 32-bit rescue disk. It also might have implications for things like USB hard disks. (These are getting big enough where it might start to make sense to LVM them -- I have one USB array that's 1.5 TB.) I happen to have a spare AMD64 system and a couple of spare IA32 systems, all with hot-swap drive bays that take the same sleds, so I may try this and see what happens. OK, so here are the results. I installed RHEL Server 5 AMD64 on a dual Opteron system. (Yeah, I know. But I had the CDs handy, and I didn't have any 64-bit Debian CDs.) I stuck a spare 160 gigabyte hard disk in one of the hot-swap bays and created a single LVM partition covering the entire drive. I then initialized it and created a 100 gigabyte logical volume, which I formatted with ext3fs. Then, for good measure, I created a 100 megabyte file of random bits and calculated its md5 checksum. First test: Same hardware, 32-bit kernel: I rebooted the same system, this time using a RIP Linux 2.5 rescue CD. Ran vgscan, vgchange -ay to activate the volume group, then mounted it. No errors. The md5 checksums matched. Second test: 32-bit hardware: I moved the drive to a dual Xeon system and booted RIP Linux 2.5. Again, no problems. The volume mounted cleanly and the checksums matched. So, I'm concluding for now that there aren't any portability issues when moving an LVM volume group between IA32 and AMD64 architectures. If someone has tried it and had it *not* work, I'd like to know about it, because this is an issue that could potentially affect me at some point in the future. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Believing what you read (was Re: Good fdisk Practices)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/07 16:24, Stefan Monnier wrote: I read recently on this list that LVM is not portable across CPU Don't believe everything you read. That's why I qualified my statement. I think it was Doug Tutty who reported here that he had LVM problems when upgrading to AMD64. - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGz2/dS9HxQb37XmcRAhQbAJ9/sOTntAMjsBqSxIJbkhZHP61OzgCfekmJ sZDvdybRrfozQR+QSFen+og= =jA7X -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Believing what you read (was Re: Good fdisk Practices)
On Fri, Aug 24, 2007 at 06:55:09PM -0500, Ron Johnson wrote: On 08/24/07 16:24, Stefan Monnier wrote: I read recently on this list that LVM is not portable across CPU Don't believe everything you read. That's why I qualified my statement. I think it was Doug Tutty who reported here that he had LVM problems when upgrading to AMD64. Not that I recall; but then again I have a bad memory. Don't make work, but if you find the link for such a message from me I'd like to review it. My Athlon64 uses SATA and all my other boxes use PATA so I've never moved a drive from one to the other. I use routinely the raid1/boot, raid1/LVM combos for the system directories with plain LVM on normal partitions for /home. When I get into video editing, I plan to put /var/tmp (or whatever) on a striped LV. I'm also a big fan of LVM for my old boxes. Old boxes have old drives. So far, the old drives have given some pre-failure warnings (non-SMART) in syslog before the filesystem gets corrupted. Its nice to be able to add a drive to the system and migrate the data, without needing to keep two drives in the box for raid1. Also, no two of my PATA drives are the same size. The only problem with installing that I've had consistently is that GRUB doesn't end up on the disk. I think I've tracked it down to the partitioner forgetting that I've set up the /boot partition whenever I set up something else. My recent re-install of my Athlon64 box (wanted to change from JFS back to ext3) took me 4 hours just to get the partitioner to work right; I had to keep starting the install over. Luckily, I have CD-bin1.iso since I'm on dialup. Thanks, Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good fdisk Practices
David Brodbeck [EMAIL PROTECTED] wrote: I'd always heard that swap files are slower than swap partitions. Is that a myth? Not a myth, just old information. It used to be the case that swap files were slower than swap partitions, but this stopped being true sometime around kernel 2.4 Also, is there any good reason to have a separate /boot on a modern system? I always thought /boot was just a kludge to get around old BIOSes that couldn't load anything that wasn't on the first part of the disk. I tend to just combine /boot and / on my newer systems -- am I taking some kind of risk by doing so? I do the same and have had no problems. This may restrict the type of filesystem you can use on your root partition though. I dont think GRUB can load a kernel from an XFS filesystem, so by separating root and /boot, you can put ext2/3 on /boot and something else on root. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
