Re: Command Line Partitioning
Honestly, that's WAY more of a level of involvement than what I want to get into. I've already figured out what I need to do and compared it to the size of the memory and the CPU and so on.
I have a general rule: the less work (and still achieving my goal), the better. The fewer exceptions I need to maintain, the better. If all goes well, I'll be adding systems along the way, they're going to be in remote locations, and I don't want to be dealing with issues of custom kernels. I want the system to be as stock Debian as possible so I can get security updates and so on with "apt-get update && apt-get upgrade." While I know it's not always that easy, I've learned that the less I customize, the less there is that is likely to go wrong later.
What I have found (as recommended by someone else) is sfdisk, which gives me the abilities of fdisk in a program intended for scripting (actually, reading the man page reminds me I could use input redirection for sfdisk and that might work for fdisk as well). It's a simple solution and doesn't create anything that'll add to the work of maintaining it later.
Thank you for the suggestions, though. They are things I'll be looking into with other projects.
Hal
On Feb 19, 2011, at 1:02 PM, Stephen Powell wrote:
> On Sat, 19 Feb 2011 11:49:41 -0500 (EST), Hal Vaughan wrote:
>>
>> I have everything else worked out so it can be done in a batch mode
>> or in a program, but I'm having trouble with partitioning.
>>
>> I've been working with cfdisk, fdisk, and parted:
>>
>> parted: Always leaves only 512 bytes at the start and grub-install
>> doesn't seem to like that. But it can be used in a batch mode.
>>
>> fdisk: Doesn't seem to have a batch/script mode and I'd have to
>> calculate sizes in megabytes from cylinder info
>>
>> cfdisk: Lets me work in whatever units I like (bytes, kbytes, mbytes,
>> and so on) but is curses based and doesn't have batch/script mode.
>>
>> What I would like to do is to be able to use a partitioning program
>> from a batch or script mode. Parted would be good for that, but I
>> can't seem to get it to leave more than 512 bytes at the start
>> (cfdisk left 32k -- why? I don't know).
>>
>> Also, it seems when I get CF disks they have an MS-DOS partition
>> table (grub kept noting that and one part of the whole process
>> didn't seem to like that). How can I either wipe the disk without
>> a mess (tried zeroing it, parted wouldn't recognize it or write to
>> it, but fdisk had no issue with that) or write a new partition table?
>> What type of partition table should I use? (I'm guessing bsd, which
>> was one of the options, but there wasn't a Linux option for types of
>> partition tables.)
>
> Well, if I were in your situation I think I know what I would do.
> I would use another boot loader besides grub2, such as lilo or
> extlinux, that doesn't need to allocate sectors at the beginning
> of the disk which are supposed to be unallocated (or in the case of
> parted, are part of a partition). Both lilo and extlinux can be
> installed in either the master boot record or a partition boot sector
> and are perfectly happy with the MS-DOS partitioning scheme.
> With extlinux you are limited to either the ext2 or ext3 filesystem
> for the /boot partition. With lilo you can use just about anything
> for a file system. The down side of lilo is that the boot loader
> installer has to be run any time the physical location of any
> sector in the kernel image file or the initial RAM disk image file
> changes.
>
> I have a web page that you may find useful. It is
>
> http://users.wowway.com/~zlinuxman/Kernel.htm
>
> You may find it useful for several reasons. First of all, it is
> very common when working with embedded systems to create a custom
> Linux kernel. A "lean and mean" kernel is often created which contains
> only the drivers which are actually needed for that particular
> embedded system. This saves hard disk space and memory space on
> the embedded device (but not on the system on which one actually
> compiles the kernel!)
>
> Second, step 10, "Customize the Kernel Installation Environment",
> contains stuff which is useful even to people who use stock
> kernels. For example, there is a section on how to switch to
> lilo from another boot loader (in this case, grub 1 from Lenny)
> and covers some little known stuff about lilo, such as how to
> make use of UUIDs in lilo, how to determine the capabilities of
> the BIOS, etc. Third, if you are using a custom kernel built
> in the manner recommended in the write-up, and you are using
> lilo, you will probably need some extra "hook scripts" which
> don't currently ship with lilo. This write-up provides some
> sample hook scripts which you may find useful.
>
> Good luck with your project.
>
> --
> .''`. Stephen Powell
> : :' :
> `. `'`
> `-
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 1193057518.926874.1298138552084.JavaMail.root@md01.wow.synacor.com">http://lists.debian.org/[🔎] 1193057518.926874.1298138552084.JavaMail.root@md01.wow.synacor.com
>
Reply to: