Attn: robbat2, not bbullock, sorry -- Gentoo questions

[unixronin]

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?

Comments

[smandal.livejournal.com]

Quick, sleep-deprived diagnostic responses from a fellow Gentooer:

* I don't know -- I don't use Perl for anything. Your problem sounds icky; you may want to dig into the Perl ebuild to see how it handles these flags.

* Because you're chrooted? The running portage is out-of-date, but the one emerged on your non-root disk is current?

* Yes. I have device-specific udev rules that produce pointers like /dev/backup and /dev/scanner, as well as hotplug rules to set sysctl perms upon the driver registering a new device. I can email you my rules if you want, and there are howtos on Gentoo Wiki (gentoo-wiki.com).

In general, the Gentoo forums are awesome for questions like these; my handle is "Hypnos".

[unixronin.livejournal.com]

No, I don't want /dev/backup and /dev/scanner. My point is I want to be able to reference controller, bus, target, LUN, partition in the device node, and have that always point to the same partition on the same physical device regardless of whether I've inserted additional disks or other devices since I last rebooted. devfs Just Does It.

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.

[smandal.livejournal.com]

Perhaps I don't understand devfs, but it only does what you say if you haven't changed the order or cards and devices on your buses. Or, perhaps that's what you want for RAID or what have you.

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.

[unixronin.livejournal.com]

Well, I slightly overstated, I suppose. If you move devices around at whim, you're going to have problems unless you use partition names as tww1fa suggested.

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.

[smandal.livejournal.com]

I wouldn't call the behavior broken -- it's just an ordered representation of the devices you have on your bus. Unless, you're expecting memory of what was hooked up when!

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.

[tww1fa]

For the perl stuff you may need to create your own ebuild. Set PORTDIR_OVERLAY=/usr/local/portage in your make.conf, mkdir -p /usr/local/portage/dev-lang/perl, cp -r /usr/portage/dev-lang/perl/* /usr/local/portage/dev-lang/perl, then edit the .ebuild in /usr/local/portage for the version you want to use (5.8.6-r8 seems to be the latest,) then run "ebuild perl-5.8.6-r8.ebuild digest" to rebuild the digest, and emerge again.

For the portage stuff, make sure you've run etc-update or dispatch-conf after the portage update - otherwise it may not be able to detect you're using the new portage.

You can tell udev to use devfs type names - in fact in /etc/udev/scripts there are scripts you can call from your rules file to do just that. You'll have to update your udev rules to use those scripts, however the default rules already provide fixed names for your disks - take a look at /dev/disk/by-* which are populated by symlinks pointing to the canonical device names. Personally, I mount by partition label so the naming scheme doesn't affect me except when I'm partitioning.

[unixronin.livejournal.com]

Maybe I'm just not going to be able to get all of this working until I can boot from it. Getting it bootable without some of this stuff working may be entertaining. :p

[midiamin.livejournal.com]

To clarify, the reason you may have to create your own ebuild is because use64bitint and uselongdouble are not known to the portage tree. Reading from /usr/portage/dev-lang/perl/perl-5.8.6-r7.ebuild:

IUSE="berkdb debug doc gdbm ithreads perlsuid build minimal"

Since your extra flags aren't known to the perl ebuild, it ignores them and won't pass appropriate flags to configure. Naturally, maintaining your own perl ebuild could be a pita as time goes by, so you might lobby the maintainers for a new use flag or other workaround. Until then, don't forget to pin perl to the version you have a custom ebuild for lest the system try to replace it with a non-hacked version when a newer version becomes available.

And I second what he says about udev rules.

[robbat2.livejournal.com]

Welcome to Gentoo - your friendly Gentoo dev.
1. What errors are you seeing trying ithreads with perl?
2. Run plain 'emerge -pv portage' and see what version it brings in. There was a cosmetic bug in the past where it repeatedly claimed it needed an upgrade until you just upgraded with the -u.
3. Look in /dev/disk, but that isn't ideal depending on when udev starts (stupid hotplug events being lost).
For your devfs naming, see /etc/udev/scripts/scsi-devfs.sh. Put the 4 comments lines with BUS=scsi into /etc/udev/rules.d/99-scsi.rules, and then udev will create the devfs style symlinks.

[tww1fa]

Look in /dev/disk, but that isn't ideal depending on when udev starts (stupid hotplug events being lost).

That's what coldplug is for - if I run coldplug at boot the device nodes are created just fine.

[robbat2.livejournal.com]

nope. It doesn't generate the missing symlinks for my boot RAID at all here.
(3ware 8xxx card, driver compiled into the kernel, shows up only as /dev/sd*).

[unixronin.livejournal.com]

I'll have to remember to look up coldplug later.

[unixronin.livejournal.com]

Oh, I guess my memory was at fault ... I was thinking it was bbullock who was the gentoo dev, not you.

Perl -- building with ithreads works fine, I just can't get it to also enable use64bitint and uselongdouble. midi pointed out that this is because the ebuild does not recognize those options, and that I should bug a developer to get them included. (Saaaaaaayyyyyyyy.....!) :)

Portage:

babylon5 / # emerge -pv portage

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild R ] sys-apps/portage-2.0.51.22-r3 -build (-selinux) 0 kB

Total size of downloads: 0 kB
babylon5 / # emerge -u portage
Calculating dependencies ...done!
>>> Auto-cleaning packages ...

>>> No outdated packages were found on your system.

* GNU info directory index is up-to-date.

And thanks for the devfs/udev info; done. :)

[robbat2.livejournal.com]

I don't see the portage error you mentioned about it wanting .51.22-r3 repeatedly.
My perl builds with use64bitint, but not uselongdouble. File a feature request in the bugzilla, and I'll bug our perl mongers about it.
The perl build system isn't something I've hacked at before.

[unixronin.livejournal.com]

Well, if after doing both of those, I emerge -eav dcron syslog-ng xfsprogs jfsutils slocate:

babylon5 / # emerge -eav dcron syslog-ng xfsprogs jfsutils slocate

These are the packages that I would merge, in order:

Calculating dependencies ...done!
...
...
[ebuild N ] sys-apps/sandbox-1.2.12 0 kB
[ebuild N ] sys-apps/portage-2.0.51.22-r3 -build (-selinux) 0 kB
*** Please update portage to the above version before proceeding.
Failure to do so may result in failed or improper merges.
A simple 'emerge -u portage' is sufficient.
...
...


Every time I try to emerge ANYTHING, it tells me to update portage first, as above. So I try to update it, just lke it told me, and it says there's nothing to be done.

[robbat2.livejournal.com]

Your error is this: "emerge -eav"
-e tells portage to treat your system as empty and re-merge everything.
So the above output is correct given that -e was specified.

[unixronin.livejournal.com]

AHA! I overgeneralized from tww1fa's instructions to me on pre-installing gcc-3.4.4, and somehow failed to catch my error when I read the man page. Thanks!

Er, sorry, take 2

[unixronin.livejournal.com]

I just found an ebuild error. The gnumeric emerge (not gentoolkit) pulls in libmpeg3, and libmpeg3 requires nasm to build, but does not have nasm listed as a dependency. Therefore on a new system that does not yet have nasm, installing gnumeric will fail.

Re: Er, sorry, take 2

[robbat2.livejournal.com]

*points to bugzilla*