Re: vim build error on sparc
* Norbert Tretkowski wrote: > the current vim package from t-p-u ftbfs on sparc, and I don't > understand the reason. Looks like the buildd is broken, I just compiled it on a sparc64 machine without problems. Norbert
vim build error on sparc
Hi, the current vim package from t-p-u ftbfs on sparc, and I don't understand the reason. The build log is here: http://buildd.debian.org/fetch.php?&pkg=vim&ver=1%3A6.3-046%2B0sarge1&arch=sparc&stamp=1103908298&file=log&as=raw Build log of the unstable package: http://buildd.debian.org/fetch.php?&pkg=vim&ver=1%3A6.3-046%2B1&arch=sparc&stamp=1102901031&file=log&as=raw There was _no_ change, it was just a recompile on sarge for t-p-u. Any ideas? Norbert
Re: Sarge sparc netinstall rc2 bugs report
Hi Fred,
On Thu, 30 Dec 2004, Fred Rochet wrote:
Hello all,
I tested Sarge netinstall rc2 on an Ultra60 (Dual processor, 2GB RAM)
I downloaded
http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/sparc/rc2/sarge-sparc-netinst.iso
(112 MB)
Installation is OK (Partitioning, etc...)
But when I reboot the workstation, here is the message that I have got:
Reboting with command: boot disk1
Boot device: /[EMAIL PROTECTED],4000/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 File
and args:
SILO Version 1.4.8
boot:
Allocated 8Megs of memory at 0x4000 for kernel
Uncompressing image...
Loaded kernel version 2.4.27
Loading initial ramdisk (3391488 bytes at 0xBF802000 phys, 0x40C0
virt)...
\
Remapping the kernel... Booting Linux
Starting CPU 2... Illegal Instruction
{2} ok
=
The messages 'Starting CPU 2...' clearly comes from the kernel
(arch/sparc64/kernel/smp.c). I do not own any SMP hardware myself, so I
wonder whether 2.4.27 SMP kernels work for someone else on Ultra? As a
workaround you may try installing uniprocessor kernel. For that you need
to go to the installer's main menu and lower the debconf priority. Then,
after the base install you should be prompted for kernel to install,
giving you a choice of UP and SMP.
Best regards,
Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
Re:
> I was also wondering about the possibility of using an "initrd-less" > kernel. Somewhere in the Xconfig/Kconfig option sequence, I remember > reading in one of the help screens about initrd support that it's not > really necessary in many cases. I guess this is a little beyond this > message, but why does Linux need an initrd at all? Does it speed up the > boot process? This should help you for clarification on initrd. [EMAIL PROTECTED] ~]$ apropos initrd initrd (4) - boot loader initialized RAM disk mkinitrd (8) - creates initial ramdisk images for preloading modules [EMAIL PROTECTED] ~]$ man initrd "DESCRIPTION The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the the block device /dev/initrd’s contents for a two phased system boot-up. In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device’s contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device." > Or does it have something to do with compressing the kernel > to fit onto a floppy (in which case, one would only need an initrd on a > boot floppy, not the HD)? Or maybe it's got to do with having all the > modules needed to boot in one handy place, in which case if one were to > compile everything monolithically for a specific machine it shouldn't be > needed? > A bit of a chicken-egg issue. If your disk drivers are compiled as Modules, you need an initrd to boot the system. If they are compiled into the kernel, you won't need the initrd. However, if you try and enable a lot of stuff, and compile it all in, you may get a zImage that is too big to load on boot, so keep that in mind. Bruce
[no subject]
Perhaps his /boot was simply full? There were an awful lot of modules listed. Butwouldn't it be simpler to just compile the stuff in and be done with it? I mean, I understand why the installation kernel relays on initrd, but for a tuned, self compiled kernel, this isn't necessary. 'df -h' reports that /boot is only 26% full (22M out of 90M used). I was also wondering about the possibility of using an "initrd-less" kernel. Somewhere in the Xconfig/Kconfig option sequence, I remember reading in one of the help screens about initrd support that it's not really necessary in many cases. I guess this is a little beyond this message, but why does Linux need an initrd at all? Does it speed up the boot process? Or does it have something to do with compressing the kernel to fit onto a floppy (in which case, one would only need an initrd on a boot floppy, not the HD)? Or maybe it's got to do with having all the modules needed to boot in one handy place, in which case if one were to compile everything monolithically for a specific machine it shouldn't be needed? A URL explaining "why linux uses initrds" would be great... Daniel, could you attach "ls -l /boot" from your machine? www2# cd /boot www2# ls -l total 18223 lrwxrwxrwx 1 root root 1 2004-11-12 10:41 boot -> . -rw-r--r-- 1 root root 18958 2004-12-16 10:07 config-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 23847 2004-08-24 02:50 config-2.4.27-1-sparc64 -rw-r--r-- 1 root root 20236 2004-12-27 17:52 config-2.6.810.1-dej-usb -rw-r--r-- 1 root root 29705 2004-11-28 00:08 config-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 1 2004-11-12 10:41 etc -> . -rw-r--r-- 1 root root1024 2004-07-14 10:38 fd.b -rw-r--r-- 1 root root 512 2004-07-14 10:38 first.b -rw-r--r-- 1 root root1024 2004-07-14 10:38 generic.b -rw-r--r-- 1 root root 784 2004-07-14 10:38 ieee32.b lrwxrwxrwx 1 root root 31 2004-12-28 14:58 initrd-268 -> boot/initrd.img-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 33 2004-12-28 09:39 initrd-268usb -> boot/initrd.img-2.6.810.1-dej-usb lrwxrwxrwx 1 root root 33 2004-12-28 09:36 initrd.img -> boot/initrd.img-2.6.810.1-dej-usb -rw-r--r-- 1 root root 1802240 2004-12-16 11:35 initrd.img-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 3358720 2004-11-12 10:40 initrd.img-2.4.27-1-sparc64 -rw-r--r-- 1 root root 2007040 2004-12-28 09:36 initrd.img-2.6.810.1-dej-usb -rw-r--r-- 1 root root 3620864 2004-12-28 14:55 initrd.img-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 32 2004-12-28 09:42 initrd-sun -> boot/initrd.img-2.4.27-1-sparc64 lrwxrwxrwx 1 root root 35 2004-12-28 09:42 initrd-usb -> boot/initrd.img-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root7184 2004-07-14 10:38 isofs.b drwxr-xr-x 2 root root 12288 2004-11-12 10:29 lost+found -rw-r--r-- 1 root root7680 2004-11-12 10:41 old.b -rw-r--r-- 1 root root 64000 2004-11-12 10:41 second.b -rw-r--r-- 1 root root 315 2004-12-28 18:13 silo.conf -rw-r--r-- 1 root root 420 2004-12-28 15:02 silo.conf~ -rw-r--r-- 1 root root 61405 2004-07-14 10:38 silotftp.b -rw-r--r-- 1 root root 478536 2004-12-16 11:31 System.map-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 495144 2004-08-24 04:46 System.map-2.4.27-1-sparc64 -rw-r--r-- 1 root root 798041 2004-12-27 19:38 System.map-2.6.810.1-dej-usb -rw-r--r-- 1 root root 801887 2004-11-28 01:18 System.map-2.6.8-1-sparc64 -rw-r--r-- 1 root root 512 2004-07-14 10:38 ultra.b lrwxrwxrwx 1 root root 30 2004-12-28 09:36 vmlinuz -> boot/vmlinuz-2.6.810.1-dej-usb -rw-r--r-- 1 root root 1294079 2004-12-16 11:31 vmlinuz-2.4.27-10.1-dej-usb -rw-r--r-- 1 root root 1109207 2004-08-24 04:46 vmlinuz-2.4.27-1-sparc64 lrwxrwxrwx 1 root root 23 2004-12-28 15:00 vmlinuz-268 -> vmlinuz-2.6.8-1-sparc64 -rw-r--r-- 1 root root 1274753 2004-12-27 19:38 vmlinuz-2.6.810.1-dej-usb -rw-r--r-- 1 root root 1265285 2004-11-28 01:17 vmlinuz-2.6.8-1-sparc64 lrwxrwxrwx 1 root root 30 2004-12-28 09:53 vmlinuz-268usb -> boot/vmlinuz-2.6.810.1-dej-usb lrwxrwxrwx 1 root root 29 2004-12-28 09:44 vmlinuz-sun -> boot/vmlinuz-2.4.27-1-sparc64 lrwxrwxrwx 1 root root 32 2004-12-28 09:45 vmlinuz-usb -> boot/vmlinuz-2.4.27-10.1-dej-usb www2# Thanks again. -Dan
Re: lockd testing 2.4.18
you need nfs-common but also: netbase portmap (They were installed on my machine after I chosed to configure my machine as a server using "tasksel") Ref.: /usr/share/doc/nis/nis.debian.howto If you managed to automount using autofs and nis maps using /etc/auto.master: please tell me trick :-) Fred Selon "Rakotomandimby (R12y) Mihamina" <[EMAIL PROTECTED]>: > Hello, > > I'm trying to be a NFS client with my Debian testing on a sparc u-5. > > Mounting NFS is OK: the mount is then displayed when I type 'mout' after > mounting as root. > > The problem is the commad line freeze when attampting to enter and list > the content of the remote directory. > # lsmod > Module Size Used byNot tainted > nfsd 73816 0 (unused) > > (you have noticed no lockd) > > I have only nfs-common installed, and if I try to modprobe lockd : > > # modprobe lockd > modprobe: Can't locate module lockd > > # invoke-rc.d nfs-common start > Starting NFS common utilities: statdinvoke-rc.d: initscript nfs-common, > action "start" failed. > > What should I do to make this machine to be a working NFS client ? > -- > ASPO Infogérance http://aspo.rktmb.org/activites/infogerance > Unofficial FAQ fcolc http://faq.fcolc.eu.org/ > LUG sur Orléans et alentours. > Tél : 02 38 76 43 65 (France) > >
lockd testing 2.4.18
Hello, I'm trying to be a NFS client with my Debian testing on a sparc u-5. Mounting NFS is OK: the mount is then displayed when I type 'mout' after mounting as root. The problem is the commad line freeze when attampting to enter and list the content of the remote directory. # lsmod Module Size Used byNot tainted nfsd 73816 0 (unused) (you have noticed no lockd) I have only nfs-common installed, and if I try to modprobe lockd : # modprobe lockd modprobe: Can't locate module lockd # invoke-rc.d nfs-common start Starting NFS common utilities: statdinvoke-rc.d: initscript nfs-common, action "start" failed. What should I do to make this machine to be a working NFS client ? -- ASPO Infogérance http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc http://faq.fcolc.eu.org/ LUG sur Orléans et alentours. Tél : 02 38 76 43 65 (France)
Sarge sparc netinstall rc2 bugs report
Hello all,
I tested Sarge netinstall rc2 on an Ultra60 (Dual processor, 2GB RAM)
I downloaded
http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/sparc/rc2/sarge-sparc-netinst.iso
(112 MB)
Installation is OK (Partitioning, etc...)
But when I reboot the workstation, here is the message that I have got:
Reboting with command: boot disk1
Boot device: /[EMAIL PROTECTED],4000/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 File
and args:
SILO Version 1.4.8
boot:
Allocated 8Megs of memory at 0x4000 for kernel
Uncompressing image...
Loaded kernel version 2.4.27
Loading initial ramdisk (3391488 bytes at 0xBF802000 phys, 0x40C0
virt)...
\
Remapping the kernel... Booting Linux
Starting CPU 2... Illegal Instruction
{2} ok
=
Then I am not able to go further...
I tried to reboot with the netinstall cd, choosing rescue, and the system
hangs:
=
boot: rescue
Allocated 8Megs of memory at 0x4000 for kernel
Loaded kernel version 2.4.27
Loading initial ramdisk (2896142 bytes at 0xBFC02000 phys, 0x40C0
virt)...
|
Remapping the kernel... Booting Linux
=
Well ... I have got a Woody box installed on another Ultra 60.
Working well, that's why I am giving Sarge a try !
On these 2 machines, 2 SCSI disks, Solaris on disk0 and Debian on disk1.
Still haven't play with SILO, so I stop boot sequence in order to boot to
disk1 when I want to try debian.
I am ready to test a new version (rc3 for example).
My guess is that the ramdisk used for the installation is OK, as the
installation started well when installing Sarge. But the ramdisk installed
hangs the system (Message 1 above):
==> initial ramdisk (3391488 bytes
Same story for the ramdisk loaded during rescue mode:
==> initial ramdisk (2896142 bytes
It seems the initital ramdisk is different during installation, when booting
after installation, and when rescuing the system !
By the way, the boot sequence hangs when activating CPU2 ("Starting CPU 2...
Illegal Instruction") so I checked my Woody Ultra60, which, in fact, Woody is
not using that 2nd CPU:
===
[EMAIL PROTECTED]:~$ cat /proc/cpuinfo
cpu : TI UltraSparc II (BlackBird)
fpu : UltraSparc II integrated FPU
promlib : Version 3 Revision 31
prom: 3.31.0
type: sun4u
ncpus probed: 2
ncpus active: 1
Cpu0Bogo: 897.84
Cpu0ClkTck : 1ad23b30
MMU Type: Spitfire
===
Hope that mail will help. Sarge is about to be officially released, and it is
the first time I am helping the Debian project, after about 10 years using
Linux !
I would like that kind of installation issue to be avoided before Sarge
coming-out !!!
Cheers
Fred
