https://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082009-06-23T05:11:47ZDragonFlyBSD bugtrackerDragonFlyBSD - Bug #1407: disklabel64 boot problemhttps://bugs.dragonflybsd.org/issues/1407?journal_id=67732009-06-23T05:11:47Zcorecode
<ul></ul><p>Matthew Dillon wrote:</p>
<blockquote>
<p>:Booting DragonFly from disklabel64 slice has problems:<br />: - using HAMMER it almost works: one module can't be read<br />:Reading /modules/acpi.ko fails; after booting (host can run without ACPI)<br />:(i.e. by kernel) acpi.ko can be read and contents is correct.<br />:(files on test HAMMER system are just cpdup'ed from a working system;<br />:cmp verified acpi.ko is readable and has same contents)</p>
<p>It sounds like the hammer fs read code in the boot loader isn't<br />handling all the cases properly.</p>
</blockquote>
<p>Yes, we should try and fix that. Thomas, can you compile hammerread.c <br />and try to find out why it is having a problem?</p>
<blockquote>
<p>I'm going to be blunt on the HAMMER boot thing... I don't actually<br />like the idea, because the boot code can't run the UNDO's after a<br />crash and so might not be able to find the kernel and other boot<br />related files. I would rather just boot from a small UFS /boot<br />partition and then have the kernel mount HAMMER as the root.</p>
<p>I guess I'll have to deal with changing the installer to create a<br />BOOT+HAMMER setup instead of a straight HAMMER setup.</p>
</blockquote>
<p>However so far nobody had problems since we fixed the last bugs. I <br />absolutely agree that we should have the boot code reading the UNDO, and <br />also multi-volume HAMMER file systems will not work with the boot loader <br />(will never). However I think for a simple setup, having just one <br />HAMMER file system should be supported and perfectly fine.</p>
<p>But then, maybe I'm too much an HAMMER enthusiast, and we should go the <br />Linux route and always install a (UFS) /boot. Then it is also easier to <br />run more complex setups, like vinum, ccd, etc.</p>
<p>cheers<br /> simon</p> DragonFlyBSD - Bug #1407: disklabel64 boot problemhttps://bugs.dragonflybsd.org/issues/1407?journal_id=67742009-06-23T14:37:14Zftigeot
<ul></ul><p>On Mon, Jun 22, 2009 at 07:28:20PM -0700, Matthew Dillon wrote:</p>
<blockquote>
<p>:But then, maybe I'm too much an HAMMER enthusiast, and we should go the <br />:Linux route and always install a (UFS) /boot. Then it is also easier to <br />:run more complex setups, like vinum, ccd, etc.<br />:<br />There are a few other things I'd like to get done for this release.<br />Sacha has kindly taken on adding a BOOT+HAMMER feature to the<br />installer. I will take on fixing up fdisk to handle multi-terrabyte<br />disks. Right now it wraps the 32 bit logical block length instead<br />of assigning the max value (0xFFFFFFFF), and our slice code in the<br />kernel doesn't translate the max-value into the actual disk size<br />which makes disklabel believe that the disk is smaller then it actually</p>
</blockquote>
<p>What about gpt ? I had the impression it was meant to replace fdisk for big<br />storage volumes...</p> DragonFlyBSD - Bug #1407: disklabel64 boot problemhttps://bugs.dragonflybsd.org/issues/1407?journal_id=67762009-06-24T03:11:12Zftigeot
<ul></ul><p>On Tue, Jun 23, 2009 at 10:47:56AM -0700, Matthew Dillon wrote:</p>
<blockquote>
<p>:What about gpt ? I had the impression it was meant to replace fdisk for big<br />:storage volumes...</p>
<p>Many BIOSes (most, probably) do not understand GPT slices and<br />can't boot from it.</p>
<p>I'm sure this will change but adoption has been very slow.</p>
</blockquote>
<p>I was thinking about gpt(8): the program, not the on-disk structure itself.<br />It is able to create a special /boot mbr slice for old bioses and still address<br />more than 2TB for all the rest.</p>
<p>Shouldn't this be used instead of fdisk(8) in the future ?</p> DragonFlyBSD - Bug #1407: disklabel64 boot problemhttps://bugs.dragonflybsd.org/issues/1407?journal_id=68712009-07-16T06:05:54Zdillon
<ul></ul><p>:<br />:New submission from Thomas Nikolajsen <<a class="email" href="mailto:thomas.nikolajsen@mail.dk">thomas.nikolajsen@mail.dk</a>>:<br />:<br />:Booting DragonFly from disklabel64 slice has problems:<br />: - using HAMMER it almost works: one module can't be read<br />:Reading /modules/acpi.ko fails; after booting (host can run without ACPI)<br />:(i.e. by kernel) acpi.ko can be read and contents is correct.<br />:(files on test HAMMER system are just cpdup'ed from a working system;<br />:cmp verified acpi.ko is readable and has same contents)</p>
<pre><code>It sounds like the hammer fs read code in the boot loader isn't<br /> handling all the cases properly.</code></pre>
<p>:Also doing ls command in loader on HAMMER file system can crash loader.<br />:It seems like libstand/hammerread has an issue.<br />:<br />: - using UFS it doesn't work: I just see a spinning bar<br />:It doesn't show any text, like BTX..<br />:<br />:I had the impression that disklabel64 booting should be working<br />:(since commits below); is this correct?</p>
<pre><code>UFS should work.</code></pre>
<p>:Is zeroing slice start before making bootable disklabel still needed?<br />:If yes: is it enough to zero 16KB, like disklabel32.</p>
<pre><code>Zeroing is still needed.</code></pre>
<p>:I was going to update disklabel64.8 to include boot info again;<br />:but will hold it back until this issue is resolved.</p>
<pre><code>I'm going to be blunt on the HAMMER boot thing... I don't actually<br /> like the idea, because the boot code can't run the UNDO's after a<br /> crash and so might not be able to find the kernel and other boot<br /> related files. I would rather just boot from a small UFS /boot<br /> partition and then have the kernel mount HAMMER as the root.</code></pre>
<pre><code>I guess I'll have to deal with changing the installer to create a<br /> BOOT+HAMMER setup instead of a straight HAMMER setup.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1407: disklabel64 boot problemhttps://bugs.dragonflybsd.org/issues/1407?journal_id=68722009-07-16T06:05:55Zdillon
<ul></ul><p>:However so far nobody had problems since we fixed the last bugs. I <br />:absolutely agree that we should have the boot code reading the UNDO, and <br />:also multi-volume HAMMER file systems will not work with the boot loader <br />:(will never). However I think for a simple setup, having just one <br />:HAMMER file system should be supported and perfectly fine.<br />:<br />:But then, maybe I'm too much an HAMMER enthusiast, and we should go the <br />:Linux route and always install a (UFS) /boot. Then it is also easier to <br />:run more complex setups, like vinum, ccd, etc.<br />:<br />:cheers<br />: simon</p>
<pre><code>I'm also a bit worried about BIOS addressability with large disks.<br /> If someone installs a terrabyte disk with HAMMER on it, hammerread<br /> might have to access very high numbered sectors. I don't trust the<br /> BIOS to properly use 48-bit sector addressing.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1407: disklabel64 boot problemhttps://bugs.dragonflybsd.org/issues/1407?journal_id=68732009-07-16T06:05:56Zdillon
<ul></ul><p>Another interesting issue here which I really think puts the nail in<br /> coffin is that we really want to be able to use more complex access<br /> schemes, such as vinum, for these large filesystems. I don't want to<br /> have to depend on something like the BIOS fake-raid, its just too severely<br /> limiting.</p>
<pre><code>With a small UFS /boot we can make the primary root filesystem whatever<br /> we want... from multi-volume mounts to vinum or any other scheme we<br /> choose, including eventually mounts named by serial number.</code></pre>
<pre><code>The more I think about it, the more I really want us to default to<br /> a small UFS /boot. Here's another example... lets say we wanted to<br /> support encrypted disks. The information on the UFS /boot would not<br /> have to be encrypted per-say, since it's just a tiny boot-only partition<br /> containing no production data. It could, however, contain sufficient<br /> information to allow the system to auto-boot the encrypted root disk.</code></pre>
<pre><code>For example, the /boot booted kernel could query the local environment,<br /> such as the network, and acquire sufficient information to mount its<br /> encrypted root.</code></pre>
<pre><code>--</code></pre>
<pre><code>If we reserved space for a /boot by default on every disk we disklabel,<br /> it could lead to some fairly impressive booting and recovery options.<br /> I'd like it to be the new concept for the 'a' partition. Make 'a'<br /> <strong>always</strong> be a small /boot partition.</code></pre>
<pre><code>-Matt</code></pre> DragonFlyBSD - Bug #1407: disklabel64 boot problemhttps://bugs.dragonflybsd.org/issues/1407?journal_id=68742009-07-16T06:05:58Zdillon
<ul></ul><p>:But then, maybe I'm too much an HAMMER enthusiast, and we should go the <br />:Linux route and always install a (UFS) /boot. Then it is also easier to <br />:run more complex setups, like vinum, ccd, etc.<br />:<br />:cheers<br />: simon</p>
<pre><code>I think you're more enthusiastic about a HAMMER-only install then I<br /> am :-). To me, UFS1 is a perfectly fine filesystem... for small<br /> partitions. There's no reason to throw it away.</code></pre>
<pre><code>The biggest problem I see with trying to put too much intelligence in<br /> the boot code is simply that there is no way for it to keep up with<br /> the kind of intelligence we can put into the kernel. It's a lot easier<br /> to implement new and cool filesystem / mounting / vinum / etc features<br /> with a full-fledged kernel running.</code></pre>
<pre><code>The partition naming scheme also looks a lot more natural if we make<br /> 'a' the small boot partition, leave 'b' as swap, and make 'd' the<br /> root mount and rest of the disk (for a BOOT+HAMMER install). That way<br /> swap space can stay on the much higher bandwidth outer rim of the disk<br /> without us having to intentionally mis-order the partition offsets.</code></pre>
<pre><code>There are a few other things I'd like to get done for this release.<br /> Sacha has kindly taken on adding a BOOT+HAMMER feature to the<br /> installer. I will take on fixing up fdisk to handle multi-terrabyte<br /> disks. Right now it wraps the 32 bit logical block length instead<br /> of assigning the max value (0xFFFFFFFF), and our slice code in the<br /> kernel doesn't translate the max-value into the actual disk size<br /> which makes disklabel believe that the disk is smaller then it actually<br /> is. This doesn't matter so much for add-on disks but it does for<br /> boot disks where the BIOS is expecting a slice table, yet we want the<br /> disklabel to be able to make full use of the actual size of the disk. </code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1407: disklabel64 boot problemhttps://bugs.dragonflybsd.org/issues/1407?journal_id=68752009-07-16T06:05:59Zdillon
<ul></ul><p>:What about gpt ? I had the impression it was meant to replace fdisk for big<br />:storage volumes...<br />:<br />:-- <br />:Francois Tigeot</p>
<pre><code>Many BIOSes (most, probably) do not understand GPT slices and<br /> can't boot from it.</code></pre>
<pre><code>I'm sure this will change but adoption has been very slow.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1407: disklabel64 boot problemhttps://bugs.dragonflybsd.org/issues/1407?journal_id=68762009-07-16T06:06:00Zdillon
<ul></ul><p>:On Tue, Jun 23, 2009 at 10:47:56AM <del>0700, Matthew Dillon wrote:<br />:> <br />:> :What about gpt ? I had the impression it was meant to replace fdisk for big<br />:> :storage volumes...<br />:> <br />:> Many BIOSes (most, probably) do not understand GPT slices and<br />:> can't boot from it.<br />:> <br />:> I'm sure this will change but adoption has been very slow.<br />:<br />:I was thinking about gpt(8): the program, not the on-disk structure itself.<br />:It is able to create a special /boot mbr slice for old bioses and still address<br />:more than 2TB for all the rest.<br />:<br />:Shouldn't this be used instead of fdisk(8) in the future ?<br />:<br />:-</del> <br />:Francois Tigeot</p>
<pre><code>It has a mbr compat feature but BIOSes often can't deal with it. i.e.<br /> it isn't as compatible as was originally intended.</code></pre>
<pre><code>-Matt<br /> Matthew Dillon <br /> &lt;<a class="email" href="mailto:dillon@backplane.com">dillon@backplane.com</a>&gt;</code></pre> DragonFlyBSD - Bug #1407: disklabel64 boot problemhttps://bugs.dragonflybsd.org/issues/1407?journal_id=110392012-10-08T07:08:28Zthomas.nikolajsen
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>Assignee</strong> deleted (<del><i>0</i></del>)</li></ul><p>(don't remember why I kept this one open)</p>