Re: [gentoo-user] Problem building statically linked e2fsprogs
Albert Hopkins wrote: On Wed, 2008-09-24 at 22:34 +0200, Maarten wrote: Albert Hopkins wrote: # ldd e2fsck/e2fsck linux-gate.so.1 = (0xb8033000) libc.so.6 = /lib/libc.so.6 (0xb7edb000) /lib/ld-linux.so.2 (0xb8034000) Ehm, exactly. So yes, it uses less libraries than before, but in no way is this a real statically linked binary: This is true, but it is sufficiently static enough. Pretty much any Linux shipped within the past 10 years or so has GNU libc 2 .x (libc 6), so the dependencies are satisfied. Ah ? Are there no major difference between recent glibc versions ? I did not know that versions are so much compatible. If you really really need static then: No, it worked. However, the com_err library gave us no end of grief today. Mount was broken, fetchmail was broken, etc. And reemerging com_err yielded no results, the error libcom_err.so.2: cannot handle TLS data persisted like a real plague. I finally fixed it, but am unsure how. I think reemerging an ancient version together with ss in the exact same version did the trick. But something is badly broken-- com_err insists on running revdep-rebuild, but running that does NOT report problems related to any of the problematic binaries... :-( As witnessed by, for instance, this: master sys-libs # mkfs.ext2 --help mkfs.ext2: error while loading shared libraries: libuuid.so.1: cannot handle TLS data master sys-libs # revdep-rebuild --pretend --ignore Checking reverse dependencies... snip Checking dynamic linking consistency... broken /usr/lib/apache2-extramodules/libphp4.so (requires libpdf.so.2) broken /usr/X11R6/lib/apache2-extramodules/libphp4.so (requires libpdf.so.2) broken /opt/blackdown-jre-1.4.2.01/lib/i386/libjsoundalsa.so (requires libasound.so.2) broken /opt/blackdown-jdk-1.4.2.03/jre/lib/i386/libjsoundalsa.so (requires libasound.so.2) done. snip All prepared. Starting rebuild... emerge --oneshot --nodeps --pretend --ignore =dev-java/blackdown-jdk-1.4.2.03-r12 =dev-java/blackdown-jre-1.4.2.01-r1 =dev-php/mod_php-4.3.10 In other words, no sign at all about this broken stuff. Same goes for fetchmail, but that has been reemerged so I cannot reproduce it anymore. All in all, it has been a VERY BAD week for Gentoo from my perspective. Which is a shame really, because I _want_ to love Gentoo... But... :-( Another very bad thing which really bites us with our older Gentoo servers is the fact that having the CHOST set to *i386-* seems to harshly break any hope of a viable upgrade path. Figure that-- the main reason we chose Gentoo was, in fact, the possibility to seamlessly upgrade and thus stay up to date forever. That CHOST has killed that hope. Now IF someone back in 2004 had mentioned (or had known?) this fact we would not have fallen in this trap. But now, our management is pushing real hard to switch to redhat or some other 'terrible choice'. I really really get angry and disappointed whenever I think about this situation nad how trivially simple it could have been avoided... :-( I even think that the com_err thingy has some relations to this. Because 'emerge world' has been effectively cut off for us, many many upgrades can be done only halfway, and these library problems indirectly stem from that. If someone knows a solution to the CHOST=i386 problem that doesn't involve an 'emerge --emptytree world', I would LOVE to hear it...! Thanks, Maarten
[gentoo-user] Problem building statically linked e2fsprogs
Hi List,
I'm in a bit of trouble. A server or ours has a broken e2fsck because it
is linked to a library version that doesn't exist anymore. Yes, I should
have fixed this before-- but alas, I obviously didn't... :-(
Tonight, the server had a hard crash and the only way to get it up again
(no IT people at the location) was by talking someone through a process
wherein I replaced e2fsck by /bin/true so it would not complain at boot
(where it would remain in an inaccesible state, with a panic shell).
So it is up and running again. All /seems/ fine, for now at least...
However, we must certainly assume the disk is in a dirty state so I
really do not want to do more than the bare minimum to it. So emerging
isn't a real good idea. Even then, I still tried. But it seems that
-despite the state of the bug(s) about e2fsprogs which are in
{resolved,fixed} state I cannot get e2fsprogs to compile AT ALL.
I've tried 10 different versions, etc., etc. To no avail. (Error below)
I believe looking at google and forum entries e2fsprogs on gentoo has a
*terrible* track record of late by the way, but maybe that is just me.
Things get more complicated fast, because this server has a CHOST i386
therefore -unless someone tells me otherwise- I cannot update glibc, and
practise has taught us to not upgrade packages/libs left and right
because you invariably end up, at revdep-rebuild time, with dependencies
which are unsolvable unless And it is the unless (meaning emerge
-e world) which is unacceptable for this (or any production-) server...
It crashes on the ../../lib/libuuid.so: undefined reference to
`___tls_get_addr'. The two bugzilla entries that apply basically tell
me to rebuild from scratch, which I cannot do for reasons outlined
above. (http://bugs.gentoo.org/204102 http://bugs.gentoo.org/232743)
-in short-
So as to avoid any further messing with the box I opted for building a
statically linked e2fsck binary on another box and copy it. However, I'm
having no luck with that. I can build static binaries fine for other
packages, but e2fsprogs refuses to build a static version.
(It builds, but the result is still dynamically linked)
Can anyone help with this ? Does this package not support building
static ? The USE flag is there for a reason, no? Did I take the wrong
approach here ? What is up with this [damn] package ?!?
# Grep works fine...
[EMAIL PROTECTED] ~ $ ldd /bin/grep
linux-gate.so.1 = (0xe000)
libc.so.6 = /lib/libc.so.6 (0xb7e42000)
/lib/ld-linux.so.2 (0xb7f96000)
thoughtpad ~ # USE=static emerge -v grep
[snip]
[EMAIL PROTECTED] ~ $ ldd /bin/grep
not a dynamic executable
# But e2fsprogs doesn't...
[EMAIL PROTECTED] ~ $ ldd /sbin/e2fsck
linux-gate.so.1 = (0xe000)
libext2fs.so.2 = /lib/libext2fs.so.2 (0xb7ea1000)
libcom_err.so.2 = /lib/libcom_err.so.2 (0xb7e9d000)
libblkid.so.1 = /lib/libblkid.so.1 (0xb7e93000)
libuuid.so.1 = /lib/libuuid.so.1 (0xb7e8e000)
libe2p.so.2 = /lib/libe2p.so.2 (0xb7e87000)
libc.so.6 = /lib/libc.so.6 (0xb7d55000)
/lib/ld-linux.so.2 (0xb7ee8000)
thoughtpad ~ # USE=static emerge -v e2fsprogs
[ebuild R ] sys-fs/e2fsprogs-1.40.9 USE=nls static* 0 kB
[snip]
Enabling ELF shared libraries
[snip]
checking whether linker accepts -static... yes
[snip]
Completed installing e2fsprogs-1.40.9 into
/var/tmp/portage/sys-fs/e2fsprogs-1.40.9/image/
# After that, no change, however...
[EMAIL PROTECTED] ~ $ ldd /sbin/e2fsck
linux-gate.so.1 = (0xe000)
libext2fs.so.2 = /lib/libext2fs.so.2 (0xb7f7f000)
libcom_err.so.2 = /lib/libcom_err.so.2 (0xb7f7b000)
libblkid.so.1 = /lib/libblkid.so.1 (0xb7f71000)
libuuid.so.1 = /lib/libuuid.so.1 (0xb7f6c000)
libe2p.so.2 = /lib/libe2p.so.2 (0xb7f65000)
libc.so.6 = /lib/libc.so.6 (0xb7e33000)
/lib/ld-linux.so.2 (0xb7fc6000)
[EMAIL PROTECTED] ~ $ ls -la /sbin/e2fsck
-rwxr-xr-x 1 root root 159896 Sep 24 21:17 /sbin/e2fsck
[EMAIL PROTECTED] ~ $ file /sbin/e2fsck
/sbin/e2fsck: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linux 2.6.9, dynamically linked (uses shared libs), stripped
Thanks in advance for any insights...
Maarten
Re: [gentoo-user] Problem building statically linked e2fsprogs
Albert Hopkins wrote: On Wed, 2008-09-24 at 21:39 +0200, Maarten wrote: Hi List, [...] # Grep works fine... [EMAIL PROTECTED] ~ $ ldd /bin/grep linux-gate.so.1 = (0xe000) libc.so.6 = /lib/libc.so.6 (0xb7e42000) /lib/ld-linux.so.2 (0xb7f96000) thoughtpad ~ # USE=static emerge -v grep [snip] [EMAIL PROTECTED] ~ $ ldd /bin/grep not a dynamic executable # But e2fsprogs doesn't... [EMAIL PROTECTED] ~ $ ldd /sbin/e2fsck linux-gate.so.1 = (0xe000) libext2fs.so.2 = /lib/libext2fs.so.2 (0xb7ea1000) libcom_err.so.2 = /lib/libcom_err.so.2 (0xb7e9d000) libblkid.so.1 = /lib/libblkid.so.1 (0xb7e93000) libuuid.so.1 = /lib/libuuid.so.1 (0xb7e8e000) libe2p.so.2 = /lib/libe2p.so.2 (0xb7e87000) libc.so.6 = /lib/libc.so.6 (0xb7d55000) /lib/ld-linux.so.2 (0xb7ee8000) thoughtpad ~ # USE=static emerge -v e2fsprogs [ebuild R ] sys-fs/e2fsprogs-1.40.9 USE=nls static* 0 kB [snip] Enabling ELF shared libraries [snip] checking whether linker accepts -static... yes [snip] Completed installing e2fsprogs-1.40.9 into /var/tmp/portage/sys-fs/e2fsprogs-1.40.9/image/ # After that, no change, however... [EMAIL PROTECTED] ~ $ ldd /sbin/e2fsck linux-gate.so.1 = (0xe000) libext2fs.so.2 = /lib/libext2fs.so.2 (0xb7f7f000) libcom_err.so.2 = /lib/libcom_err.so.2 (0xb7f7b000) libblkid.so.1 = /lib/libblkid.so.1 (0xb7f71000) libuuid.so.1 = /lib/libuuid.so.1 (0xb7f6c000) libe2p.so.2 = /lib/libe2p.so.2 (0xb7f65000) libc.so.6 = /lib/libc.so.6 (0xb7e33000) /lib/ld-linux.so.2 (0xb7fc6000) The grep package has a static USE flag. e2fsprogs does not. So enabling the static USE flag has no effect on e2fsprogs. Ehm, how do you figure that? It surely displays the static USE flag: thoughtpad ~ # emerge -pv e2fsprogs These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-fs/e2fsprogs-1.40.9 USE=nls -static 0 kB So I would assume at this point the package is broken in this respect. The easiest (easier?) thing to do would be to compile e2fsprogs statically by hand and copy over the resulting binary Good idea... well, maybe... # tar zxvf /path/to/e2fsprogs-1.x.x.tar.gz # cd e2fsprogs-1.x.x # ./configure --enable-static # make # ldd e2fsck/e2fsck linux-gate.so.1 = (0xb8033000) libc.so.6 = /lib/libc.so.6 (0xb7edb000) /lib/ld-linux.so.2 (0xb8034000) Ehm, exactly. So yes, it uses less libraries than before, but in no way is this a real statically linked binary: # ldd e2fsck/e2fsck linux-gate.so.1 = (0xe000) libc.so.6 = /lib/libc.so.6 (0xb7e32000) /lib/ld-linux.so.2 (0xb7f86000) # file e2fsck/e2fsck e2fsck/e2fsck: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped However, since this might still perform much better, I tested it... and indeed, it does the job (despite different glibc versions between the build host and the bad server): broken_server ~ # /sbin/e2fsck e2fsck: error while loading shared libraries: libcom_err.so.2: cannot handle TLS data broken_server ~ # ./e2fsck Usage: ./e2fsck [-panyrcdfvstDFSV] [-b superblock] [-B blocksize] [-I inode_buffer_blocks] [-P process_inode_size] [-l|-L bad_blocks_file] [-C fd] [-j external_journal] [-E extended-options] device Thank you, Maarten
Re: [gentoo-user] Problem building statically linked e2fsprogs
Daniel Pielmeier wrote: Maarten schrieb am 24.09.2008 21:39: Can anyone help with this ? Does this package not support building static ? The USE flag is there for a reason, no? Did I take the wrong approach here ? What is up with this [damn] package ?!? http://bugs.gentoo.org/show_bug.cgi?id=232115 gives some information about this issue. Ah, that explains it. Still, not too nice a fix they did on this. Instead of really addressing the issue, simply dropped USE=static. (But what do I know, maybe it's truely quite complicated) Anyway, I'll shut up before my frustration of today airs too much. :-) Regards, Maarten
[gentoo-user] 2006.0 installer quits during partitioning stage (CCISS?)
When attempting an install on an HP DL360 with a CCISS SCSI controller the installer quits when attempting the partitioning with the message: The setup program seems to have failed No other info is given. I then tried several things to circumvent it, first I partitioned the disk with fdisk prior to starting the installer (which doesn't help) and secondly I made symlinks from the /dev/cciss/c0d0* devices to their /dev/sda* counterparts, which didn't help either. I'm willing to do the install manually, but the 2006 manual sadly does not suggest an alternative to using the installer. What now? TIA Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] /usr as noexec? (was GB for / partition flamewar)
Ryan Tandy wrote:
Maarten wrote:
Or else, if /usr can be mounted
noexec without trouble, I'll donate 75 bogomips to the FSF.
Can we get that in writing, with a signature, creative use of {sym,hard}
links and nested mounts notwithstanding? ;)
Certainly ;-)
Oh well, it only amounts to 23 days of my Athlons' undivided attention.
I'll live. ;-)
Where trouble is defined as a system that won't run (relatively)
smoothly, rather than the amount of effort required to get it in that
state...
Hehehe. Obviously, yes.
LOL
Maarten
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] /usr as noexec? (was GB for / partition flamewar)
Uwe Thiem wrote: On 18 February 2006 15:05, Maarten wrote: Ryan Tandy wrote: Maarten wrote: Oh well, it only amounts to 23 days of my Athlons' undivided attention. I'll live. ;-) 23 days conpressed into one second. That will be the hard part. ;-) Well, maybe. Depending on your definition of MIPS. :-) And Bogomi sounded kinda weird, you know. But anyway. No, the real hard (or funny, depending on your viewpoint) part is watching those engineers try to execute a single calculation, on their 7500 billion bogomips system-with-usr-mounted-noexec... ;-) Back to the thread... I started wondering about something. I thought a 100% full root filesystem was deadly, but never thought about /tmp. So I'd like to ask, what is more deadly for a system, a full root FS, a full /tmp or a full /var ? Why ? And as a bonus question: which one is worse during boot, and which one is worse on a fully booted and running system ? Maarten Uwe -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] How many GB for / partition?
Okay, can we stop with the flamefest, already ? Comments below... Alexander Skwar wrote: Hemmann, Volker Armin wrote: On Thursday 16 February 2006 20:40, Alexander Skwar wrote: Hemmann, Volker Armin wrote: On Thursday 16 February 2006 17:18, Alexander Skwar wrote: Hemmann, Volker Armin wrote: On Thursday 16 February 2006 15:45, Alexander Skwar wrote: Wrong again. If tmp is the only place somebody can write, then it might save you (and it DID save my ass more than once now). since /tmp is not the only place where someone can write (/var/tmp anyone?) Several more indeed. Find comes to the rescue: 120870 drwxrwxrwt 2 root root 40 Jan 10 22:40 /dev/shm 2527440 drwxrwxrwt 2 root root 72 Apr 20 2005 /var/spool/samba Yes, I CAN make files there, as a regular user. if he has enough rights, that you have to worry about rw /usr, he has enough rights, to circumvent ro mounting by remounting. No, that is also not true. Just to satisfy everyone's curiosity, look at what find comes up with: 12100210 drwxrwxr-x 2 lp lp416 Aug 26 16:44 /usr/share/foo2zjs/crd 128775 21 drwxrwsr-x 4 root portage 21968 Feb 8 10:58 /usr/portage/distfiles And I'm _only_ looking at directories now, not even files... yes really, you have to remount /usr everytime you update something. Jaja. You know, your exaggerations become boring... Well, no. It is correct. How do you expect to install something when /usr is mounted RO ? snipped the rest of the ''argument''... Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] /usr as noexec? (was GB for / partition flamewar)
Eric Bliss wrote: On Friday 17 February 2006 14:36, Rumen Yotov wrote: Hi, Please don't take this post as a signal for more battles. IMHO there are many true facts from both of you. Just a few point, as i have some (limited experience with hardened systems). 1.For 2-3 years using portage-tree in /var/portage, no problems so far, all it takes is a symlink in /usr change in /etc/make.conf file. So i can mount all /usr as 'noexec'. Forgive me for asking, but how is this possible??? The last time I checked (which was 2 minutes ago...), /usr is where almost all the executables on my system are - /usr/bin, /usr/kde/3.x, /usr/libexec, /usr/sbin... It is, therefore, logically not possible. I believe, in all the mess that this thread has developed into, that Rumen simply confused 'noexec' with 'ro'. Shit happens... :-) This must be the explanation for sure. Or else, if /usr can be mounted noexec without trouble, I'll donate 75 bogomips to the FSF. Maarten P.S.: The thread this derived from has to be the most lame discussion I have witnessed in ages, and I've seen a few. First and foremost because neither of you took the simple effort to run two trivial 'find' commands to try and prove the other guy wrong. It is a shame, because at first, you both said some things that were 'insightful'[tm]... Most people would try to strengthen their positions by coming up with some proof, some good arguments, but that is SO totally absent here... No proof, nor examples, nor whatsoever... All you two did manage to say was really just an endless loop of-- Wrong Not wrong, right. No, you're wrong I'm right, you are wrong You are a thousand times wrong No, it is you who are infinitely wrong You are wrong infinitely plus one I am right, have always been right, and you suck No YOU suck I may suck but that is because you know I'm right You suck AND you are wrong I do not suck. YOU suck! Do NOT! Do TOO! No you suck. And you are wrong... Now what age-group type conversation does that remind you of...? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: File system full issues
James wrote:
Mark Knecht markknecht at gmail.com writes:
OK, good info - but what can I remove? Or more important how can I
find what's talking up too much space. /home, /usr/portage and /var
are on partitions of their own. There is about 200MB of Java stuff in
/opt and I deleted everything in /tmp before I wrote the first note.
The first question to ask is Did it fill up slowly or has it filled up
fairly quickly? If it was quick, chances are a runaway process did
something, like write a big coredump, a log which filled up due to
errors, a file copy that didn't fit, stuff like that.
Now you mention that the most likely point for that trouble are
accounted for (/tmp, /var). You also mention you use MythTV over the
network. So I would look at the (NFS?) mountpoint first; it happened to
me that the share wasn't mounted, and mythtv then happily fills up the
partition on which the mountpoint resides, ie. /.
So run a 'du -s' on /mnt/* (if that is your mountpoint) after unmounting
all network shares (a mounted dir can hide a file!).
Next, run du -s on the files and dirs in /root/. Maybe logging or cache
was written there (don't forget the dot-entries!)
Also, look into /usr/src and remove sources you can miss.
If nothing helps there, you best run a 'du -s /*' but you better umount
everything that isn't essential first. And even then, it's slw...
In the case it filled up slowly you are worse off. You then know you
have to remove stuff you may need instead of just finding 'the culprit'.
Look carefully into the entire tree and decide what you need and what
you can do without. Likely candidates are Howtos and such, but they
reside under /usr/share so it's likely they aren't on your / filesystem.
They are small, too, so you don't gain that much.
One you have space, you can gain much more by gzipping stuff (especially
mysqldumps, logs, etc) but as you stated /var is on it's own partition I
fear there will not be much to gzip anyway...
One last remark: It happened to me on occasion that a filesystem keeps
at 100% full until you reboot the box. It may be that a process still
has files open, or that an fsck is in order, or whatever. This is the
reason you should never let / fill up; it doesn't always recover very
gracefully, at least that has been my experience. I still have to guess
at the exact reason that stays-at-100% happens, if anyone can explain...
Good luck,
Maarten
Well the first thing you need to do, is run a 'df' and see which
partitions are full. Then used these tools to find files by size and
date. Let's assume we're talking about /usr/portage/distfiles
for example:
REMOVING LARGE FILES IN /usr/portage/distfiles
find ./ -size +10 -exec ls -lag {} \; | less lists large files
find ./ -size +10 -print -exec rm {} \; prints removes large files
You can then changethe size and work your way down.
Now let's look at old files in /usr/portage/disfiles
REMOVING OLD FILES IN /usr/protage/distfiles
find ./ -mtime +180 -exec ls -lag {} \; | less
find ./ -mtime +180 -print -exec rm {} \;
It really helps if you do this a the 90% point, and avoid
sluggish behavior.
Look at /home too. If you have one big partition, as recommended
in the handbook then removing any files will help.
/usr/src/* is another place to remove kernel sources, similarly,
/boot/
Be cautions!
hth,
James
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Problems with GRUB in the installation of Gentoo
Gilberto Martins wrote: What is OP ? _O_riginal _P_oster, I believe. Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] MythTV users - read before updating to 0.19
Mark Knecht wrote: Hi, I just wasted an hour so I thought maybe I could save someone else the problems. The new MythTV 0.19 rev that's out in portage doesn't work with an older mythbackend server running version 0.18. Apparently you have to update both ends at the same time. Of course portage is not smart enough to know the server is running elsewhere on the network and save me the problem so I'm dropping back to the 0.18 frontend on my desktop. This has, I think, always been the case. I once emerged a newer frontend, connected back to the server and it didn't work. Worse, by connecting it the frontend UPDATED the mysql tables, so the backend ceased functioning altogether (...!). A nice DoS. I wrote to the mythtv list regarding this behaviour (I called it a bug) but it was deemed neccessary ie. not a bug at all since some extensions in the frontend run standalone (like weather, etc.) so the frontend has to update the db. I was not satisfied with that answer, but what can you do... I has no other than updating the backend too, since there is no rollback possibility. The next MythTV update I do will have to be carefully planned, since I deploy one backend and 4 frontends... Maybe this behaviour has changed by now though, since from your post I gather your backend still works fine. Still, my strong advice is: always always backup the mysql db before attempting to connect ANY newer version MythTV frontend. I hope this saves someone else the time. Hear hear. Maarten Cheers, Mark -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Problems with GRUB in the installation of Gentoo
Gilberto Martins wrote: Most modern BIOS have the option to boot from a lot of devices, you can check if your BIOS have options to boot from hd1, or primary slave, whatever your BIOS call it, just enter the SETUP and check for it. Yeah, it is already configured to start the first Hard Disk. LILO won't help you, you're installing the boot loader in a slave disk, whatever you do, your BIOS will still call for the master (in most cases), check your grub config twice, change it for the slave drive (hd(1,0)?!) and change your BIOS to boot from the slave... I really haven't checked for it, but i did emerge lilo to have a try at lilo, anyway. After that, I emerge --unmerge grub it. Hope I haven't done something too wrong. Finally, I did: cd /usr/src/linux make install After that, I had the folowing /boot content: # cd /boot # file * System.map: symbolic link to `System.map-2.6.15-gentoo-r1' System.map-2.6.15-gentoo-r1: ASCII text System.map-2.6.15-gentoo-r1.old: ASCII text System.map.old: symbolic link to `System.map-2.6.15-gentoo-r1.old' boot:symbolic link to `.' boot.0340: x86 boot sector, code offset 0x48 config: symbolic link to `config-2.6.15-gentoo-r1' config-2.6.15-gentoo-r1: ASCII English text config-2.6.15-gentoo-r1.old: ASCII English text config-gentoo-2.6.12-gentoo-r10: ASCII English text config.old: symbolic link to `config-2.6.15-gentoo-r1.old' grub:directory kernel-gentoo-2.6.12-gentoo-r10: x86 boot sector lost+found: directory map: data vmlinuz: symbolic link to `vmlinuz-2.6.15-gentoo-r1' vmlinuz-2.6.15-gentoo-r1:x86 boot sector vmlinuz-2.6.15-gentoo-r1.old:x86 boot sector vmlinuz.old: symbolic link to `vmlinuz-2.6.15-gentoo-r1.old' Now, after rebooting, it really went straight, with text menu. It starts loading really fast the system,but all of a sudden, a Kernel Panic says: Warning - Unable to open an initial console Kernel panic - not suncing: No init found. Try passing init= option to kernel Which init= I should use ? the problem is the lack of a initrd file ? I tried to read mkinitrd man page, but I guess this does not apply. This is the lilo.conf. lba32 boot = /dev/hdb default=gentoo menu-scheme=Wb prompt delay = 50 vga = 791 image = /boot/vmlinuz root = /dev/hdb1 You're pointing the kernel to hdb1 as the system root partition. I bet money hdb1 isn't; it's /boot. So point it to the hdb[2|3|4|...] which is your main / partition, and all will be well. Maarten label = Gentoo read-only # read-only for checking I adapted it from sample file. I can see that : 1) there was something missin in grub conf file; 2) I need to study a little bit more ... 8( -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Problems with GRUB in the installation of Gentoo
Richard Fish wrote: Now, after rebooting, it really went straight, with text menu. It starts loading really fast the system,but all of a sudden, a Kernel Panic says: Warning - Unable to open an initial console Kernel panic - not suncing: No init found. Try passing init= option to kernel This message usually means you are missing /dev/console on your root filesystem. That warning, yes. But the error right after that means what it says: No init found, ie. it has mounted a filesystem (else you get another error-: Kernel panic - cannot mount root partition) but it is unable to find 'init' there. From that, one can deduce the OP probably pointed the kernel to the wrong root partition (ie. /boot, or /usr, etc.) Maarten Boot from the live CD, mount your root, and do: cp -a /dev/console /dev/null /dev/zero /mnt/gentoo/dev/ -Richard -- gentoo-user@gentoo.org mailing list
[gentoo-user] Handling of config updates, RFC
Hi I have not been impressed by the handling of configfiles (updating them) by neither etc-update nor dispatch-conf, so I pondered on an alternative. Not an alternative to those packages, but some extra help, possibly integrated into one of those tools. Please bear with me... What tickles me the most about the current process is that one sometimes gets huge lists of updated files by updating a single package. A package which may have never been used, or at least configured, by the user. For instance, updating webmin, or snort, yields many many ._cfg files an average user knows little about, and does not care about since he never tweaked them. In other words, they are in their distibution-default state, never edited. It stands to reason everyone would want all those files overwritten by the new ones, is it not ? Well, neither tool does that now. The user is left with two options to handle the task: 1) Pick out all non-trivial files in a massive list of over 150 files, merge those, and after due consideration have dispatch-conf do all the remaining files automatically. (I suspect this is what most people do) 2) Go through all the files step by step and choose either overwrite or skip as fast as possible, and re-run the tool on the remaining files, and this time carefully decide what to do with it, overwrite, shred, or merge. Well, neither is comfortable. Especially since 'trivial merges' like CVS- or revision info are advertized as being dealt with, but in reality are often not. I cannot tell you how many 'changes' I get confronted with are just trivial changes (like added commentary, and so on) I propose to add an additional mechanism to 'see' whether a file was actively changed during the lifetime of the machine, by a very simple and dumb means, but nevertheless a very effective one. This would work like this: upon extraction of the stage tarball (or at least very very early in the install process) one should set all the dates of all the potential configfiles to a set date in the (distant) past. Let's say, feb 29 1988. Only thereafter, we start configuring the system, editing fstab, hostname, etc. Now when we run dispatch-conf, it will first check the date of the file that corresponds with a ._cfg file. If that file has that magic date, overwrite it by the new file, and (this is important) re-set the date of that new file to that old magic date. The user thus needn't be bothered by numerous files he didn't touch, and a very significant time-saving is realized for everyone. If I'm not mistaken, other distributions have had solutions like this for ages. For instance, SuSE's YaST had/has a way to see if a user touched the configfile, and refuses to touch it if it found out the user had changed it manually. (Not a very succesful strategy for people who routinely did edit the files, but considering all that, it was still not bad. ...What do you think ? Has this idea been suggested before ? Wouldn't this make the updating a much less painful process ? What, if any, would be possible pitfalls using this approach ? Thank you for your time reading this, Maarten v d Berg -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Handling of config updates, RFC
Neil Bothwick wrote: On Sun, 12 Feb 2006 14:37:41 +0100, Maarten wrote: What tickles me the most about the current process is that one sometimes gets huge lists of updated files by updating a single package. A package which may have never been used, or at least configured, by the user. For instance, updating webmin, or snort, yields many many ._cfg files an average user knows little about, and does not care about since he never tweaked them. In other words, they are in their distibution-default state, never edited. It stands to reason everyone would want all those files overwritten by the new ones, is it not ? Not. What is the default settings change. You may not have edited the config because the old defaults were what you wanted, but the new defaults may break your system. Your old config file, with the settings you needed, has now gone to bit heaven and you are left with a broken system. Hum, I'll go along in that there _may_ be changes in the default behaviour that a user may not want, but tough luck; the opposite is far _more_ likely: that the new binary can't cope with the old config, and you then also are left with a broken system. Same difference... Is is also very possible that the new binary has different behaviour regardless of config. Emerging world can, and does, change things and I would suggest that if a user doesn't want any surprises he/she shouldn't run emerge world in the first place... But apart from that, I'd even dare suggest that, when emerging a package + its config file changes the default behaviour and that change is not unavoidable (by setting the right options in the new config) that that ebuild is plain broken. There is one exception to that, however: when the change is neccessary from a security standpoint. In that case I'd say it is _good_ that the old config with the insecure setting gets overwritten. Remember, the user _did_not_edit_ the file at any point, so there should be no expectancy of non-breakage by an update. If a user explicitly wants to keep the config, what is wrong with him running 'touch' on all configs he wants unchanged? And besides, I never suggested that my new procedure _shouldn't_ make backups of all configs it replaces, just like dispatch-conf can do. In my case, emerge world very often breaks things, no matter if I use the old or the new config. So saying this may break things in very rare occasions is a bit like saying while you're in the air falling down and both your parachutes fail to work, you also get the hiccups. ;-) Of course, Gentoo is all about choice, so if you want to take that change, you can set dispatch-conf to do what you want. If you say so... but it is non-obvious. Or if by that you mean I have to make a huge list of CONFIG_PROTECT_MASK files... well, that takes even more time than just running dispatch-conf and be done with it. What I'm looking for is a way to automate things a bit more. Defining a list of what may and what may not be overwritten can be quite tedious, and is by no means automatic. # Automerge files that the user hasn't modified # (yes or no) replace-unmodified=no I _have_ set that setting at yes of course, but it works nowhere near useful... even to the point that I figured the setting was broken, or was only a stub for future enhancement... That said, cfg-update sounds exactly like what I need, so... Regards, Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Handling of config updates, RFC
Rumen Yotov wrote: On Sun, 2006-02-12 at 14:37 +0100, Maarten wrote: Hi, Check cfg-update it's in portage, and i think it the better. i'm using it together with dispatch-conf but think if switching completely to 'cfg-update' (or mostly at least). Check the forums for additional info (features, history etc.) HTH.Rumen That sounds perfect. Thank you very much for the pointer ! Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Handling of config updates, RFC
Boyd Stephen Smith Jr. wrote: On Sunday 12 February 2006 07:37, Maarten [EMAIL PROTECTED] wrote about '[gentoo-user] Handling of config updates, RFC': What tickles me the most about the current process is that one sometimes gets huge lists of updated files by updating a single package. A package which may have never been used, or at least configured, by the user. For instance, updating webmin, or snort, yields many many ._cfg files an average user knows little about, and does not care about since he never tweaked them. In other words, they are in their distibution-default state, never edited. It stands to reason everyone would want all those files overwritten by the new ones, is it not ? Well, neither tool does that now. 1) The Gentoo Way says that gentoo shouldn't make that decision for you. Nah. I think The Gentoo Way translates to You can turn this behaviour ON or OFF at your discretion. I fail to see why yet another switch in the dispatch-conf.conf would do harm to the Gentoo Way, and neither what would be the drawbacks to shipping a stage tarball with all config dates set to a predefined past date which can serve as reference point... 2) Check out your /etc/dispatch-conf.conf; It has options to automatically perform a number of merges and even keep an RCS history of config files to ensure that it is easy to rollback in breaking changes. I tell dispatch-conf to automatically merge config files I haven't touched. I do too, but it still confronts me with 80+ files I have never touched. I'd say the tools provided with portage, plus cfg-update, as mentioned by the other poster, as more than capable for my use (actually, the only one I /ever/ use is dispatch-conf). Before trying to stir up development efforts on another method, please try and fully understand the tools gentoo provides. I'm not saying config file maintainence couldn't be improved in gentoo, but I think it's in a state that satisfied the majority of users and (more importantly) developers. It does help to tweak your CONFIG_PROTECT and CONFIG_PROTECT_MASK. Okay, I'll look into that, too. I understand the developers have better things to do than go on a wild goose chase, but I really think there is room for improvement in this area. Maybe most of you run nightly or weekly 'emerge world's (and thus can easily cope with the occasional 7 files needing merging), but we run a large number of servers, and therefore we only run emerge world a couple of times a year (at most). I can tell you from experience that emerge telling you there are 231 config files needing attention after such an update is _very_ discouraging. Especially since fixing that is only the beginning; after that you need to fix everything that broke (and boy do things break if you run an emerge after 6 months!). I'd mention udev, or apache, or gcc, but the list has plenty of examples... Not complaining; things break and such is life. But in the process, every step that is either tedious or time-consuming or unneccessary cuts into the time and effort needed for fixing stuff later on. And I think the current process of merging configs has all three of those aspects. But that's all IMHO, of course. regards, Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Problems with GRUB in the installation of Gentoo
Gilberto Martins wrote: livecd / # cat /boot/grub/grub.conf default 0 timeout 0 #splashimage=(hd0,0)/grub/splash.xpm.gz title Gentoo Linux 2.6.12.gentoo-r10 root (hd0,0) kernel /kernel-gentoo-2.6.12-gentoo-r10 root=/dev/hdb3 You say /dev/hdB, and above (hd0,0). Therefore implying that there is no /dev/hdA in the system. Is that correct ? If not, and you do have a hda device, the (hd0,0) is wrong and should probably be (hd1,0). But in that case your BIOS will probably boot from hda anyway so grub will never even be launched in the first place. What lives on hda, windows ? You can trivially check this by running 'grub' and, within grub, say 'root (hd0,0)'. It should then reply by saying Filesystem type is XXX where XXX is ext2 or ext3 or whatever you used. If it says something like FAT or yields an error (Selected disk does not exist | No such partition) you have the wrong mapping. Trying 'root (hd1,0)' will then be more successful probably. However, your BIOS would still boot hda in most cases, so you had better look into installing grub on /dev/hda (but without breaking whatever lives on hda) If you have no hda, or if hda is the CDrom, it may be prudent to change the cabling so that linux is on the /dev/hda device. Altough it is possible to boot from the slave drive, but it is more straightforward to boot from the master, and you may save yourself some headaches. Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Lost my coreutils
Benno Schulenberg wrote: Benno Schulenberg wrote: here's the output of 'equery files coreutils': Hmm... equery behaves different when its output is redirected. Here's a list without any of the duplicates (symlinks) in /usr/bin. /bin/link /bin/ln ^^^ Ehm. Which possibly creates a chicken-egg problem. How do you make the symlink from ln - busybox without having /bin/ln in the first place ? Maarten Benno -- gentoo-user@gentoo.org mailing list
[gentoo-user] Udevinfo or /sys/ problem in Gentoo
Hi I need to distinguish several, mostly identical, USB devices from each other by assigning them unique static names. I know there are primers(*) that describe the process, and I try to follow them, but either the gentoo /sys/ tree is broken in some way, or my system is broken, or the primers / howto's are incorrect... (*) http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html (*) http://www.reactivated.net/udevrules.php I'm really stuck with this, so by way of reference I tried another linux flavour, and there the whole /sys tree and udevinfo DO work as expected. So I need to find out what's wrong. The docs tell you to run 'udevinfo -a -p /sys/path'. But under gentoo, I cannot find the right path. This is what is listed under /sys/class/usb*: drwxr-xr-x2 root root 0 Feb 3 11:46 usb drwxr-xr-x6 root root 0 Feb 3 11:46 usb_host The usb directory is completely empty, the usb_host directory has four devices, being the hostcontrollers. But the attached devices are not listed anywhere. However, looking at another linux (Suse 10) I find three directories: drwxr-xr-x2 root root 0 Feb 2 16:27 usb drwxr-xr-x 13 root root 0 Feb 2 16:27 usb_device drwxr-xr-x4 root root 0 Feb 2 16:27 usb_host And indeed, under usb_device I find all my attached devices...! Under gentoo, I don't understand what should happen, and / or why it doesn't. The kernel finds the device: Feb 3 12:26:01 [kernel] usb 2-2: new full speed USB device using uhci_hcd and address 6 Feb 3 12:26:02 [kernel] pl2303 2-2:1.0: PL-2303 converter detected and the device gets registered under /dev and is useable: Gentoo # ls -la /dev/tts/ crw-rw 1 root tty 188, 0 Feb 3 12:26 USB0 But still, no /sys/ entry to be found! Not under usb, nor anywhere else. And this is not just that special USB device. I tried connecting mice, memory sticks, cardreaders, network interfaces, even hubs... nothing. Can someone please help me ? I've been wrestling with this issue for weeks now... :-( Thanks in advance, Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Udevinfo or /sys/ problem in Gentoo
Neil Bothwick wrote: On Fri, 03 Feb 2006 12:45:51 +0100, Maarten wrote: I need to distinguish several, mostly identical, USB devices from each other by assigning them unique static names. I know there are primers(*) that describe the process, and I try to follow them, but either the gentoo /sys/ tree is broken in some way, or my system is broken, or the primers / howto's are incorrect... (*) http://webpages.charter.net/decibelshelp/LinuxHelp_UDEVPrimer.html (*) http://www.reactivated.net/udevrules.php The latter one is written by a Gentoo dev, so I'm surprised you think it doesn't work with Gentoo I'm really stuck with this, so by way of reference I tried another linux flavour, and there the whole /sys tree and udevinfo DO work as expected. So I need to find out what's wrong. The docs tell you to run 'udevinfo -a -p /sys/path'. But under gentoo, I cannot find the right path. This is what is listed under /sys/class/usb*: Have you tried udevinfo -q path -n /dev/xxx to identify the correct path in /sys? Do you have CONFIG_SYSFS=y in your kernel config? Ok. I think found out what went wrong. Following the 'Everything is a file linux philosophy I ran udevinfo on the files under that directory. That gives the less than helpful error: couldn't get the class device Witness my history... :-( 686 udevinfo -a -p /sys/class/tty/ 689 udevinfo -a -p /sys/class/tty/ttyUSB0/dev 690 udevinfo -a -p /sys/class/tty/ttyUSB1/dev 698 udevinfo -a -p /sys/block/sda/dev 699 udevinfo -a -p /sys/class/nvidia/nvidia0/dev 700 udevinfo -a -p /sys/class/net/eth0/type 701 udevinfo -a -p /sys/class/sound/dsp/dev 702 udevinfo -a -p /sys/class/misc/rtc/dev 706 udevinfo -a -p /sys/class/usb/lp0/dev I think, for the sake of clarity, that the howto might have mentioned this explicitly. So one must not try to run it on the dev file but just on the underlying directory. Which is what the doc says, but it is not very intuitive to do so, and I have an itchy [TAB] key... Oh well. All is cleared up now. Sorry for bothering you. Maarten -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: Udevinfo or /sys/ problem in Gentoo
Michael Mauch wrote:
Maarten wrote:
All is cleared up now. Sorry for bothering you.
FWIW, you could also run udevinfo -d to see all your devices, and use
the left side of its output for udevinfo -a -p.
Wow, yes, that is a useful tip! Thanks!
I wonder why the -d switch is not documented neither in udevinfo -h
nor in the man page.
I fully concur.
Handling the /sys/ dir for the first time when you don't yet know your
way around it can be a daunting task anyway. Look at this little
example, which illustrates how incredibly picky udevinfo is about the
right pathname. Only the third form prints any useful info, the first
yields an error and the second one does give some little output, but
alas nothing useful. (It is awful that the simple fact of omitting a
trailing / makes that much of a difference):
server mnt # udevinfo -a -p /sys/class/tty/ttyUSB0/device
couldn't get the class device
server mnt # udevinfo -a -p /sys/class/tty/ttyUSB0/device/
looking at class device '/sys/class/tty/ttyUSB0/device':
KERNEL==device
SUBSYSTEM==tty
SYSFS{detach_state}==0
server mnt # udevinfo -a -p /sys/class/tty/ttyUSB0
device '/sys/class/tty/ttyUSB0' has major:minor 188:0
looking at class device '/sys/class/tty/ttyUSB0':
KERNEL==ttyUSB0
SUBSYSTEM==tty
SYSFS{dev}==188:0
follow the device-link to the physical device:
looking at the device chain at
'/sys/devices/pci:00/:00:1d.0/usb2/2-2/2-2:1.0/ttyUSB0':
BUS==usb-serial
ID==ttyUSB0
DRIVER==PL-2303
SYSFS{detach_state}==0
snip much more info
Maarten
--
gentoo-user@gentoo.org mailing list
