On Thu, May 28, 2009 at 3:58 PM, Lorenzo Perone
lopez.on.the.li...@yellowspace.net wrote:
the result is, when choosing the disk with the zfs boot
sectors in it (in my case F5, which goes to ad6), the kernel
is not found. the console shows:
forth not found
definitions not found
only not
Lorenzo Perone wrote:
Hi,
I tried hard... but without success ;(
the result is, when choosing the disk with the zfs boot
sectors in it (in my case F5, which goes to ad6), the kernel
is not found. the console shows:
forth not found
definitions not found
only not found
(the above repeated
Hello,
During my tests (succesful) to directly boot from ZFS (with zfsboot and
gptzfsboot) I encounter the error can't boot 'kernel' if too many
devices/pools are connected to the machine. In my case:
2 SAS disks with 2 pools
2 SATA disks with 2 pools
1 USB key with one pool
`heap` command:
Henri Hennebert wrote:
Lorenzo Perone wrote:
Hi,
I tried hard... but without success ;(
the result is, when choosing the disk with the zfs boot
sectors in it (in my case F5, which goes to ad6), the kernel
is not found. the console shows:
forth not found
definitions not found
only not found
On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert h...@restart.be wrote:
This is the file /boot/loader from 7.2-STABLE which is wrong.
You can find a copy from 8.0-CURRENT and a script that I tested on a USB
key) and is running for me:
replacing /boot/loader with yours did the job
thanks!
--
Odds are that there are more changes that were made in HEAD to the
loader that need to be MFC'd.
-Kip
On Mon, Jun 1, 2009 at 3:55 AM, Alberto Villa villa.albe...@gmail.com wrote:
On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert h...@restart.be wrote:
This is the file /boot/loader from
on 29/05/2009 15:35 Andriy Gapon said the following:
So anyone else feels that this is a bug?
on 28/05/2009 16:55 Andriy Gapon said the following:
on 28/05/2009 16:26 Henri Hennebert said the following:
(gdb) bt
#0 0x0008012a6f22 in strlen () from /lib/libc.so.7
#1 0x0008012a0feb
Hello,
According to sem_init(3), we can't have shared unnamed semaphores.
However, the following code snippet seems to work just fine:
-- cut here --
sem_t semaphore;
if (sem_init(semaphore, 1, 10) 0)
std::cout Couldn't init semaphore:
strerror(errno)
On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote:
Hello,
According to sem_init(3), we can't have shared unnamed semaphores.
However, the following code snippet seems to work just fine:
-- cut here --
sem_t semaphore;
if (sem_init(semaphore, 1, 10) 0)
Andriy Gapon wrote:
on 29/05/2009 15:35 Andriy Gapon said the following:
So anyone else feels that this is a bug?
on 28/05/2009 16:55 Andriy Gapon said the following:
on 28/05/2009 16:26 Henri Hennebert said the following:
(gdb) bt
#0 0x0008012a6f22 in strlen () from /lib/libc.so.7
#1
On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote:
According to sem_init(3), we can't have shared unnamed semaphores.
However, the following code snippet seems to work just fine:
-- cut here --
sem_t semaphore;
if (sem_init(semaphore, 1, 10) 0)
on 01/06/2009 19:12 Henri Hennebert said the following:
Andriy Gapon wrote:
I propose the following patch for this issue.
It fixes mismatch between __assert extern declaration in zfs code and
actual
signature in libc code.
I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks.
On 31.05.2009, at 09:18, Adam McDougall wrote:
I encountered the same symptoms today on both a 32bit and 64bit
brand new install using gptzfsboot. It works for me when I use
a copy of loader from an 8-current box with zfs support compiled in.
I haven't looked into it much yet but it might help
I'm thinking that too. I spent some time taking stabs at figuring it
out yesterday but didn't get anywhere useful. I did try compiling the
-current src/sys/boot tree on 7.2 after a couple header tweaks to make
it compile but the loader still didn't work. The working loader is the
same file
Daniel O'Connor wrote:
On Mon, 1 Jun 2009, Pavel Greenberg wrote:
Hello everybody!
After today's source update I have a problem when doing make
buildworld:
cc -O2 -fno-strict-aliasing -pipe -march=pentium4
-DLOADER_NFS_SUPPORT - DBOOT_FORTH
-I/usr/src/sys/boot/i386/loader/../../ficl
On Monday 01 June 2009 12:06:18 Henri Hennebert wrote:
Lorenzo Perone wrote:
Hi,
I tried hard... but without success ;(
the result is, when choosing the disk with the zfs boot
sectors in it (in my case F5, which goes to ad6), the kernel
is not found. the console shows:
forth not
Jilles Tjoelker wrote:
If process-shared semaphores really work, then the above structure is
not a pathological case. Effectively, sem_t is carved in stone. So
process-private semaphores should continue to have most of their stuff
in a separately allocated structure, to preserve flexibility.
On Mon, 1 Jun 2009, Bruce Simpson wrote:
Jilles Tjoelker wrote:
If process-shared semaphores really work, then the above structure is
not a pathological case. Effectively, sem_t is carved in stone. So
process-private semaphores should continue to have most of their stuff
in a separately
On Mon, Jun 1, 2009 at 10:21 AM, Adam McDougall mcdou...@egr.msu.edu wrote:
I'm thinking that too. I spent some time taking stabs at figuring it out
yesterday but didn't get anywhere useful. I did try compiling the -current
src/sys/boot tree on 7.2 after a couple header tweaks to make it
Same here..
The first bug is the use of a LIBZFS variable in
src/sys/boot/i386/loader/Makefile, as this variable is set in
share/mk/bsd.libnames.mk
I just replaced LIBZFS by LIBZFSBOOT and the buildworld succeeded.
The second bug is the use of LOADER_ZFS_SUPPORT without any
consideration
20 matches
Mail list logo
