From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vivien Kraus Subject: bug#35858: Null pointer error when partitioning with the graphical installer Date: Tue, 28 May 2019 21:30:52 +0200 Message-ID: <1559071852.4335.91.camel@planete-kraus.eu> References: <87sgt61fu6.fsf@planete-kraus.eu> <87ftoyy68p.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:37597) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVhpN-0002bx-TT for bug-guix@gnu.org; Tue, 28 May 2019 15:32:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hVhpK-0002rQ-Jk for bug-guix@gnu.org; Tue, 28 May 2019 15:32:05 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:43643) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hVhpK-0002qg-Bg for bug-guix@gnu.org; Tue, 28 May 2019 15:32:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hVhpK-000477-5f for bug-guix@gnu.org; Tue, 28 May 2019 15:32:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87ftoyy68p.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: Mathieu Othacehe , 35858@debbugs.gnu.org (Please pardon me for the duplicate) Hello, Thank you for your answer. > Can you confirm that the backtrace you posted comes from 1.0.1 and not > 1.0.0?  (It seems to be from 1.0.1 accordingly to the line numbers, but > better be on the safe side.) After backing up my data, I re-downloaded the guix image from the website, burnt it, and booted it.  The boot screen reads "1.0.1-1.8204295". I also had an error during the loading with an error in finalization thread: Bad file descriptor (twice, reproducible) but no additional info, right after ssh-keygen.  Is there a log file for that?  I had very little time to catch it. > Is it 100% reproducible for you? Except for the bytestructures (but with the same loop at 863:17), I reproduced it 4/4 times with a full reboot, and 4/4 times without a full reboot. > Does the problem occur when you choose the “manual partitioning” method > instead of “guided partitioning”? So I use the same language and such and select the manual partitioning: I get to a screen with the 3 partitions already present on my 1.5T disk:  - 1 537MB fat32 boot,esp /boot/efi  - 2 256MB ext2  - 3 1500GB If I select the second partition, I get another reproducible (2/2 with full reboot) backtrace: In .gnu/installer/steps.scm:        189:6 19 (run-installer-steps #:steps _ #:rewind-strategy _  #:menu-proc _) In ice-9/boot-9.scm:     829:9 18 (catch srfi-34 # # _)     829:9 17 (catch srfi-34 # # _)     829:9 16 (catch srfi-34 # # _)     829:9 15 (catch srfi-34 # # _)     829:9 14 (catch srfi-34 # # _) In ./gnu/installer/steps.scm:    182:21 13 (_) In ./gnu/installer/newt/partition.scm:    762:40 12 (run-partitioning-page)    668:10 11 (run-disk-page (#< bytestructure: #>) _ #:guided? _) In ./gnu/installer/newt/page.scm:    397:21 10 (run-listbox-selection-page #:info-text _ #:title _ #:info-textbox-width _ #:listbox-items _ #:listbox-item->text _ #:listbox-height _ #:listbox-default-item _ # _ # _ #:allow-delete? ...) In ./gnu/installer/newt/partition.scm:    640:20 9 (listbox-action _) In ./gnu/installer/parted.scm:    317:18 8 (partition->user-partition #< bytestructure: #>) In unknown file:            7 (scm-error misc-error #f "~A" ("Unhandled ext2 fs-type\n") #f) In ice-9/boot-9.scm:    751:25  6 (dispatch-exception 5 misc-error (#f "~A" ("Unhandled ext2 fs-type\n") #f)) In ice-9/eval.scm:     619:8  5 (_ #(#(# #< name: newt init: # exit: # exit-error: # final-...>) ...))     619:8  4 (_ #(#(#(# #< name: newt init: # exit: # exit-error: # f...>) ...) #)) In ice-9/ports.scm:    462:17  3 (call-with-output-file _ _ #:binary _ #:encoding _) In ice-9/eval.scm:     619:8  2 (_ #(#(# misc-error (#f "~A" ("Unhandled ext2 fs-type\n") #f)) #))     159:9 1 (_ #(#(# misc-error (#f "~A" ("Unhandled ext2 fs-type\n") #f)) #)) In unknown file:            0 (make-stack #t) ice-9/eval.scm:159:9: Unhandled ext2 fs-type I've managed to avoid the problem with a manual partitioning procedure, selecting my hard drive, selecting "gpt" to get rid of the existing ext2 partition. Then I go to create a single root partition (with the idea of re-installing guix with the default cryptsetup options once the ext2 partition is forgotten), but then I get another "null pointer dereference" exception -- this one is longer :( In ice-9/boot-9.scm:     829:9 19 (catch _ _ # _)     829:9 18 (catch _ _ # _)     829:9 17 (catch _ _ # _) In ./gnu/installer/steps.scm:    182:21 16 (_) In ./gnu/installer/newt/partition.scm:    763:40 15 (run-partitioning-page)    714:40 14 (run-disk-page _ _ #:guided? _)    429:10 13 (run-partition-page _ #:default-item _) In ./gnu/installer/newt/page.scm:    384:15 12 (run-listbox-selection-page #:info-text _ #:title _ #:info-textbox-width _ #:listbox-items _ #:listbox-item->text _ #:listbox-height _ #:listbox-default-item _ # _ # _ #:allow-delete? ...) In ./gnu/installer/newt/partition.scm:    400:23 11 (button-action) In ./gnu/installer/parted.scm:    771:25 10 (mkpart #< bytestructure: #> _ #:previous-partition _) In parted/structs.scm:    552:19  9 (pointer->partition _)     132:3  8 (pointer->bytestructure _ #) In unknown file:            7 (pointer->bytevector # 88 # #) In ice-9/boot-9.scm:    751:25  6 (dispatch-exception 5 null-pointer-error ("pointer->bytevector" "null pointer dereference" () ())) In ice-9/eval.scm:     619:8  5 (_ #(#(# #< name: newt init: # exit: # exit-error: # final-...>) ...))     619:8  4 (_ #(#(#(# #< name: newt init: # exit: # exit-error: # f...>) ...) #)) In ice-9/ports.scm:    462:17  3 (call-with-output-file _ _ #:binary _ #:encoding _) In ice-9/eval.scm:     619:8  2 (_ #(#(# null-pointer-error ("pointer->bytevector" "null pointer dereference" () ())) #))     159:9  1 (_ #(#(# null-pointer-error ("pointer->bytevector" "null pointer dereference" () ())) #)) In unknown file:            0 (make-stack #t) ice-9/eval.scm:159:9: In procedure pointer->bytevector: null pointer dereference I reboot and the partition table is erased (good thing I updated my backups just before the operation ;) less so that I don't have an operating system on my main computer and have to use this one :( However, selecting the automatic method for whole disk encryption still gives the first error, and trying to add a partition manually gives the second. > > Could you post the output of “fdisk -l /dev/sda” (hit Ctrl-Alt-F3 and > run that command)? I wanted to give it before the GPT erasure but I thought I could save it to / on the Guix installer, and it did not work.  So I only have the log after the procedure: Disk /dev/ram0: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes (repeat exactly this for /dev/ram1 to /dev/ram15) Disk /dev/sda: 1.4 TiB, 1500301910016, 2930277168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: D8D62D0Aè7272-425E-A46A-8FC7275FD65C Disk /dev/sdb: 3.8 GiB, 4009754624 bytes, 7831552 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical / physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 30373931-3130-4130-B138-333934393436 Device       Start     End Sectors  Size Type /dev/sdb1       64   43839   43776 21.4M Microsoft basic data /dev/sdb2    43840   49599    5460  2.8M EFI System /dev/sdb3    49600 2693755 2644156  1.3G Apple HFS/HFS+ /dev/sdb4  2693756 2694355     600  300K Microsoft basic data And here is the error that came with it in red: GPT PMBR size mismatch (2694403 != 7831551) will be corrected by write. The backup GPT table is corrupt, but the primary appears OK, so that will be used. The backup GPT table is not on the end of the device. This problem will be corrected by write. I remember that a similar error happened when I had the previous GPT table, but I don't remember the exact wording.  So maybe there is still a backup of the GPT table that still has the ext2 partition? Anyways, I have saved all my data and have a rainy-days computer at hand, so the situation is not so bad.