There are plenty of valid uses. After 1024, I forget why I used one, but I'm pretty sure there was a reason. At the time, I know it was lack of fs support in the kernel, but I can't think of why. I haven't used that system much in several years, and it died a few months ago. Haven't gotten around to rebuilding it (I have the parts, need to extract the CPU cooler & CPU from the old mobo and rebuild with new parts).

EDIT:

Oh, I remember. My /boot is on a separate physical drive. IIRC, /boot & swap on the same drive. Because I could, mainly. Small drive, freed up the partitions / space on the other drives._________________lolgov. 'cause where we're going, you don't have civil liberties.

Yes, now. But earlier it didn't. The question was why anyone would have a separate boot partition. It could be because that's how things had to be a few years ago. The answer wasn't "but things are different now".

Yes, now. But earlier it didn't. The question was why anyone would have a separate boot partition. It could be because that's how things had to be a few years ago. The answer wasn't "but things are different now".

yeah, people these days don't seem to put boot on a separate partition. that is of course another option. simply move /boot to / and make it bootable and merge the other two partitions. perhaps this is easiest and I should just do that. can I do this without a live cd? I can copy the contents of /boot somewhere, unmount /boot, mkdir /boot, and move the contents back. I then should edit /etc/fstab, but will update-grub automagically make the new / partition bootable?

Yes, now. But earlier it didn't. The question was why anyone would have a separate boot partition. It could be because that's how things had to be a few years ago. The answer wasn't "but things are different now".

yeah, people these days don't seem to put boot on a separate partition. that is of course another option. simply move /boot to / and make it bootable and merge the other two partitions. perhaps this is easiest and I should just do that. can I do this without a live cd? I can copy the contents of /boot somewhere, unmount /boot, mkdir /boot, and move the contents back. I then should edit /etc/fstab, but will update-grub automagically make the new / partition bootable?

I think update-grub doesn't make the partition bootable, that's something you need to do elsewhere? Maybe it sets the boot flag however I think the first HDD set in the BIOS just trys to boot from the first partition regardless of whether the boot flag is set.

Separate boot does marginally improve security. As I recall, it was originally (i.e. years ago) necessary so that one could put the stage 2 bootloader within the range of storage addresses addressable by the stage 1 bootloader, which was constrained by the need to keep the stage 1 bootloader small enough to conform with the antediluvian DOS boot sector standard.

If sda6 isn't system critical( /usr or something), you can just unmount sda5 and sda6 and then use gparted from within the working system. /boot doesn't need to be mounted.
Also, how small is your /boot? I'm interested to know how small is small enough to be annoying._________________CFLAGS=" -O999999"

If sda6 isn't system critical( /usr or something), you can just unmount sda5 and sda6 and then use gparted from within the working system. /boot doesn't need to be mounted.
Also, how small is your /boot? I'm interested to know how small is small enough to be annoying.

So small he can't keep his bootsplash graphic collection and his last 64 kernels, System Maps and configs?

1, so I can't delete kernels accidentally
2, I like splitting my mount points down
3, it's ext2 as it takes a smaller journal than 3 or 4 (iirc)
4, when you've been doing the same thing for 8-9 years it becomes habit

Easiest way, yeah. Put sysresccd in a spare usb flash drive (or do as I do, and put it in all your usb flash drives ) and done.

incidently, for aslong as i'd been using Gentoo, I've always set up a 64mb boot. plently of room. but recently I've gone to 512-1024mb of disk space. this allows not only for me to k`eep the kernel onboard, but also systemrescuecd and other live cd's.

This allows me to use the live cd's to demonstrate different distros to curious people without having to keep alot of cd/dvi's on hand

NQS_________________These opinions are mine, mine I say! Piss off and get your own.

If sda6 isn't system critical( /usr or something), you can just unmount sda5 and sda6 and then use gparted from within the working system. /boot doesn't need to be mounted.
Also, how small is your /boot? I'm interested to know how small is small enough to be annoying.

So small he can't keep his bootsplash graphic collection and his last 64 kernels, System Maps and configs?

100MB. Back in the day that was enough. I basically haven't updated that number since 1999 when I first installed linux and kernels were 900kb. Ubuntu kernels are now a whopping 20-30 MB, so basically what happens is that I can only have 2 kernels in the /boot. When the system goes to update I usually just click OK and then it barfs if it is getting a kernel.

If sda6 isn't system critical( /usr or something), you can just unmount sda5 and sda6 and then use gparted from within the working system. /boot doesn't need to be mounted.
Also, how small is your /boot? I'm interested to know how small is small enough to be annoying.

