[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Mon, 13 Jun 2011, Simon Waters wrote:
On 13/06/11 10:03, Gordon Henderson wrote:Anyway, hand-crafting a partition table with sfdisk sorted it for me. (Although now cfdisk now won't look at the partition table, fdisk tells me I have a paritition not on a cylinder boundary and thus isn't DOS compatable, even though it's 100% correct as far as Linux cares!)So you spent time "fixing" an issue that saves a fraction of 0.00005% of your available disk space (did this space cost as much as a tenth of a penny?), instead of accepting the default which is more compatible with other tools and then wonder why this process is frustrating?
Yes, I spent time fixing something to save me 0.00005% of my disk space.It's not just about saving disk space - however that is important when I build Linux systems for my embedded stuff, so when someone removes 1MB of my 32MB flash disk, I need to know why and I need to know that I can recover it if needed - that's why I spend time on these things rather than blindly accepting it.
So I like to understand the reason behind things. I still can't see why they jumped to 2048 rather than 64. When you have 4K native sectors, with 512 byte reported sectors (in the case of the WDC 'EARS' drives and possibly others), the start sector of the partition simply has to be divisible by 8. There's no magic there.
The tool compatibility thing is odd though - it appears that having your partition table compatible with DOS is now deprecated - fair enough - who uses DOS! So what that boils down to is not slaving yourself to "cylinder boundaries". These disks have an odd number of sectors per cylinder, so not aligning them is good - unless you're using DOS. Which I'm not. So I didn't align them - now cfdisk won't touch it. I suspect cfdisk hasn't quite caught up with fdisk and still wants things cylinder boundary aligned. Cfdisk was nice, but I don't care - I've gotten used to sfdisk and bc.
Then I tried to add in a 2nd identical drive, used sfdisk to copy the partition over, then went through the runes to install mdadm, and do it properly. Got stuck there. Well stuck. Wasted a long time. Still don't have this sorted - had to uninstall mdadm in the end and ended up copying a lot of data - again.Wouldn't it have been less painful just to install the OS to the new disks, and copy across the data from the old one. It takes about 20 minutes to partition the disks as a mirrored pair, and install basic Debian, and can all be done from the installers menus.
It would have been - and I did consider it - but I didn't fancy downloading another 2.5GB for a full install. Besides, I've done it that way before and not had any issues...
Then I tried to compile a custom kernelWhy? If it is to save a few seconds on boot, you've already spent that time many times over.
It's not to save time on boot. My last workstation had an uptime of 180 days. I do not reboot it. Apart from my laptop, I don't reboot things, so I don't really care about boot time. I just like things to be efficient - and when dealing with slow low-power processors, if I can squeeze another ounce out of the system, I will. (My electric bill is measurably less than it was last year, despite rising fuel prices)
I like things that last: $ uptime 11:45:36 up 958 days, 13:51, 1 user, load average: 0.00, 0.00, 0.00 $ uptime 11:45:13 up 1348 days, 16:05, 2 users, load average: 0.00, 0.00, 0.00And one of these is a very active device, very directly connected to the public facing Internet too. It's a router passing GB of data every day...
(FWIW: Power on full usability: 45 seconds. 18 of that is BIOS to LILO prompt, so if I could eliminate that then a 27 second boot time isn't bad for a 1.6GHz processor - that's auto login to fully running XFCE4)
- easy enough, but it doesn't work. It stops halfway through the boot sequence, and right now I can't work out why.At which point, last message/error?
Difficult to get the messages out as they're all on the svga console and I don't have another box to hand to get serial output, but it's right after it's detected the disks. (Small update - it's do with starting init, so actually after the kernel has loaded and mounted root read-only)
All in all, it's been a fairly frustrating experience - the good-side is that the 3 PCs I built recently all more or less "just worked" and following through the published stuff to make DVDs & CDs play was all very fine and good and relatively straighforward - so when you stick to the system, it seems it's fine, but dare to deviate ...You have to understand it, a lot has changed, but most of it is progress (like UUID, which are a tad unwieldy, but make it much easier to move file systems around if you actually move the filesystem rather than copy the data, which would have been fine as it can be extended etc).
I'm trying to understand the changes - that's what frustrating! And yes, I could have DD'd the filesystem and expanded it, but .. I still don't really trust those things and would rather copy things the way I've always copied - at least I learnt about UUIDs.
Linux from scratch is looking more and more attractive ...If you don't know how to build a modern kernel to boot your system I doubt Linux from Scratch will make it substantially easier. Presumably you forgot to compile in a required driver (SATA?), or you passed a UUID to the boot loader and don't have anything clever enough to make use of it in the boot process (like urm initrd kernel).
You probably mean a modern kernel with modules and an initrd - in which case, you're right, I don't know. I've also no real need to know right now because I don't need it. Sure - it might be the way things are going, but not in my world right now. I build systems for a purpose - they rarely change during their lifetime - I have a variety of systems from servers with TBs of disks (some running Squeeze with a completely static kernel and no udev and some running Woody and some running every other Debian in-between) to embedded devices sat in a corner gathering dust with uptimes measured in years to others hurtling up and down the country at 125mph running on the dodgiest power supples you've stuck a meter on which get power cycled very regularly... (24 hours is a long uptime for these boxes)
Anyway, I've worked out the issue, not going to bore you with the details, (although it wasn't to do with the kernel in the end), and I now have Debian Squeeze running with the kernel of my choice with the compiled in options of my choice, tuned to my procssor, memory and hardware, with no initrd, and very little modules - which I'll tune up later. Udev is still running, consuming resources for no real reason, and I'm running xfce4 with a minimal configuration, although I have allowed myself a few toys, but I've also used the configuration editor to remove all desktop furniture, stop all automounting and generally not get in my way.
(And I can still boot it with the original Debian kernel, etc., should I desire)
The xfce menus are still a pain, but I'll crack that in good time. For now, it's good enough for me to stick to it and not go back to FVWM.
Gordon -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq