similar to: klibc kernel tree merged with 2.6.17-rc5; sparc64 changes in

changing i386 COMMAND_LINE_SIZE to 1024 attached is a simplistic fix to change kernel's command-line size from 256 to 1024, tomatch capability in syslinux 3.08. It seems to work. Is this all there is to it ? One of the reasons I did this was to figure out what extra options are appearing, and why. b4 extending: (the last bit is truncated) Jun 4 06:31:05 truck kernel: Kernel command

Hi, I believe the following patch in the GIT - 2.6.17-rc5 is not correct: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=75616cf9854b83eb83a968b1338ae0ee11c9673c It is the second of the two patches contributed by Leonid Ananiev. This one incorrectly adds the super block unlocking in the error path, though. As we can see in the function ext3_group_add() the

Sparc64 has support for a bunch of architecture-specific options taken from the PROM. Convert them to kernel command line form and write the file /arch.cmd in the rootfs, which can be recovered by kinit and processed. The kinit support has already been committed. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit c6e5c5a77681f5bf6f9fea55d031115e9f58ada6 tree

folks, Im finding that using a config like this: SERIAL 0 19200 #IPAPPEND 2 PROMPT 1 TIMEOUT 100 IMPLICIT 0 APPEND console=ttyS0,19200n81 root=/dev/nfs nfsaddrs=10.10.10.100:10.10.10.2:10.10.10.2:255.255.255.0:soekris:eth0 nfsroot=10.10.10.2:/nfshost/truck panic=15 LABEL deb268 KERNEL vmlinuz-2.6.8-1-386 initrd=initrd.img-2.6.8-1-386 panic=10 LABEL deb268-ram KERNEL vmlinuz-2.6.8-1-386

Boot options which have been obtained in an architecture-specific fashion have to be copied to /arch.cmd in the rootfs. This implements that functionality for sparc32; the code is identical to sparc64 minus the openprom support for obtaining nfsroot options. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit fc8c0c09f9dd5139dd8d797eaf9fe33962b6cd2c tree

Hi, I've got another one... NFS error 101 with NFSROOT has been discussed a lot, and hpa gave an answer to it which appears right. It's ENETUNREACH, and I suspect my diskless box does not set its IP parameters right. PXElinux is set up as follows: label linvdr kernel kernel-linvdr append initrd=initrd-linvdr acpi=off root=/dev/nfs \

folks, Im trying to boot to runlevel 4 explicitly, using this stanza: ie with a single 4 at end of APPEND line. LABEL 2.6.11-r10c2-soekris-v1 MENU LABEL ^j. runlevel 4 2.6.11-r10c2-soekris-v1 # 4 MENU DEFAULT KERNEL vmlinuz-2.6.11-r10c2-soekris-v1 APPEND console=ttyS0,19200n81 root=/dev/nfs nfsroot=192.168.42.1:/nfshost/foo

As some people have requested, here is klibc as a historyless patchset against 2.6.17. The patchset consists of two parts: changes to the main kernel code taken straight from the git history (as it is rather few patches), and additions, grouped by rough divisions. The majority of the patches are independent in the sense that they should apply independently, but Makefile/Kbuild files may have to

The parts of klibc specific to the sparc64 architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit f30fa3db62972125afa68d3b53d03cdb843d3bbd tree f2d942e281dce8bb98d4fa84b7e431c7beaddfc4 parent 1b5c93603ed3460ed1fba9e5d453a6fa54d0ccce author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:50 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

Hi, Thanks for your reply Josef. > In netstat -p |grep rpc I get: > dgram 56732 rpc.nfsd > dgram 55905 rpc.mountd > While client looks for socket 100003/2 or 100005/1, mine rpc.mountd is on socket 55905. Maybe it is a reason for an error 22. >The port numbers are RPC numbers, not sockets. Try 'rpcinfo -p' for these. rpcinfo -p 100005 mountd 100003 nfs So this looks

I know almost nothing about modern SPARC64 systems especially when they are running linux. But, can you try this command line and see if it gives more information before it blows up: rsync -vvai /export/test/ /export/test2/ On 06/28/2016 05:39 PM, alexmcwhirter at triadic.us wrote: > -------- Original Message -------- > Subject: rsync seem to be broken on sparc64 > Date: 2016-06-27

Hi all, I realize I have been a bit MIA lately, but I'm going to try to make forward progress again on klibc. I have pushed the current integrated tree up to 2.6.21-rc2; so far, no functional enhancements, but I'm looking at the following: - Mount-by-label/mount-by-uuid. - Ability to fall back on different roots. - nfsroot on NFSv4. - nfsroot over IPv6, as soon as the kernel supports

-------- Original Message -------- Subject: rsync seem to be broken on sparc64 Date: 2016-06-27 23:43 From: alexmcwhirter at triadic.us To: debian-sparc at lists.debian.org I posted about this in the kernel lists a few months ago to no avail. I see it on gentoo as well with any kernel newer than 3.18. I came across this when using lxc on sparc64. The debian template uses rsync to move the

TB --- 2013-11-19 23:00:41 - tinderbox 2.20 running on worker01.tb.des.no TB --- 2013-11-19 23:00:41 - FreeBSD worker01.tb.des.no 9.1-RELEASE-p4 FreeBSD 9.1-RELEASE-p4 #0: Mon Jun 17 11:42:37 UTC 2013 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-11-19 23:00:41 - starting RELENG_10 tinderbox run for sparc64/sparc64 TB --- 2013-11-19 23:00:41 - cleaning the

TB --- 2008-07-29 09:37:14 - tinderbox 2.3 running on freebsd-stable.sentex.ca TB --- 2008-07-29 09:37:14 - starting RELENG_7 tinderbox run for sparc64/sparc64 TB --- 2008-07-29 09:37:14 - cleaning the object tree TB --- 2008-07-29 09:37:32 - cvsupping the source tree TB --- 2008-07-29 09:37:32 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/sparc64/sparc64/supfile TB ---

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=474 jan.oravec@6com.sk changed: What |Removed |Added ---------------------------------------------------------------------------- OS/Version|All |Gentoo Platform|All |sparc64 ------- Additional Comments From jan.oravec@6com.sk

TB --- 2008-06-03 09:06:24 - tinderbox 2.3 running on freebsd-legacy.sentex.ca TB --- 2008-06-03 09:06:24 - starting RELENG_6 tinderbox run for sparc64/sparc64 TB --- 2008-06-03 09:06:24 - cleaning the object tree TB --- 2008-06-03 09:06:55 - cvsupping the source tree TB --- 2008-06-03 09:06:55 - /usr/bin/csup -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/sparc64/sparc64/supfile TB ---

On Tue, Feb 20, 2018 at 19:08:27 -0500, Chris Ross wrote: > > Apologies first for using two addresses, but I can?t currently read my email at distal.com. :-) > > I was previously running dovecot2-2.2.29.1_2 on FreeBSD 11 on sparc64. > Trying to debug a problem I was having with one of my clients, I > upgraded to dovecot-2.2.33.2_4 on that same server. However, I

TB --- 2012-04-08 08:26:29 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-04-08 08:26:29 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-04-08 08:26:29 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2012-04-08 08:26:29 - cleaning the

I am trying to build llvm on freebsd-8.0 on sparc64 CPU. I patched sources because 'sparc' enum value in include/llvm/ADT/Triple.h conflicts with gcc typedef 'sparc'. This allowed llvm itself to build successfully. But there is an error during gcc frontend compile: Did not get a target machine! Triplet is sparc64-unknown-freebsd8.0 I think this is because in many places, like in