there isn't anything on /dev/sda6. Are you suggesting that I can use gparted and expand /dev/sda5 and reduce /dev/sda6 while my OS is booted? Keep in mind that my OS is /dev/sda8 (i.e. the same physical disk). I thought that if you use gparted on part of a physical disk, no part of that disk can be mounted. I have no basis to think this though. If so, however, this will be trivial no? Unmount /boot, fire up gparted, shrink/grow, remount. Child's play, no?

If sda6 isn't system critical( /usr or something), you can just unmount sda5 and sda6 and then use gparted from within the working system. /boot doesn't need to be mounted.
Also, how small is your /boot? I'm interested to know how small is small enough to be annoying.

there isn't anything on /dev/sda6. Are you suggesting that I can use gparted and expand /dev/sda5 and reduce /dev/sda6 while my OS is booted? Keep in mind that my OS is /dev/sda8 (i.e. the same physical disk). I thought that if you use gparted on part of a physical disk, no part of that disk can be mounted. I have no basis to think this though. If so, however, this will be trivial no? Unmount /boot, fire up gparted, shrink/grow, remount. Child's play, no?

That's exactly what I'm thinking. I'm almost certain you can use gparted on any part of any disk, provided the sections you're editing are unmounted.
Try it, at least. If gparted won't let you do that, then there's no harm._________________CFLAGS=" -O999999"

If sda6 isn't system critical( /usr or something), you can just unmount sda5 and sda6 and then use gparted from within the working system. /boot doesn't need to be mounted.
Also, how small is your /boot? I'm interested to know how small is small enough to be annoying.

So small he can't keep his bootsplash graphic collection and his last 64 kernels, System Maps and configs?

100MB. Back in the day that was enough. I basically haven't updated that number since 1999 when I first installed linux and kernels were 900kb. Ubuntu kernels are now a whopping 20-30 MB, so basically what happens is that I can only have 2 kernels in the /boot. When the system goes to update I usually just click OK and then it barfs if it is getting a kernel.

I made mine 32 cylinders (about 268 MiB). I rarely have more than about 12 MiB of stuff in there, but this way I don't stupidly force myself into a jug-fuck of moving partitions around if I want to do something that requires more space.

If sda6 isn't system critical( /usr or something), you can just unmount sda5 and sda6 and then use gparted from within the working system. /boot doesn't need to be mounted.
Also, how small is your /boot? I'm interested to know how small is small enough to be annoying.

So small he can't keep his bootsplash graphic collection and his last 64 kernels, System Maps and configs?

100MB. Back in the day that was enough. I basically haven't updated that number since 1999 when I first installed linux and kernels were 900kb. Ubuntu kernels are now a whopping 20-30 MB, so basically what happens is that I can only have 2 kernels in the /boot. When the system goes to update I usually just click OK and then it barfs if it is getting a kernel.

I made mine 32 cylinders (about 268 MiB). I rarely have more than about 12 MiB of stuff in there, but this way I don't stupidly force myself into a jug-fuck of moving partitions around if I want to do something that requires more space.

well, that's the situation i am in now. I will probably just increase it to 500MB and be done with it. Have my disc is unused, so...

If sda6 isn't system critical( /usr or something), you can just unmount sda5 and sda6 and then use gparted from within the working system. /boot doesn't need to be mounted.
Also, how small is your /boot? I'm interested to know how small is small enough to be annoying.

So small he can't keep his bootsplash graphic collection and his last 64 kernels, System Maps and configs?

100MB. Back in the day that was enough. I basically haven't updated that number since 1999 when I first installed linux and kernels were 900kb. Ubuntu kernels are now a whopping 20-30 MB, so basically what happens is that I can only have 2 kernels in the /boot. When the system goes to update I usually just click OK and then it barfs if it is getting a kernel.

I made mine 32 cylinders (about 268 MiB). I rarely have more than about 12 MiB of stuff in there, but this way I don't stupidly force myself into a jug-fuck of moving partitions around if I want to do something that requires more space.

well, that's the situation i am in now. I will probably just increase it to 500MB and be done with it. Have my disc is unused, so...

You could just put your boot partition somewhere else on the disk, but if you're OCD, that won't do. Besides, moving partitions around has the side effect of defragmentation, if you do it right. Boot from CD, purge your tmp directories, then 'cp -a' each partition somewhere else (ideally, with the destination partition(s) mounted with the same options as the originals, as it pertains to atimes and that sort of thing). Then fix your partitions and 'cp -a' it all back. You can do a byte-wise copy or move using dd or the equivalent (which is what most partition utility "move" and "copy" functions do, I think), but that wastes time moving all your empty space, does not defragment the filesystem, and replicates any filesystem errors. Tar and compression might be useful, but if your disk is less than half full, you have no issue, and I'm not sure it actually saves any time unless you're copying somewhere over the network.

I've done this sort of thing several times without problems, so if you destroy your data, it's not my fault.