So here I am, finally getting around to installing Gentoo on an extra disk in babylon5, with the intention of migrating over to it altogether once I get it set up how I want. Right now, I'm still running my Gentoo environment chrooted under my 2.4.31 kernel, until I have it fully set up. Only, so far I'm running into a few setup problems I can't find answers to.
- I can get emerge to build Perl with ithreads enabled by placing 'dev-lang/perl ithreads' in /etc/portage/package.use. I cannot get it to build Perl with ithreads, use64bitint, and uselongdouble enabled; it ignores all my attempts to do so. How do I make it play nice in this regard, and keep doing so?
- Every time I emerge a package, it gives me a list of dependencies it will install. Among this list, invariably it tells me that before proceeding, I should update portage to sys-apps/portage-2.0.51.22-r3 before proceeding, and that I can accomplish this by emerge -u portage. When I then execute emerge -u portage, it tells me portage is up to date and there's nothing to do. What's with this?
- All the documentation seems to indicate that udev, unlike devfs, offers no mechanism to address a device as (for example) /dev/sd/c1b0t5u0p4 instead of /dev/sdd4. I hate and despise the /dev/sdx model; it's horribly broken, it's lame, and every time you insert a device, you have to figure out which other device identifiers are now going to point to different devices than they used to. (I am in fact totally gobsmacked that, by kernel 2.6.14, Linux still uses the /dev/sdx model at all, even for legacy support. I repeat and emphasize, it's HORRIBLY BROKEN and should be considered harmful.) Is there any means that the Gentoo installation handbook just isn't bothering to tell me about, by which I can tell udev to use fully specified device identifiers that I can safely rely on to always point to the same physical device?
Tags:
no subject
As for portage, no, my entire and only Gentoo environment right now is the chrooted one on the third disk I just installed, and I don't think it's ready to run on its own yet.
no subject
On a udev-only system such as my laptop, default rules map /dev/hda* to /dev/ide/host0/bus0/target0/lun0/part* as well as /dev/discs/disc0/part* which duplicates the order-dependent behavior of devfs.
My custom rules are for identifying devices uniquely using serial numbers, which is critical for USB devices.
no subject
Here's my point: If I have a single controller with a fixed SCSI disk at id 0 and, say, an Iomega Jaz drive at id 6, the fixed disk is /dev/sda and the Jaz is /dev/sdb, using the /dev/sdx model. But now if I add a second fixed disk at id 1, suddenly IT is /dev/sdb and my Jaz just became /dev/sdc. This behavior is broken.
On the other hand, if I'm addressing that Jaz as /dev/sd/c0b0t6u0, I can add or remove as many devices as I like on that controller, and the Jaz will always remain /dev/scsi/c0b0t6u0 (or, if I prefer, /dev/scsi/host0/bus0/target6/lun0/). The only time I'm going to have to change device nodes is if I add an additional controller that starts up before one or more controllers of the same type (IDE, SCSI, FCAL etc) I'm already using.
no subject
Anyway, udev should do what you desire automatically from its default rules, populating a path like /dev/scsi/host0/etc. If it doesn't, something is broken: buggy rules, or a quirk in the device registration of the SCSI driver that leaves empty hostX trees as you add/remove driver modules and/or devices.
I haven't bothered with it since I identify all my devices uniquely and give them unique names with custom udev rules.