Dear collegaues,
one of my friends tonight called me to help him with recovering his remote(both
to me and him, heh) server with 8.0 or something with ZFS-on root (yes, I'd
said he was brave enough) having troubles with loading modules by loader.
During investigation it has been clear we
on 24/04/2013 02:03 Dimitry Andric said the following:
> Indeed, the DS segment was incorrect, the GDT should be loaded from the
> CS segment instead.
Very good catch! Indeed the segments at this point were set up for "user" data
while the "supervisor" data is needed.
Thank you!
--
Andriy Gapo
x003f 0x9590 0x
>>>> (gdb) x/16xh 0x9590
>>>> 0x9590: 0x 0x 0x 0x 0x 0x 0x9a00 0x00cf
>>>> 0x95a0: 0x 0x 0x9300 0x00cf 0x 0x 0x9a00 0x
>>>>
>>>> Nevertheless doing stepi l
$eip
>>> 0x90e8: lgdtl 0x95d0
>>> (gdb) x/3xh 0x95d0
>>> 0x95d0: 0x003f 0x9590 0x
>>> (gdb) x/16xh 0x9590
>>> 0x9590: 0x 0x 0x 0x 0x 0x 0x9a00 0x00cf
>>> 0x95a0: 0x 0x0000 0x9300 0x00cf 0x 0x00
0x9a00 0x
>>
>> Nevertheless doing stepi leads to exactly the same triple fault.
>
>
> Is it because lgdt loads the GDT from the ds segment, and ds is now 33,
> not 0 (or equal to CS, I'm not sure which is correct here)?
Indeed, the DS segment was incorrect,
On Apr 23, 2013, at 23:46, Andriy Gapon wrote:
> on 23/04/2013 19:31 John Baldwin said the following:
>> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
...
>>> 0x90e8: lgdtl 0x95d0
>>> 0x90ef: ljmpw $0x18,$0x90f5
>>>
>>> Triple fault
>>> CPU Reset (CPU 0)
>
on 23/04/2013 19:31 John Baldwin said the following:
> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
>> on 23/04/2013 17:36 Dimitry Andric said the following:
>>> I have tried to ascertain it actually arrives at this code when
>>> rebooting from the load
On Tuesday, April 23, 2013 1:32:34 pm Andriy Gapon wrote:
> on 23/04/2013 19:09 Andriy Gapon said the following:
> >
> > IN:
> > 0x90d2: cli
> > 0x90d3: mov$0x1800,%esp
> > 0x90d8: mov%cr0,%eax
> > 0x90db: and$0x7f
On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
> on 23/04/2013 17:36 Dimitry Andric said the following:
> > I have tried to ascertain it actually arrives at this code when
> > rebooting from the loader, but it does not seem to ever make it there,
> > at least no
on 23/04/2013 19:09 Andriy Gapon said the following:
>
> IN:
> 0x90d2: cli
> 0x90d3: mov$0x1800,%esp
> 0x90d8: mov%cr0,%eax
> 0x90db: and$0x7fff,%eax
> 0x90e0: mov%eax,%cr0
>
>
>
on 23/04/2013 17:36 Dimitry Andric said the following:
> I have tried to ascertain it actually arrives at this code when
> rebooting from the loader, but it does not seem to ever make it there,
> at least not to the jump to f000:fff0. Maybe VMware intercepts the
> switching back to
#x27;s own
> >> instruction, hoping the bios catches it("tell the BIOS a boot failure,
> >> which may result in no effect"), or jumps to a location that I can't yet
> >> determine what code exists there. I can't seem to find OpenBSD's
cation that I can't yet
>> determine what code exists there. I can't seem to find OpenBSD's reboot
>> method from OpenBSD's cvsweb, only an exit but not where that exit leads
>> to. The native operating system is irrelevant, only the boot loader so
>
ither jumps to it's own
> instruction, hoping the bios catches it("tell the BIOS a boot failure,
> which may result in no effect"), or jumps to a location that I can't yet
> determine what code exists there. I can't seem to find OpenBSD's reboot
> met
I can't seem to find OpenBSD's reboot
method from OpenBSD's cvsweb, only an exit but not where that exit leads
to. The native operating system is irrelevant, only the boot loader so
all the Linux distributions and Solaris forks all count as "grub." Many
other bootloade
On Fri, Apr 19, 2013 at 05:49:34PM -0500, Joshua Isom wrote:
> Basically, the loader finds a simple safe way to reboot that's
> worked since the 286, and VMWare doesn't like it. It's called a
> triple fault. FreeBSD and Linux even use it to reboot as a fail
>
Basically, the loader finds a simple safe way to reboot that's worked
since the 286, and VMWare doesn't like it. It's called a triple fault.
FreeBSD and Linux even use it to reboot as a fail safe. Read
sys/i386/i386/vm_machdep.c and cpu_reset_real to see how FreeBSD handles
(Please keep me CC'd as I'm not subscribed to -hackers)
When running FreeBSD under VMware Workstation (I'm using 9.0.1, but this
issue has existed for many years now, I remember it occurring on
Workstation 6.x), the following is reproducible:
1. Power on + boot FreeBSD VM
2.
't have room to be but so smart. It can't parse a filesystem, so
> it
> just loads a raw partition assuming that the partition is the boot loader.
> The 545k bit has to do with where it is loaded. The boot loader has to live
> in the lower 640k, but it starts at 0x7c00 (the
reebsd-ufs (2.0G)
> > 4196386 12582912 3 freebsd-swap (6.0G)
> >16779298 959993837 4 freebsd-zfs (457G)
> >
> > I also did:
> > gpart bootcode -b /boot/pmbr ada0
> >
> > I'm trying to boot and get
> > Boot loade
On 22.01.2013 16:41, Daniel Braniss wrote:
> the source pmbr.s seems to say different - 545K, but since gptboot is 15k ...
> someone should mention it in the gpart(8) man page.
It is already documented in the gpart(8) man page, twice.
--
WBR, Andrey V. Elsukov
___
> > > 4196386 12582912 3 freebsd-swap (6.0G)
> > >16779298 959993837 4 freebsd-zfs (457G)
> > >=20
> > > I also did:
> > > gpart bootcode -b /boot/pmbr ada0
> > >=20
> > > I'm trying to boot and get
&g
reebsd-boot (1.0M)
> >20824194304 2 freebsd-ufs (2.0G)
> > 4196386 12582912 3 freebsd-swap (6.0G)
> >16779298 959993837 4 freebsd-zfs (457G)
> >
> > I also did:
> > gpart bootcode -b /boot/pmbr ada0
> >
> >
sd-zfs (457G)
>
> I also did:
> gpart bootcode -b /boot/pmbr ada0
>
> I'm trying to boot and get
> Boot loader too large
>
> not matter if I boot from disk or pxe.
> The pmbr is 512 bytes, so what causes it to overshoot?
> I don't know x86 assembl
wap (6.0G)
>16779298 959993837 4 freebsd-zfs (457G)
>
> I also did:
> gpart bootcode -b /boot/pmbr ada0
>
> I'm trying to boot and get
> Boot loader too large
>
> not matter if I boot from disk or pxe.
> The pmbr is 512 bytes, so what ca
0
I'm trying to boot and get
Boot loader too large
not matter if I boot from disk or pxe.
The pmbr is 512 bytes, so what causes it to overshoot?
I don't know x86 assembler (nor want to :-), but the comment says:
545k should be enough
so what's going on?
gt;> returns boolean based on multiple conditions (currently takes $console and
>> $boot_serial into consideration -- should be trivial to add a check for
>> boot_multicons).
>
> You're correct; boot -D is for after boot and this only affects loader(8):
>
>
on -- should be trivial to add a check for
> boot_multicons).
You're correct; boot -D is for after boot and this only affects loader(8):
-Dboot with the dual console configuration. In the
single configuration, the console will be eithe
On Dec 7, 2012, at 11:50 AM, Garrett Cooper wrote:
> On Fri, Dec 7, 2012 at 1:07 AM, Devin Teske wrote:
>
> ...
>
>> I've made some improvements to the supplied patch. Said improvements should
>> address the previous issues that were preventing this from going in.
>>
>> Can someone test the
On Fri, Dec 7, 2012 at 1:07 AM, Devin Teske wrote:
...
> I've made some improvements to the supplied patch. Said improvements should
> address the previous issues that were preventing this from going in.
>
> Can someone test the newly-attached patch.txt and get back to me?
The patch seems
On 2012-12-07, Devin Teske wrote:
> Can you re-test with the attached patch?
Works for me. Thanks!
http://people.freebsd.org/~jh/misc/menu-patched.png
--
Jaakko
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/fre
Thanks for testing Jaakko.
Can you re-test with the attached patch?
I cleaned things up a bit while addressing the problem that a later call to
f_double was un-doing the previous installation of the ASCII charset.
This new patch should work (and I re-tested, having had ample sleep this time).
-
On Sun, Feb 24, 2008 at 14:21:24 -0800, Jeremy Chadwick wrote:
>
> On Sun, Feb 24, 2008 at 02:01:14PM -0800, Jeremy Chadwick wrote:
> > ... I'll submit a PR for the whole thing. We can hash out
> > details/improvements there.
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=121064
>
I've made so
On Friday, October 19, 2012 7:05:05 pm Richard Yao wrote:
> Dear Everyone,
>
> I know that the kernel is a BTX client, but I do not understand the
> protocol used by loader to pass sysctl settings and loadable modules to
> the kernel. Is there documentation on this?
The loa
Dear Everyone,
I know that the kernel is a BTX client, but I do not understand the
protocol used by loader to pass sysctl settings and loadable modules to
the kernel. Is there documentation on this?
Yours truly,
Richard Yao
signature.asc
Description: OpenPGP digital signature
2012/8/2 Andrey V. Elsukov :
> On 02.08.2012 15:30, Sergey Listopad wrote:
>> Hi.
>>
>> I have as issue with booting FreeBSD on retro server.
>> loader(8) stuck during the boot (more details
>> http://docs.freebsd.org/cgi/mid.cgi?CAO_2TxM4_7YpPV9iTXeX6S7w4T1zqiZJa0
On 02.08.2012 15:30, Sergey Listopad wrote:
> Hi.
>
> I have as issue with booting FreeBSD on retro server.
> loader(8) stuck during the boot (more details
> http://docs.freebsd.org/cgi/mid.cgi?CAO_2TxM4_7YpPV9iTXeX6S7w4T1zqiZJa0ewe5KKiusdmNiVnw)
>
> How can I debug why loa
Hi.
I have as issue with booting FreeBSD on retro server.
loader(8) stuck during the boot (more details
http://docs.freebsd.org/cgi/mid.cgi?CAO_2TxM4_7YpPV9iTXeX6S7w4T1zqiZJa0ewe5KKiusdmNiVnw)
How can I debug why loader(8) is stuck. What information may be helpful?
Thanks.
--
S.Listopad
ut in the my branch ZFS tastes only
> disks and
> partitions with type "freebsd" and "freebsd-zfs". So if you have created ZFS
> on top
> of MBR partition with type "ntfs", then loader will be unable to detect it.
>
Sorry, I'm missing the big pictur
ly there is only one problem with ZFS tasting, that can affect users -
now we taste each disk and partition, but in the my branch ZFS tastes only
disks and
partitions with type "freebsd" and "freebsd-zfs". So if you have created ZFS on
top
of MBR partition with type "ntfs&qu
on 16/07/2012 14:14 Andrey V. Elsukov said the following:
> On 16.07.2012 15:05, Andriy Gapon wrote:
2. I am not sure if I like the approach of moving partition tasting code
into
common ZFS code (zfs.c). On one hand, it now makes sense because the new
partition iteration code
On 16.07.2012 15:05, Andriy Gapon wrote:
>>> 2. I am not sure if I like the approach of moving partition tasting code
>>> into
>>> common ZFS code (zfs.c). On one hand, it now makes sense because the new
>>> partition iteration code is machine-independent. On the other hand, the
>>> reason
>>>
ased:
>>> zfs/zfs.c
>>> i386/loader/main.c
>>
>> First of all, it's hard to parse the above sentence. "probing ... should be
>> greatly increased". Probing what? :-) If probing time, then we don't want
>> that ;-)
>
On 16.07.2012 14:23, Andriy Gapon wrote:
> on 26/06/2012 15:50 Andrey V. Elsukov said the following:
>> 3. ZFS code now uses new API and probing on the systems with many disks
>> should be greatly increased:
>> zfs/zfs.c
>> i386/loader/main.c
>
>
on 26/06/2012 15:50 Andrey V. Elsukov said the following:
> 3. ZFS code now uses new API and probing on the systems with many disks
> should be greatly increased:
> zfs/zfs.c
> i386/loader/main.c
First of all, it's hard to parse the above sentence. "probing
Pawel Jakub Dawidek wrote
in <20120628230725.gb1...@garage.freebsd.pl>:
pj> PS. We are discussing two totally different things here:
pj> 1. Is placing GPT on anything but raw disk violates the spec? I can
pj>agree that it does and I'm happy with gpart(8) growing a warning.
I agree that th
On Jun 28, 2012, at 4:07 PM, Pawel Jakub Dawidek wrote:
>>
>> I would be having less problems if the mirroring didn't force the backup
>> GPT header in anything but the last sector. [...]
>
> GPT backup header is placed in the last sector of the mirror device,
> just like the user asked. Gmirror
ou would complain that it keeps metadata where the primary header
should be located and also MBR metadata, BSDlabel metadata, etc.
Somewhere in the middle of the disk? Some future GPTng may want to use
the same spot, but also gmirror-unaware boot loader will see corrupted
data (shifted by one sect
roblems are expected if the disk is
shared between other OSes.
In my opinion that's fair.
With such a warning in place, I think we can allow users to decide on
their own if they really want that or not. Then, we can also improve
FreeBSD boot loader to play nice with FreeBSD-specific extension
On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote:
> On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar
> wrote:
>
>> My advise is to leave disk mirroring to H/W or firmware solutions and
>> use FreeBSD mirroring for FreeBSD partitions only. If you want to
>> mirror the whole disk, don't
On Jun 28, 2012, at 10:25 AM, Pawel Jakub Dawidek wrote:
> On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote:
>>
>> On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote:
>>>
>>> All of the above is ugly, U'm afraid :(
>>
>> Indeed. The only sane way is to put the metadata in a partit
On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar
wrote:
> My advise is to leave disk mirroring to H/W or firmware solutions and
> use FreeBSD mirroring for FreeBSD partitions only. If you want to
> mirror the whole disk, don't partition the disk with non-FreeBSD
> partitioning schemes and part
uration is non-standard and problems are expected if the disk is
shared between other OSes.
In my opinion that's fair.
With such a warning in place, I think we can allow users to decide on
their own if they really want that or not. Then, we can also improve
FreeBSD boot lo
These schemes to just put the metadata in some special location
and have all the tools know about it create a lot of problems.
There is always some tool that doesn't know. There is always
some human that doesn't know. Telling the difference between
real metadata and some other data that happens to
On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote:
>
> All of the above is ugly, U'm afraid :(
Indeed. The only sane way is to put the metadata in a partition of its own.
Every compliant OS will respect that and consequently will not scribble over
the data unintentionally. Any other scheme that pu
On 28.06.2012 14:35, Wojciech Puchar wrote:
>> Just modify GEOM classes that keep state at the end of a partition to
>> leave some spare area *behind* the GEOM data. I.e.:
>>
>
> what is really a problem aat all?
>
> just leave as is. If someone want's use gpart and mirror then mirroring every
>
Just modify GEOM classes that keep state at the end of a partition to
leave some spare area *behind* the GEOM data. I.e.:
what is really a problem aat all?
just leave as is. If someone want's use gpart and mirror then mirroring
every partition is simpler. usually not every partition needs to
On Wed, Jun 27, 2012 at 2:39 PM, Poul-Henning Kamp wrote:
>
> I would like to point out that all other operating system which has
> had this precise problem, have solved it by adding a bootfs partition
> to hold the kernel+modules required to truly understand the disk-layout ?
I have seen some fo
Sorry for following up to self, but ...
I just noticed somebody else suggesting the same method
(put GMIRROR configuration below Secondary GPT header),
but I think there is a problem:
If GMIRROR is used to mirror whole GPT partitioned drives,
then you want the GPT sectors to be considered part of
Am 27.06.2012 21:14, schrieb Marcel Moolenaar:
>
> On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote:
>
>> On 06/27/12 16:28, John Baldwin wrote:
>>> On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote:
>>>
>>>> When we are in the Fr
I would like to point out that all other operating system which has
had this precise problem, have solved it by adding a bootfs partition
to hold the kernel+modules required to truly understand the disk-layout ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | T
On Jun 27, 2012, at 1:48 PM, Andrey V. Elsukov wrote:
> On 28.06.2012 00:14, Marcel Moolenaar wrote:
>>> Our loader detects that primary GPT header is damaged. It tries to read
>>> backup GPT header from the last LBA and it detects that there is
>>> "GEOM
On 28.06.2012 00:14, Marcel Moolenaar wrote:
>> Our loader detects that primary GPT header is damaged. It tries to read
>> backup GPT header from the last LBA and it detects that there is
>> "GEOM::" signature. It tries to read one previous sector and there is
>&g
ed (no mirroring, warning messages about corrupted GPT, etc) for
>> no apparent reason and without any kind of warning that what he/she is doing
>> is potentially harmful... That's the spirit!
>
> Ok. Let's return back to my patches. They don't add any new methods
On Tue, 26 Jun 2012 12:37:11 -0500, John Baldwin wrote:
I'm
hesitant to encourage the use of this as I do think putting GPT inside
of a
gmirror violates the GPT spec.
I personally think this use case is a bit ... odd, anyway.
I have only request to those that manage GPT/GEOM/etc -- as I'm
rning that what he/she is doing
> is potentially harmful... That's the spirit!
Ok. Let's return back to my patches. They don't add any new methods to
shoot in the foot. We are talking about the *FreeBSD loader*.
This is the program that starts FreeBSD kernel. It doesn't sta
On Jun 27, 2012, at 12:08 PM, Christian Laursen wrote:
> On 06/27/12 16:28, John Baldwin wrote:
>> On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote:
>>
>>> When we are in the FreeBSD, our loader can detect that device size
>>> is lower than it s
On Wednesday, June 27, 2012 1:45:35 pm Marcel Moolenaar wrote:
>
> On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote:
> >
> > As for sharing disk with other OS. If you share the disk with OS that
> > doesn't support gmirror, you shouldn't use gmirror in the first place.
> > You probably want
On Jun 27, 2012, at 11:20 AM, Pawel Jakub Dawidek wrote:
> On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote:
>>
>> On Jun 26, 2012, at 10:37 AM, John Baldwin wrote:
>>>
>>> GPT really wants the backup header at the last LBA. I know you can set it,
>>> but I've interpreted that
On 2012-06-26 14:50, Andrey V. Elsukov wrote:
> Some time ago i have started reading the code in the sys/boot.
> Especially i'm interested in the partition tables handling.
> I found several problems:
> 1. There are several copies of the same code in the libi386/biosdisk.c
> and common/disk.c, and
On 06/27/12 16:28, John Baldwin wrote:
On Wednesday, June 27, 2012 8:45:45 am Andrey V. Elsukov wrote:
When we are in the FreeBSD, our loader can detect that device size
is lower than it see and it will work. When primary header is OK, then
other OSes should work with this GPT. When it isn&#
On Jun 27, 2012, at 11:34 AM, Pawel Jakub Dawidek wrote:
>
> I'm sorry, Marcel, but what you describe here has nothing to do with
> reality. To be able to implement realiable mirroring you have to use
> on-disk metadata. There is no way around that. You can implement
> non-redundant GEOM classes
On Wed, Jun 27, 2012 at 10:45:35AM -0700, Marcel Moolenaar wrote:
>
> On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote:
> >
> > As for sharing disk with other OS. If you share the disk with OS that
> > doesn't support gmirror, you shouldn't use gmirror in the first place.
> > You probably w
On Wed, Jun 27, 2012 at 10:37:11AM -0700, Marcel Moolenaar wrote:
>
> On Jun 26, 2012, at 10:37 AM, John Baldwin wrote:
> >
> > GPT really wants the backup header at the last LBA. I know you can set it,
> > but I've interpreted that as a way to see if the primary header is correct
> > or
> >
eated as disk device.
> So, i don't see anything criminal if we will add some quirks in the our loader
> for the better supporting of our technologies.
You can't just re-interpret standards to match a context you know very well
isn't applicable and consequently redefine
On Jun 26, 2012, at 2:43 PM, Pawel Jakub Dawidek wrote:
>
> As for sharing disk with other OS. If you share the disk with OS that
> doesn't support gmirror, you shouldn't use gmirror in the first place.
> You probably want to use only formats that are recognized by all your
> OSes.
This statemen
On Jun 26, 2012, at 10:37 AM, John Baldwin wrote:
>
> GPT really wants the backup header at the last LBA. I know you can set it,
> but I've interpreted that as a way to see if the primary header is correct or
> not. It seems to me that GPT tables created in this fashion (inside a GEOM
> prov
ce to see if it has a
> >> valid GPT Header and point to a valid GPT Partition Entry Array."
> >
> > Right, we break the last rule. If you want to use a partition editor
> > that doesn't grok gmirror (because you are using another OS's editor),
> >
...] The same
> > is even true of the "software" RAID that graid supports since the metadata
> > is defined by the vendor and thus the logical volume is always seen other
> > OS's consistently.
>
> But is it seen without metadata by the boot loader?
Yes. The log
> [...] The same
> is even true of the "software" RAID that graid supports since the metadata
> is defined by the vendor and thus the logical volume is always seen other
> OS's consistently.
But is it seen without metadata by the boot loader?
What I'm trying to sa
; Right, we break the last rule. If you want to use a partition editor
> that doesn't grok gmirror (because you are using another OS's editor),
> to repair a GPT, it will do the wrong thing.
When we are in the FreeBSD, our loader can detect that device size
is lower than it see and i
On Tuesday, June 26, 2012 5:23:08 pm Pawel Jakub Dawidek wrote:
> On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote:
> > > 4. The gptboot now searches the backup GPT header in the previous sectors,
> > > when it finds the "GEOM::" signature in the last sector. PMBR code also
> > > tries
the last LBA.
> >> 5. Also the pmbr image now contains one fake partition record.
> >> When several first sectors are damaged the kernel can't detect GPT
> >> (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1)
> >> command, but the old pmb
on 27/06/2012 07:50 Andrey V. Elsukov said the following:
> Also we still haven't any tool to install zfsboot.
Yeah, I think it would be nice if ZFS provided some interface (ioctl?) to
properly write stuff to its special areas.
--
Andriy Gapon
___
free
On 27.06.2012 1:41, Kevin Oberman wrote:
> Long ago I saw a proposal to create a dedicated partition on GPT to
> hold the metadata. With the large number of partitions available on
> GPT, tying up one just for GEOM seems like a low price and it moves
> the device GEOM out of the realm of FreeBSD un
re must check the last LBA of the device
to see if it has a
valid GPT Header and point to a valid GPT Partition Entry Array."
For the FreeBSD an each GEOM provider can be treated as disk device.
So, i don't see anything criminal if we will add some quirks in the our loader
for the bet
On Tue, Jun 26, 2012 at 2:23 PM, Pawel Jakub Dawidek wrote:
> On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote:
>> > 4. The gptboot now searches the backup GPT header in the previous sectors,
>> > when it finds the "GEOM::" signature in the last sector. PMBR code also
>> > tries to do
On Tue, Jun 26, 2012 at 02:41:31PM -0700, Kevin Oberman wrote:
> Long ago I saw a proposal to create a dedicated partition on GPT to
> hold the metadata. With the large number of partitions available on
> GPT, tying up one just for GEOM seems like a low price and it moves
> the device GEOM out of t
On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote:
> > 4. The gptboot now searches the backup GPT header in the previous sectors,
> > when it finds the "GEOM::" signature in the last sector. PMBR code also
> > tries to do the same:
> > common/gpt.c
> > i386/pmbr/pmbr.s
>
ch is here:
> http://people.freebsd.org/~ae/boot.diff
>
> What i already did:
> 1. The partition tables handling now is machine independent,
> and it is compatible with the kernel's GEOM_PART implementation.
> There is new API for disk drivers in the loader to get
ion. I did implement support for both CRC checksum
> > verification and fallback to backup GPT header when primary is broken.
> > And the code is still in sys/boot/common/gpt.c. So my question would be
> > what do you mean by this sentence?
>
> Yes, gptboot does that, but the
in sys/boot/common/gpt.c. So my question would be
> what do you mean by this sentence?
Yes, gptboot does that, but the loader/zfsloader doesn't. So there might
be a situation when gptboot does boot, but loader(8) can't.
--
WBR, Andrey V. Elsukov
signature.asc
Description: OpenPGP digital signature
ed the changes:
> http://svnweb.freebsd.org/base/user/ae/bootcode/
> The patch is here:
> http://people.freebsd.org/~ae/boot.diff
>
> What i already did:
> 1. The partition tables handling now is machine independent,
> and it is compatible with the kernel's GEOM_P
and it is compatible with the kernel's GEOM_PART implementation.
There is new API for disk drivers in the loader to get information
about partitions and tables:
common/Makefile.inc
common/part.c
common/part.h
2. The similar and general code from the disk dri
nslations.
> ... if you'd like to modify the blob in a major way you need to relocate it
> into a new location with more padding …. create a DTB metadatum (as if the
> DTB was loaded dynamically from standalone blob file) with sufficient space,
> …. and pass this new copy (as
it accordingly. This won't be
possible however with the statically embedded DTB in the kernel as you cannot
grow this space easily. The way to go here would be to create a DTB metadatum
(as if the DTB was loaded dynamically from standalone blob file) with
sufficient space, reloc
On May 12, 2012, at 4:36 PM, Tim Kientzle wrote:
>
> On May 10, 2012, at 5:32 AM, Marcel Moolenaar wrote:
>
>> On May 8, 2012, at 1:32 AM, Tim Kientzle wrote:
>>>
>>> On the AM3358, the DRAM starts at 0x8000
>>> on boot, so I'm trying to find a clean way to convince
>>> the loader's ELF cod
On May 10, 2012, at 5:32 AM, Marcel Moolenaar wrote:
>
> On May 8, 2012, at 1:32 AM, Tim Kientzle wrote:
On i386, amd64, powerpc, and arm, loadimage subtracts
the dest value from the address declared in the actual ELF
headers so that the kernel always gets loaded into low memory.
On May 8, 2012, at 1:32 AM, Tim Kientzle wrote:
>>> On i386, amd64, powerpc, and arm, loadimage subtracts
>>> the dest value from the address declared in the actual ELF
>>> headers so that the kernel always gets loaded into low memory.
>>> (there's some intermediate bit-twiddling I'm glossing ove
On May 8, 2012, at 2:39 AM, Andrew Turner wrote:
> On Mon, 7 May 2012 22:32:10 -0700
> Tim Kientzle wrote:
>
>>
>> On May 7, 2012, at 6:57 AM, John Baldwin wrote:
>>>
>>> The bit twiddling is supposed to be the equivalent of subtracting
>>> KERNBASE from the load address. On both i386 and am
1 - 100 of 533 matches
Mail list logo
