Re: strange hang on ultra5 boot in audioctl init script
On Fri, 12 Nov 2004 21:35:09, Joey Hess wrote: I've an ultra 5, and if I install unstable with the 2.6 kernel on it, it hangs during boot like this. I've added set -x to the script that seems to be hanging it: Initializing random number generator...done. Recovering nvi editor sessions... done. + test -x /usr/bin/audioctl + PARAMS= + DEVICE= + '[' -f /etc/default/audioctl ']' + . /etc/default/audioctl + case "$1" in + echo -n 'Setting audio parameters...' Setting audio parameter Yes, it really seems to hang midway through the echo. Except it's not really hung, the machine still responds to ping, just the console doesn't work. Strange huh? I tried removing /etc/rcS.d/S75audioctl, and the system then boots and works ok. After it's booted, I can run /etc/init.d/audioctl start with no problems. I've tried reinstalling, and reproduce the problem every time, though it's fine if I install a 2.4 kernel. I tried installing ssh and configuring it to start before audioctl during boot. I could log in via ssh, and was suprised to see that the init script no longer seems to be running, and no other init scripts are running either. This is a complete ps fax: PID TTY STAT TIME COMMAND 1 ?S 0:03 init boot 2 ?SN 0:00 [ksoftirqd/0] 3 ?S< 0:00 [events/0] 4 ?S< 0:00 \_ [khelper] 16 ?S< 0:00 \_ [kblockd/0] 27 ?S 0:00 \_ [pdflush] 28 ?S 0:00 \_ [pdflush] 30 ?S< 0:00 \_ [aio/0] 15 ?S 0:00 [powerd] 17 ?S 0:00 [khubd] 29 ?S 0:00 [kswapd0] 133 ?S 0:00 [kseriod] 206 ?S 0:00 [kjournald] 216 ?Ss 0:00 [init] 367 ?S 0:00 [kjournald] 368 ?S 0:00 [kjournald] 369 ?S 0:00 [kjournald] 370 ?S 0:00 [kjournald] 371 ?S 0:00 [kjournald] 795 ?Ss 0:00 dhclient -e -pf /var/run/dhclient.eth0.pid -lf /var/r 802 ?Ss 0:00 /usr/sbin/sshd 855 ?Ss 0:00 \_ sshd: [EMAIL PROTECTED]/0 858 pts/0Ss 0:00 \_ -bash 919 pts/0R+ 0:00 \_ ps fax I was not ale to strace init, so I don't know what it's doing. telinit does not seem to work. And that process 216 that is apparently a swapped out init child is very strange. Nothing interesting in dmesg, and of course syslogd is not running yet. One other interesting thing is that if I echo to /dev/console, it hangs. Here's another weird thing: If I turn on bootlogd, it doesn't hang. Serial console ? Sounds like something in the boot process is setting -clocal, or turns on hardware handshaking, and if you just have a simple 3-wire terminal RTS and DCD are low so I/O from/to the console device hangs - as usual, the computer does what you say, not what you want :) Also, I have seen something very similar with a 2.6 kernel on Intel machines - sometimes, not always, but sometimes, the boot process hangs as you describe because of a bug in the serial driver. If I press "enter" on the serial console a few times, interrupts are generated and the serial driver gets "unstuck" and booting continues ... I have not been able to reproduce it reliably, though, so I haven't reported this on linux-kernel yet. Mike.
Re: Bug#226986: sysvinit: no output on headless sparc64
On Fri, 09 Jan 2004 21:44:20, Magosányi Árpád wrote: > Package: sysvinit > Version: 2.85-9 > Severity: normal > > > This is a headless sparc64 system. > After init is executed, > there is nothing in the console; the last message is > about mounting the root filesystem readonly. > It seems that the system completely hangs. > Kernel command line: root=/dev/sda1 ro -p console=ttyS0 > It may be relevant that I see every kernel message twice > on the console (but once in dmesg) > after and including the following message: > Console: ttyS0 (SU) > > The workaround is to set > #define INITDEBUG 1 > in init.h , and recompile. > > I do not claim that I understand why this solution works, > but it does. > I am interested in figuring out what the actual problem is, > and find a solution to it. I need hypotheses to test and > questions asked well (or the answer, if you have it:). I bet if you turn off bootlogd in /etc/default/bootlogd (or upgrade to a more recent version of sysvinit/initscripts where this is the default) that the problem will disappear. Bootlogd doesn't work on all systems, that's why it has been turned off in newer versions for now. Mike.
Re: X rebuilds
In article <[EMAIL PROTECTED]>, Paul Slootman <[EMAIL PROTECTED]> wrote: >Is alpha.debian.nl a potato system? Yep. It has a chrooted slink installed as well I just noticed (no idea if it works though) >(And does it have enough space for >an X build?) Hmmm... % df Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda249568 25434 21574 54% / /dev/sda115296 1282 14014 8% /milo /dev/sda5 594733363055200959 64% /usr /dev/sda6 297379 52587229433 19% /var /dev/sda7 3013788 2567409290527 90% /extra Also, it's behind a link with not that much bandwidth and it will not be appreciated if you're going to up/download hundreds of megs Mike.
Re: nis 3.8-0.1 on axp
In article <[EMAIL PROTECTED]>, Richard B. Kreckel <[EMAIL PROTECTED]> wrote: >Is anybody else experiencing problems after upgrading to the latest NIS >security patch? I did upgrade on a bunch of i386 machines and it worked >fine. On an Alpha machine, however, it works only in broadcast-mode! No idea. Someone NMUd it for me without my consent. I haven't tested it. >PS: Miquel, what is the point in having bind_wait() in /etc/init.d/nis >print 10 dots and then a 'timed out' without cleaning anything up >afterwards? What needs to be cleaned up? >If it has 'timed out', people don't expect ypbind to >be around any more, do they? I think they do, as Solaris does something similar I heard >As it stands, the routine seems to >serve purely the cosmetic need of issuing a warning. Well, someone filed a bug against the NIS package.. The idea is that in 99% of the cases, a NIS server will respond within seconds. If it doesn't respond in 10 seconds, the NIS server is probably down. The code was just added to be (reasonably) sure that there is a binding to a NIS server after /etc/init.d/nis has been run Mike. -- Q: How many ears do Trekkies have? A: Three; the left ear, the right ear, and the final front ear.
Re: glibc 2.2 and gcc (Was Re: something completely different)
In article >[EMAIL PROTECTED]>, Jason Gunthorpe <[EMAIL PROTECTED]> wrote: >On 3 Aug 2000, Miquel van Smoorenburg wrote: >> Can't you simply add a dummy package called lib6.1 that Depends: or >> probably even Predepends: on libc6. > >Well, you can change the package name, but you must not change the soname >or you are going to break binary comaptiblity with every other alpha dist You're right. I must have left on the lenscap of my mind again. Mike. -- Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.
Re: glibc 2.2 and gcc (Was Re: something completely different)
In article >[EMAIL PROTECTED]>, Christopher C. Chimelis <[EMAIL PROTECTED]> wrote: >Hmmm...well, changing Alpha's libc package name would involve the same >situation as if we all changed to libc6.2, at least on alpha. We'd have >to conflict/replace AND provide libc6.1 (to cope with older packages >and/or non-Debian-offered packages, such as the compilers that I helped to >package for Compaq). Can't you simply add a dummy package called lib6.1 that Depends: or probably even Predepends: on libc6. It will take a few releases before you can get rid of it but it would get the Alpha back in line with the other archs. And there's not ever going to be a real libc6.1 anyway. Mike. -- Cistron Certified Internetwork Expert #1. Think free speech; drink free beer.
Re: upgrade troubles with nis
In article <[EMAIL PROTECTED]>, George A. Dowding <[EMAIL PROTECTED]> wrote: >Greetings, > >I have done two slink->potato upgrades. For the most part the went >fairly smooth (aside from the unalignment problem). The server that >is set up as a shell box has had no problems with nis. However on the >machine I use for more administrative purposes (bind, dhcp, samba, >etc.) I cannot get nis to work. > >Here is the message I get in /var/log/daemon.log > >ayes ypbind[31584]: (unable to register YPBINDPROG YPBINDVERS, udp) >ayes icmplogd: destination unreachable from localhost [127.0.0.1] It means the portmapper is not running (/sbin/portmap). It is part of the "netbase" package. Mike. -- "quote me on this one - overgaan op Exchange is een wijs besluit" -- MarcoH. -- The From: and Reply-To: addresses are internal news2mail gateway addresses. Reply to the list or to [EMAIL PROTECTED] (Miquel van Smoorenburg)
Re: trouble with NIS in slink update
In article <[EMAIL PROTECTED]>, Ferenc Kiraly <[EMAIL PROTECTED]> wrote: >OK, I guess I'm ruling out the kernel problem. I upgraded from >kernel 2.0.38 to 2.2.14pre16 as you suggested and it made >absolutely no difference to NIS. The above mentioned progs >segfault just as happily as ever. So the problem remains. >Anything else I can try? Yes, debug it on the source level .. Recompile NIS with debugging (-g) on, and run the unstripped binaries under a debugger (gdb). Then when it coredumps you can do a stack-trace to see where it goes wrong. Until someone who can reproduce this debugs it this way, it's not going to be fixed .. Mike. -- The From: and Reply-To: addresses are internal news2mail gateway addresses. Reply to the list or to [EMAIL PROTECTED] (Miquel van Smoorenburg)
Re: trouble with NIS in slink update
According to George A. Dowding: > If you have copies of those suggestions I would like to see them. I > am running on alpha and NIS is extreemly important to my system. See the bug tracking system http://www.debian.org/Bugs/ Enter "nis" as package name. Mike.
Re: trouble with NIS in slink update
According to [EMAIL PROTECTED]: > I think there is a confusion here. I am speaking about the sparc > architecture (and the testing machine is an old Sun IPC running potato > with the lastest kernel, in case this is relevant). Nothing to do with > the Alphas. Okay, I'm reading this on the debian-alpha list though ... perhaps someone should remove the Cc: to debian-alpha then. Mike.
Re: trouble with NIS in slink update
According to [EMAIL PROTECTED]: > I have potato (sparc) and nis doesn't work either. Before that I have > slink and nis never work for me. I have written to this list about > the problem, but nis never got fixed. I have responded to all bugreports that were filed. Fact is: - My machine is not an Alpha, I develop on x86 - The Alphas I do have access to run the Alpha NIS package without any problems, so I cannot reproduce the problem at all - I have done several suggestions to people who have this problem but noone replied. Mike (nis maintainer).
Re: [potato] rdate problem
In article <[EMAIL PROTECTED]>, Ron Farrer <[EMAIL PROTECTED]> wrote: >What is wrong with '# rdate tock.usno.navy.mil'?? It always >gives an error: "rdate: Could not read data: No such file or directory" >or "rdate: Could not connect socket: Connection timed out". It simply means that the 'time' service that rdate tries to connect to is not running (or firewalled off) on tock.usno.navy.mil, or that the entire system is unreachable. Mike. -- The From: and Reply-To: addresses are internal news2mail gateway addresses. Reply to the list or to [EMAIL PROTECTED] (Miquel van Smoorenburg)
Re: trouble with NIS in slink update
In article <[EMAIL PROTECTED]>, Ferenc Kiraly <[EMAIL PROTECTED]> wrote: >I just upgraded to the most recent slink release and NIS stopped >working. If I run any of the NIS programs: domainname, ypcat, >ypwhich, etc, I get an instant segmentation fault. This is >supposed to be a production machine, so no I'm pretty much in deep >shit for doing the update. What can I do about it. Is it possible >get the old nis packages somewhere, so I can attempt a downgrade? Not that I know of. I got one other bugreport about this. I replied that it might be the kernel (there's an issue with the FPU emulation in most alpha Linux kernels that is mostly solved in 2.2.14pre16) but haven't had a reply yet. Could you try to compile and boot a 2.2.14pre16 kernel to see if that fixes the problem, and post the results here ? Mike. -- The From: and Reply-To: addresses are internal news2mail gateway addresses. Reply to the list or to [EMAIL PROTECTED] (Miquel van Smoorenburg)
Re: kernel upgrade
According to Adam Di Carlo: > [EMAIL PROTECTED] (Miquel van Smoorenburg) writes: > > > Don't use 2.2.11. It's br0ken. 2.2.12 will be out on monday or tuesday. > > Miquel, can you elaborate on this? AFAIK, the Stable Release Manager > was planning to do a slink update (either 2.1r3 or else 2.1.1 or > something) which shipped default with 2.2 kernels, and suggested > 2.2.11. Check out the release notes for 2.2.11 and 2.2.12 at http://www.linux.org.uk/ Note the comment about GCC, and the comment about floating point on the Alpha ... > He pointed out that 2.2.12 has some raid incompatibilities. No, the RAID update didn't go into 2.2.12 after all. It was in some of the pre-releases. > I'd be interesting on your thoughts from the Alpha standpoint. Is > someone from the Alpha team on the debian-release list to help > coordinate on behalf of Alpha porters? You'd have to find out how serious the floating point bugs for the Alpha in 2.2.12 are .. Mike. -- ... somehow I have a feeling the hurting hasn't even begun yet -- Bill, "The Terrible Thunderlizards"
Re: kernel upgrade
In article <[EMAIL PROTECTED]>, Dave Wiard <[EMAIL PROTECTED]> wrote: >Ok, once again, I'll post this up. Maybe somebody can give me some >specifics. Once I've got the new kernel compiled, what steps need to be >taken to run with the new kernel? I've got an SX164, AlphaBIOS (for the >time being I still need NT). Debian 2.1, and the new kernel will be >2.2.11. Thanks in advance, I've never done this successfullly before. Don't use 2.2.11. It's br0ken. 2.2.12 will be out on monday or tuesday. Mike. -- ... somehow I have a feeling the hurting hasn't even begun yet -- Bill, "The Terrible Thunderlizards"
sysvinit_2.76-2 uploaded, should work out of the box for Alpha
I just uploaded sysvinit_2.76-2 to frozen and unstable. Besides fixing the "init u" bug (which was in -1) I removed the debian/shlibs.local file so that there isn't a dependency on libc6 anymore. This mean the unmodified package will compile, install and run cleanly on the Alpha as would be expected. I realized I could do this since it depended on libc6 (>= 2.0.5) which was a development version when hamm was unstable. Everybody now runs either no libc6 (bo) or libc6_2.0.7t (hamm). Also all packages compiled with the libc6 from slink on i386 depend on libc (>= 2.0.7u) anyway since the shlibs file from libc6 forces that. Mike. -- Indifference will certainly be the downfall of mankind, but who cares?
Re: Init starting twice again
In article <[EMAIL PROTECTED]>, Falk Hueffner <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] (Miquel van Smoorenburg) writes: >> >> I've uploaded a fixed package to master for i386. > >Does the new version check if the running version of init is capable >of correctly restarting init, or will I have to hope to be able to >reboot fast enough? It checks if the old version is >= 2.74 for i386, and >= 2.76 for all other architectures such as alpha. Now if you install the new init _twice_ without rebooting in between init will think it's being upgraded from 2.76-1 to 2.76-1 and happily do an "init u" while 2.75-4 is still running .. so don't do that :) Mike. -- ... one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth
Re: Init starting twice again
In article <[EMAIL PROTECTED]>, Jason Gunthorpe <[EMAIL PROTECTED]> wrote: >On Mon, 2 Nov 1998, Loic Prylli wrote: >> I think signature should be declared as a 9 bytes array, and the ninth >> bye shoudl be set to zero. But I am currently unable to test it :-( > >Oh yes, I definately agree, if strcmp returns 0 it is a bloody fluke on >any arch. Could use strncmp too.. I don't actually know what part this >plays in init but can someone fix it? I've uploaded a fixed package to master for i386. Mike. -- ... one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth
Re: sysvinit_2.75-4.1.deb trashes file systems
In article <[EMAIL PROTECTED]>, Paul Slootman <[EMAIL PROTECTED]> wrote: >On Sat 24 Oct 1998, Falk Hueffner wrote: >I had the same problem (and reported it at Fri, 9 Oct 1998 09:15:06 +0200 >with subject 'Warning! Problem when upgrading to sysvinit_2.75-4.1'). >I didn't really get any substantive replies then. I'd also guess that >this is alpha-specific, because we'd see many more reports if i386 also >had this problem. It's the "init u" in the postinst script that causes this, I think. It should tell the running version of init to re-exec itself (u == upgrade). However the version of init you were running at that time took it as "init s", or whatever. Can you check if "init u" works as expected with the init binary from 2.75-4.1 actually running (eg after a reboot)? I wonder if this bug comes from an older init that is confused or that "init u" just doesn't work on an alpha. Yes I know I could test it on alpha.debian.nl but I am at home right now and cannot press the big red button if need be. Mike. -- "Did I ever tell you about the illusion of free will?" -- Sheriff Lucas Buck, ultimate BOFH.
