Dear team,
How am i gonna solve this error, with a fresh Silo install on RAID 1?
~ # cat /target/boot/silo.conf
root=/dev/md1
partition=0
default=Linux
read-only
timeout=100
image=/vmlinuz
label=Linux
initrd=/initrd.img
image=/vmlinuz.old
label=LinuxOLD
initrd
Two more caveats in common/jmp.S..
diff --git a/common/jmp.S b/common/jmp.S
index 3bc8c94..a446d78 100644
--- a/common/jmp.S
+++ b/common/jmp.S
@@ -18,7 +18,13 @@
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
USA. */
-#define
file.c | 2 +-
second/muldi3.S | 10 +-
silo/silo.c | 12 ++--
14 files changed, 87 insertions(+), 34 deletions(-)
diff --git a/Rules.make b/Rules.make
index 0f176db..e46af48 100644
--- a/Rules.make
+++ b/Rules.make
@@ -2,10 +2,9 @@ V
Hi Sam!
On 11/25/2016 10:22 PM, Sam Ravnborg wrote:
> (...)
Thank you very much for all the input! This helps a lot!
I will have a look at your comments and improve the patch.
Cheers,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie
Hi John.
On Thu, Nov 24, 2016 at 11:59:32PM +0100, John Paul Adrian Glaubitz wrote:
> This patch adds the necessary changes to compile silo
> on sparc64. It adds the required stack bias for stack
> operations and makes sure that all variables are properly
> aligned and have the prope
dy), do the required changes so that
>> it's still works for everybody without extra fiddling.
>
> Don't be so rude, I'm not forcing anything onto anyone.
>
>>>> Also you broke the tilo build...
>>>
>>> Not here. Just tried it again and it builds fine. Can you be
lt to -m
>> native.
>
> I think that's your job to try. If you want to "add 64-bit support"
> (instead of forcing it to everybody), do the required changes so that
> it's still works for everybody without extra fiddling.
+1
This is exactly the kind of trouble the origin
On 11/25/2016 05:44 PM, David Miller wrote:
> Many people, including myself, are still using predominantly 32-bit
> userspace on sparc64 machines. It is significantly faster, and for
> me speed is really important.
I have already fixed this issue in a second version posted yesterday.
Thanks,
ext. I see this number In
aout_load.c of QEMU and boot of NetBSD.
This magic numbers is a "Branch Always" instruction, which jumps to
the real entry point.
Because the text is not placed at different address, the boot loader
has to arrange it.
In Silo, first-iso/crt0.S may be fine, it move
Hi,
On Thu, Nov 24, 2016 at 11:26:20PM +0100, John Paul Adrian Glaubitz wrote:
> On 11/24/2016 11:05 PM, Aaro Koskinen wrote:
> > The same issue as with silo.
>
> Don't you think your statements are a bit misleading then? I didn't break
> anything,
> I changed the default t
This patch adds the necessary changes to compile silo
on sparc64. It adds the required stack bias for stack
operations and makes sure that all variables are properly
aligned and have the proper size, both on 32- and 64-bit
targets. These changes have been verified to work and
have been used
Replaced "LD=ld -m elf64_sparc" with "LD=ld" which essentially
reverts c836dbda which hard-wired the build to 32 bits. Since
both 32- and 64-bit builds are supported these days, this should
no longer be necessary.
Adrian
On 11/24/2016 11:51 PM, Aaro Koskinen wrote:
> You could write the Makefile so that build works even with 32-bit
> userspace. I don't think it's unreasonable or rude to demand.
It isn't. But it's always possible to say that in polite way. I'm
trying to help improving things, not forcing anything
On 11/24/2016 11:32 PM, James Clarke wrote:
> Part of the problem is not forcing 64-bit, but that the Makefile is
> inconsistent.
> The default CC is gcc without any flags, but ld is given -m elf64_sparc. If
> you
> are running with sparc32 as your default target, gcc will generate 32-bit
>
do the required changes so that
>> it's still works for everybody without extra fiddling.
>
> Don't be so rude, I'm not forcing anything onto anyone.
>
>>>> Also you broke the tilo build...
>>>
>>> Not here. Just tried it again and it builds fine. Ca
rcing anything onto anyone.
>>> Also you broke the tilo build...
>>
>> Not here. Just tried it again and it builds fine. Can you be more specific?
>
> The same issue as with silo.
Don't you think your statements are a bit misleading then? I didn't break
anything,
I changed
On 24/11/16 21:26, vinc...@cojot.name wrote:
> A while back I stumbled onto an old post talking about the 'Illegal
> instruction' issue with SILO on serengeti machines:
>
> http://helenos-blog.pavel-rimsky.cz/?p=3
>
> Any thoughts?
>
> Note that I have not personall
On 11/24/2016 10:23 PM, Aaro Koskinen wrote:
> This breaks the native build on my Sun Ultra 5 with 32-bit userspace and GCC
> defaulting to ultrasparc:
Well, you can just change this part back to "elf32_sparc" and it will work.
Might
even be possible to omit the "-m" option altogether to it will
n Ultra 5 with 32-bit userspace and GCC
defaulting to ultrasparc:
$ make
[...]
make[1]: Entering directory '/home/aaro/silo/first'
gcc -Os -Wall -I. -I../include -fomit-frame-pointer -fno-strict-aliasing
-DSMALL_RELOC=0x28 -DLARGE_RELOC=0x38 -fno-stack-protector -c first.S
-o first.o
A while back I stumbled onto an old post talking about the 'Illegal
instruction' issue with SILO on serengeti machines:
http://helenos-blog.pavel-rimsky.cz/?p=3
Any thoughts?
Note that I have not personally verified that it works or not (I sold my
US-IIICu sb2k some time ago already
On 2016-11-24 12:33, John Paul Adrian Glaubitz wrote:
Hi Dave!
As promised in another mail earlier today, here is the current patch
changes that we are currently using on top of silo HEAD to build
it as a 64-bit package in Debian unstable (sparc64).
The silo package has been shipped in Debian
On Nov 24, 2016, at 6:43 PM, alexmcwhir...@triadic.us wrote:
>
>> On 2016-11-24 12:33, John Paul Adrian Glaubitz wrote:
>> Hi Dave!
>> As promised in another mail earlier today, here is the current patch
>> changes that we are currently using on top of silo HEAD
This patch adds the necessary changes to compile silo
on sparc64. It adds the required stack bias for stack
operations and makes sure that all variables are properly
aligned and have the proper size, both on 32- and 64-bit
targets. These changes have been verified to work and
have been used
Hi Dave!
As promised in another mail earlier today, here is the current patch
changes that we are currently using on top of silo HEAD to build
it as a 64-bit package in Debian unstable (sparc64).
The silo package has been shipped in Debian with 64-bit support for
a while now without any major
From: John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de>
Date: Thu, 24 Nov 2016 11:00:29 +0100
> For SILO, Oracle has created several patches which port SILO to 64-bit (I
> extracted
> that patch and applied it to the Debian package) and other packages which
> improv
blem is that while several patches for SILO and even GRUB exist which
improve these bootloaders on sparc64, none of them have actually officially been
merged yet.
For SILO, Oracle has created several patches which port SILO to 64-bit (I
extracted
that patch and applied it to the Debian package)
Package: silo
Followup-For: Bug #730478
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org
Hello!
Can we please close this bug report since there's working silo package in the
unreleased sparc64.
# apt show silo
Package: silo
Version: 1.4.14
On 12/30/2015 10:48 PM, Aaro Koskinen wrote:
> Maybe the current (properly patched) version of elftoaout should be
> submitted to either to SILO or kernel upstream source tree, so that
> people wouldn't need to face such issues in the future...
>From what I can see, upstream seems lon
On Wed, Dec 30, 2015 at 10:57:15PM +0100, John Paul Adrian Glaubitz wrote:
> On 12/30/2015 10:48 PM, Aaro Koskinen wrote:
> > Maybe the current (properly patched) version of elftoaout should be
> > submitted to either to SILO or kernel upstream source tree, so that
> > people
hed) version of elftoaout should be
submitted to either to SILO or kernel upstream source tree, so that
people wouldn't need to face such issues in the future...
A.
On Tue, 2015-12-29 at 13:18 +0100, John Paul Adrian Glaubitz wrote:
> On 12/29/2015 12:24 PM, Frans van Berckel wrote:
> > > The unsigned long probably becomes 64 bit on sparc64. I'll check
> > > whether Oracle has a patched version.
> >
> > The Oracle devtoolset sources (incl binutils) are
Nice job everyone!
On Tue, Dec 29, 2015 at 6:18 AM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
> On 12/29/2015 12:24 PM, Frans van Berckel wrote:
> >> The unsigned long probably becomes 64 bit on sparc64. I'll check
> >> whether Oracle has a patched version.
> >
> > The
Hi!
Something with the version of silo I built from source on sparc64 is
amiss:
Version from sparc:
(sparc64 host): genisoimage -G boot/isofs.b -B ... -r -o test.iso boot/
(amd64 host): qemu-system-sparc64 -nographic -m 512 -cdrom test.iso -boot d
OpenBIOS for Sparc64
Configuration device id
On 29/12/15 11:03, John Paul Adrian Glaubitz wrote:
> On 12/29/2015 11:52 AM, Richard Mortimer wrote:
>> From memory the conversion to a.out is done by the elftoaout binary from
>> sparc-utils. It maybe that the problem lies in there rather than in silo
>> itself.
&
On 12/29/2015 12:18 PM, Bryce wrote:
> Having just looked, it carries a small patch (elftoaout-include.patch) which
> modifies the Exec struct, though now that I look at it, as mentioned by Mark,
> those should probably be u_int32_t for portability between 32/64.
> We didn't make any changes to
On 29/12/15 10:16, John Paul Adrian Glaubitz wrote:
> Hi Mark!
>
> On 12/29/2015 11:03 AM, Mark Cave-Ayland wrote:
>> The a.out magic (0x107) is located at bytes 0x202-0x204 in the working
>> image but appears at bytes 0x206-0x207 in the broken image. It looks
>> li
On 29/12/15 09:25, John Paul Adrian Glaubitz wrote:
> Hi!
>
> Something with the version of silo I built from source on sparc64 is
> amiss:
>
> Version from sparc:
>
> (sparc64 host): genisoimage -G boot/isofs.b -B ... -r -o test.iso boot/
> (amd64 host): qemu-syste
Hi Mark!
On 12/29/2015 11:03 AM, Mark Cave-Ayland wrote:
> The a.out magic (0x107) is located at bytes 0x202-0x204 in the working
> image but appears at bytes 0x206-0x207 in the broken image. It looks
> like somehow your 64-bit SILO build is extending the a.out header fields
> from 3
On Tue, 2015-12-29 at 12:03 +0100, John Paul Adrian Glaubitz wrote:
>
> The unsigned long probably becomes 64 bit on sparc64. I'll check
> whether Oracle has a patched version.
The Oracle devtoolset sources (incl binutils) are available here ...
On 12/29/2015 12:24 PM, Frans van Berckel wrote:
>> The unsigned long probably becomes 64 bit on sparc64. I'll check
>> whether Oracle has a patched version.
>
> The Oracle devtoolset sources (incl binutils) are available here ...
Not necessary, thanks. The bug was in elftoaout which made bogus
t; like somehow your 64-bit SILO build is extending the a.out header fields
>> from 32-bits to 64-bits which is why the bootloader fails to be detected
>> by the PROM.
>
> Great work, you're absolutely right. The offsets for the magic are
> different when comparing both isof
On 12/29/2015 11:52 AM, Richard Mortimer wrote:
> From memory the conversion to a.out is done by the elftoaout binary from
> sparc-utils. It maybe that the problem lies in there rather than in silo
> itself.
Right!
That must be it:
typedef struct {
unsigned long
Hi Jose (and others @Oracle)!
I am in the final process of creating a fresh set of debian-installer
images for sparc64 and just stumbled over the following comment in
the scripts which create the sparc install images [1]:
# Sparc64 kernel is so big, that uncompressing it corrupts SILO memory
of debian-installer
images for sparc64 and just stumbled over the following comment in
the scripts which create the sparc install images [1]:
# Sparc64 kernel is so big, that uncompressing it corrupts SILO memory,
# uncompress it before hand.
Does this apply to the 64-bit version of silo which I
On 28/12/15 14:11, c...@netunix.com wrote:
> It is not that simple.
> Basically ( the Oracle guys should know more ) the OBP only initialises
> a small block of memory so your image must fit into that space until it
> has initialised enough memory management to use more space.
> The clue is to
Hi John.
I am in the final process of creating a fresh set of debian-installer
images for sparc64 and just stumbled over the following comment in
the scripts which create the sparc install images [1]:
# Sparc64 kernel is so big, that uncompressing it corrupts SILO memory
I notice that most descriptions of booting Solaris from SILO mention
ufsboot, but it appears that was dropped after SunOS 5.7 or 5.8
apparently since the kernel no longer needed to handle pre-OBP systems.
If a machine has both Linux and Solaris 10 or 11 (e.g. OpenSXCE)
installed, is it still
] [UU]
md0 : active raid1 sdb4[1] sda4[0]
4883648 blocks [2/2] [UU]
Server boots but I not able to reinstall silo bootblock on /dev/sdb.
Silo only returns :
Root gershwin:[~] silo
/etc/silo.conf appears to be valid
Fatal error: File systems other than ext2, ext3, ufs and romfs not yet
Hi,
as the question came up on IRC: Just wanted to give some update about
my progress in adopting the silo package:
Thanks to Jurij I'm now a memmber of the debootloaders Alioth project.
I imported the previous packaging and switched to Git. My packing so
far is at http://anonscm.debian.org
On Wed, Oct 2, 2013 at 3:27 AM, Axel Beckert a...@debian.org wrote:
Control: retitle -1 ITA: silo -- Sparc Improved LOader
Control: owner -1 !
Hi Jurij,
Jurij Smakov wrote:
There are currently no serious bugs that I know of, so it's mostly about
keeping it reasonably up to date.
Ok
.
Done:
http://anonscm.debian.org/gitweb/?p=debootloaders/silo.git;a=shortlog
Upload preferably after I managed to build silo on sparc64, too. If
that seems too far away, I'll probably upload earlier.
Thanks for picking it up.
Thanks for all your work on silo so far!
Regards
Control: retitle -1 ITA: silo -- Sparc Improved LOader
Control: owner -1 !
Hi Jurij,
Jurij Smakov wrote:
There are currently no serious bugs that I know of, so it's mostly about
keeping it reasonably up to date.
Ok, I'll try my luck. I managed to revamp the package in a way that my
UltraSparc
Package: wnpp
Severity: normal
[This message is bcc'd to sub...@bugs.debian.org.]
Given that I'm no longer involved with sparc port and none of the other
silo maintainers appear to be active (no replies to [0], sent over a month
ago), I think the best course of action is to orphan silo
On Sun, Sep 1, 2013 at 11:55 AM, Jurij Smakov ju...@wooyd.org wrote:
Package: wnpp
Severity: normal
[This message is bcc'd to sub...@bugs.debian.org.]
Given that I'm no longer involved with sparc port and none of the other
silo maintainers appear to be active (no replies to [0], sent over
uploaded a new silo package (1.4.14+git20120819-1) including
these fixes to unstable, and would encourage everyone to test it (it
should appear on the mirrors within a few hours). After a grace period
of 10 days we are going to arrange for its propagation to testing,
given
From: Jurij Smakov ju...@wooyd.org
Date: Fri, 7 Sep 2012 09:33:58 +0100
If you could give it a try to confirm that it now boots successfully
on your machine, it would be appreciated.
I'm 3600 miles away from the machine for the next few months so
this isn't practical, sorry.
--
To
On Wed, Aug 15, 2012 at 01:14:16AM -0700, David Miller wrote:
This generates an illegal instruction exception.
This has a long history. For the first sun4v port of SILO in commit
494770a17eea7192d3242051e76f4da6d838e3a1 (SILO Niagara/SUN4V
support) this code was removed entirely
On Sun, Aug 19, 2012 at 03:24:45PM -0700, David Miller wrote:
From: Jurij Smakov ju...@wooyd.org
Date: Sun, 19 Aug 2012 16:41:42 +0100
I just uploaded a new silo package (1.4.14+git20120819-1) including
these fixes to unstable, and would encourage everyone to test it (it
should appear
From: Jurij Smakov ju...@wooyd.org
Date: Sun, 19 Aug 2012 16:41:42 +0100
I just uploaded a new silo package (1.4.14+git20120819-1) including
these fixes to unstable, and would encourage everyone to test it (it
should appear on the mirrors within a few hours). After a grace period
of 10
From: Jurij Smakov ju...@wooyd.org
Date: Sun, 19 Aug 2012 23:29:05 +0100
On Sun, Aug 19, 2012 at 03:24:45PM -0700, David Miller wrote:
From: Jurij Smakov ju...@wooyd.org
Date: Sun, 19 Aug 2012 16:41:42 +0100
I just uploaded a new silo package (1.4.14+git20120819-1) including
these fixes
Package: silo
Severity: grave
X-Debbugs-Cc: David Miller da...@davemloft.net, debian-sparc@lists.debian.org
Tags: upstream patch fixed-upstream
Filing this as a bug so it doesn't get lost. Thanks for the heads-up,
David.
On Wed, Aug 15, 2012 at 01:14:16 -0700, David Miller wrote
This generates an illegal instruction exception.
This has a long history. For the first sun4v port of SILO in commit
494770a17eea7192d3242051e76f4da6d838e3a1 (SILO Niagara/SUN4V
support) this code was removed entirely.
But later this was found to regress older UltraSPARC boxes, so we put
From: David Miller da...@davemloft.net
Date: Wed, 15 Aug 2012 01:14:16 -0700 (PDT)
This generates an illegal instruction exception.
Unfortunately, after some more testing, this needs a follow-on fix,
included below and also committed to SILO git.
Sorry for the confusion
Hello
On my sparc ultra 10 with squeeze, when I boot kernel 2.6.32 (the latest
in the repo) silo prompt shows the error code SI . If I boot old 2.6.18 it
boots fine.
What does exactly mean that silo error? How can I solve this problem?
My system has separate /boot 93MB
/ is mounted on /dev
On Tue, Jan 31, 2012 at 10:13:28AM +, Howard Eisenberger wrote:
On 2012-01-27, Jurij Smakov wrote:
I've built a new SILO package, which contain upstream fixes for bug
#655897 (failure to build from source with recent versions of
e2fslibs). I would appreciate some early testing
On 2012-01-27, Jurij Smakov wrote:
I've built a new SILO package, which contain upstream fixes for bug
#655897 (failure to build from source with recent versions of
e2fslibs). I would appreciate some early testing before I upload it to
unstable. You can find the new package (both source
Hello,
I've built a new SILO package, which contain upstream fixes for bug
#655897 (failure to build from source with recent versions of
e2fslibs). I would appreciate some early testing before I upload it to
unstable. You can find the new package (both source and binary) at
http
the upgrade of debian, and silo.conf has been automatically modified to
load the new kernel (some years ago the one of lenny, some months ago
the one of squeeze). When I boot the ultra10 with a new kernel, for ex
2.6.32, openboot loads, than at the prompt should appear SILO, but what
I get
months ago the one of squeeze). When I
boot the ultra10 with a new kernel, for ex 2.6.32, openboot loads, than at the
prompt should appear SILO, but what I get is SI and nothing more. As I've told
before, with old 2.6.18, it works
I am not an expert in this, but since nobody else has replied
ago the one of lenny, some months ago the one of squeeze). When I
boot the ultra10 with a new kernel, for ex 2.6.32, openboot loads, than at the
prompt should appear SILO, but what I get is SI and nothing more. As I've told
before, with old 2.6.18, it works (by the way, is there a way to chose
with
the silo message:
console stdout lacks device_type
and stops at the ok prompt (screen attached to th GFX).
Booting with serial console works fine. Then I returned to the onboard
graphics, everything ok again.
Any idea?
Thanks,
Hartwig
--
To UNSUBSCRIBE, email to debian-sparc-requ
(or amd64, depending on the hardware). SILO would
not install on such a machine, nor would it be in any way functional
even if you could. Sorry debian-sparc couldn't be of more help.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net
you.
Solaris comes in a version for sparc and a version for i386. You'll
need the i386 port (or amd64, depending on the hardware). SILO would
not install on such a machine, nor would it be in any way functional
even if you could. Sorry debian-sparc couldn't be of more help.
Thanks Brian
is, it's some
custom built chassis with custom everything to create this appliance.
b) OR, I was thinking that maybe I could partition the 2nd HDD while in
Solaris, install Debian/SILO on it either through boot.img or some other way
and then have it boot from this disk instead into debian
understand this installation and tell me where does
Silo/bootloader etc sit in this kind of a situation?
AFAIK, sparc bootloader is called silo, and it's configuration file
located under /etc/ :
http://packages.debian.org/lenny/sparc/silo/filelist
/etc/silo.conf
Thanks for that. Yes, I knew
and was able to boot into it as well. So far, so good!
However, I have two questions:
a) While doing a check on something, I realised that my /boot is empty. Could
anyone help me understand this installation and tell me where does
Silo/bootloader etc sit in this kind of a situation?
When I do
hi,
i try to install squeeze debian on blade 1000 (2*750Mhz, 2 go ram, 2 * scsi hdd
38go, ethernet)
beetween installation the blade load the microcodes on USB key.
well the installation spend normaly,
but when the blade try to install silo, there are the message error code
1 .
i try to parted
On Sat, Jul 24, 2010 at 11:55:54AM +0100, Jurij Smakov wrote:
Hello,
In http://bugs.debian.org/589891 Axel Beckert reports that the latest
SILO in sid (1.4.14+git20100228-1) does not work on his Ultrasparc 10
box. Can anyone with the same hardware confirm this? It works fine on
my
hi,
i have installed on my sun blade 1000 ubuntu 8.04 upgrade to ubuntu 9.04,
but i tried to parametre silo for scsi generic drivers.
on my ultra 5 it 's easy , i just add :
slio.conf // append=ide=nodma for ide hard drives.
but i cannot add append=hda=ide-scsi for scsi hard drives.
i have search
with the installation.
Two other issues: First, the internal IDE cd-rom drive in the
ultra 5 (secondary master) was not detected from inside the
installer, so I installed from an external scsi cd-rom.
Second, to get silo to boot I had to change root= in silo.conf
from /dev/sdb2 (I also have
, the internal IDE cd-rom drive in the
ultra 5 (secondary master) was not detected from inside the
installer, so I installed from an external scsi cd-rom.
Second, to get silo to boot I had to change root= in silo.conf
from /dev/sdb2 (I also have a scsi drive sda) to /dev/hda2
Given these issues
hi,
at the first time i do :
I did an expert install and when I got to
tasksel, I didn't select anything (i.e. unselected standard).
I try to install silo in the next step in the
installation or if skipped that and chose to continue without silo,
rebooting the CD in rescue mode, i chose /dev
On Mon, May 31, 2010 at 02:38:28PM +0200, philo wrote:
hi,
at the first time i do :
I did an expert install and when I got to
tasksel, I didn't select anything (i.e. unselected standard).
I try to install silo in the next step in the
installation or if skipped that and chose
hi,
i try to install debian testing cdrom iso with version sqeeze and last...
the programme silo cannot install .. i have errors !
1- squeeze between install at rubrique choise and install sofware
stay blocked at silo configuration.
2- last testing (i forgot the name, sorry) silo code error
On 2010-05-30, philo wrote:
i try to install debian testing cdrom iso with version sqeeze and last...
the programme silo cannot install .. i have errors !
1- squeeze between install at rubrique choise and install sofware
stay blocked at silo configuration.
2- last testing (i forgot
On 2010-05-31, Howard Eisenberger wrote:
On 2010-05-30, philo wrote:
i try to install debian testing cdrom iso with version sqeeze and last...
the programme silo cannot install .. i have errors !
1- squeeze between install at rubrique choise and install sofware
stay blocked at silo
On Sat, Jan 30, 2010 at 02:51:47PM +, Jurij Smakov wrote:
Hi,
I've prepared a new version of SILO (1.4.14+git20100130-1) which fixes
an FTBFS and some other bugs/warnings. One change which carries minor
risk is a switch to using default GCC (in this case, gcc-4.4), so if
you
Hi,
I've prepared a new version of SILO (1.4.14+git20100130-1) which fixes
an FTBFS and some other bugs/warnings. One change which carries minor
risk is a switch to using default GCC (in this case, gcc-4.4), so if
you are in a position to test the new package, please do. New package
On Sat, Oct 18, 2008 at 11:31:31PM -0400, Brian Thompson wrote:
Jurij Smakov wrote:
Hi,
Have anyone tried to install on a sparc box using lenny beta2
installer images? My installation is hanging on Configuring SILO,
apparently because it prompts (without using debconf
Hi,
Have anyone tried to install on a sparc box using lenny beta2
installer images? My installation is hanging on Configuring SILO,
apparently because it prompts (without using debconf) for a
confirmation about installing SILO configuration. Can anyone please
confirm this behaviour? I can't
Jurij Smakov wrote:
Hi,
Have anyone tried to install on a sparc box using lenny beta2
installer images? My installation is hanging on Configuring SILO,
apparently because it prompts (without using debconf) for a
confirmation about installing SILO configuration. Can anyone please
confirm
Hi,
I've just uploaded new SILO (1.4.13a+git20070930-3) to unstable to fix
the RC bug #495860. If you are running unstable, please upgrade to
this version in the next couple of days and report any problems.
Thanks.
--
Jurij Smakov [EMAIL PROTECTED
On Sun, Mar 02, 2008 at 10:29:55PM +, Jurij Smakov wrote:
Hi,
SILO is currently being built with a non-standard compiler (gcc-4.1),
and we would like to transition to standard one (gcc-4.3) before the
release. I've rebuilt SILO with gcc-4.3, the updated package is
available at http
Hi,
SILO is currently being built with a non-standard compiler (gcc-4.1),
and we would like to transition to standard one (gcc-4.3) before the
release. I've rebuilt SILO with gcc-4.3, the updated package is
available at http://www.wooyd.org/debian/silo. If you have a chance,
please try it out
them with one CPU only AFAIK.
After a reboot the SILO is found. Return is pressed and immediately an
illegal instruction is raised.
Which Kernel are you trying to boot? I run into such things while trying
to boot a SMP Kernel on non-SMP machines and the other way round. Also
2.6.18 seems to have
Hello,
On Monday 05 November 2007 11:02:23 Bernd Zeimetz wrote:
[...]
After a reboot the SILO is found. Return is pressed and immediately an
illegal instruction is raised.
Which Kernel are you trying to boot? I run into such things while trying
to boot a SMP Kernel on non-SMP machines
and then chroot in
and re-install Silo?
Many thanks
Steffen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
to continue with the
installation. We have a complete lvm-based file system on our disk. The
update-initramfs was executed.
After a reboot the SILO is found. Return is pressed and immediately an illegal
instruction is raised.
There is no ready Debian sparc machine at our disposal, which means
firmware-qlogic which allowed us to continue with the
installation. We have a complete lvm-based file system on our disk. The
update-initramfs was executed.
Just because it may help with a different bug: Does the Blade run with
one or two CPUs?
After a reboot the SILO is found. Return is pressed
saw in expert mode didn't say that
silo really needed to rewrite the partition table RIGHT NOW. Once I
finally (autopartitioning) told it to do the partitioning itself, it
screamed just that.
That's the problem I've been having. How to reset silo to square one?
That's only offered in Guided
1 - 100 of 404 matches
Mail list logo
