Op maandag 4 september 2017 14:28:24 CEST schreef u:

On 04.09.17 11:49, Freek de Kruijf wrote:

...

I used the latest JeOS image 2017.05.23-Build1.1 for the RPi1 (armv6l) on a SD card and booted the system, which went OK.

After that I did a "zypper dup --no-recommends" on that system which, at the end, shows the following message:

Output of grub2-arm-uboot-2.02-6.1.armv6hl.rpm %posttrans script: update-bootloader: 2017-09-04 11:31:09 <3> update-bootloader-1244

run_command.274: '/usr/lib/bootloader/grub2-efi/install' failed with exit code> 1, output: <<<<<<<<<<<<<<<< target = arm-efi ls: cannot access '/sys/firmware/efi/efivars': No such file or directory + /usr/sbin/grub2-install --target=arm-efi --no-nvram --removable Installing for arm-efi platform.

Can you try to run this command on its own? If it still fails, run it with strace -f and upload the output somewhere (or look at it and search for failures)?

Thanks!

Alex

The RPi1 is not EFI system, so I wonder why the target should be arm-efi. # /usr/sbin/grub2-install --target=arm-efi --no-nvram --removable Installing for arm-efi platform. /usr/sbin/grub2-install: error: cannot find a GRUB drive for /dev/mmcblk0p2. Check your device.map. # more /boot/grub2/device.map (hd0) /dev/disk/by-id/mmc-SDC_0x49910339 # ls /dev/disk/by-id/ mmc-SDC_0x49910339 mmc-SDC_0x49910339-part1 mmc-SDC_0x49910339-part2 mmc- SDC_0x49910339-part3 When running yast in ncurses to change the bootloader without any update I also get the same error message: Error Execution of command "[["/usr/bin/grub2-editenv", "list"]]" failed. Exit code: 1 Error output: /usr/bin/grub2-editenv: error: cannot find a GRUB drive for / dev/mmcblk0p2. Check your device.map. I am able to continue and I get the default "GRUB for EFI", which I change for GRUB2 After that I get the message: Error Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Details: unsuported architecture arm Caller: /usr/share/YaST2/lib/bootloader/stage1_proposal.rb:266:in `block in class:Stage1Proposal' Obviously the architecture is armv6l. Submitted bug#1057142: https://bugzilla.opensuse.org/show_bug.cgi?id=1057142 -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Op dinsdag 5 september 2017 08:53:02 CEST schreef Freek de Kruijf:

Op maandag 4 september 2017 14:28:24 CEST schreef u:

...

On 04.09.17 11:49, Freek de Kruijf wrote:

...

I used the latest JeOS image 2017.05.23-Build1.1 for the RPi1 (armv6l) on a SD card and booted the system, which went OK.

After that I did a "zypper dup --no-recommends" on that system which, at the end, shows the following message:

Output of grub2-arm-uboot-2.02-6.1.armv6hl.rpm %posttrans script: update-bootloader: 2017-09-04 11:31:09 <3> update-bootloader-1244

run_command.274: '/usr/lib/bootloader/grub2-efi/install' failed with exit code>

1, output: <<<<<<<<<<<<<<<< target = arm-efi ls: cannot access '/sys/firmware/efi/efivars': No such file or directory + /usr/sbin/grub2-install --target=arm-efi --no-nvram --removable Installing for arm-efi platform.

Can you try to run this command on its own? If it still fails, run it with strace -f and upload the output somewhere (or look at it and search for failures)?

Thanks!

Alex

The RPi1 is not EFI system, so I wonder why the target should be arm-efi.

# /usr/sbin/grub2-install --target=arm-efi --no-nvram --removable Installing for arm-efi platform. /usr/sbin/grub2-install: error: cannot find a GRUB drive for /dev/mmcblk0p2. Check your device.map.

# more /boot/grub2/device.map (hd0) /dev/disk/by-id/mmc-SDC_0x49910339

# ls /dev/disk/by-id/ mmc-SDC_0x49910339 mmc-SDC_0x49910339-part1 mmc-SDC_0x49910339-part2 mmc- SDC_0x49910339-part3

When running yast in ncurses to change the bootloader without any update I also get the same error message: Error Execution of command "[["/usr/bin/grub2-editenv", "list"]]" failed. Exit code: 1 Error output: /usr/bin/grub2-editenv: error: cannot find a GRUB drive for / dev/mmcblk0p2. Check your device.map.

I am able to continue and I get the default "GRUB for EFI", which I change for GRUB2 After that I get the message: Error Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Details: unsuported architecture arm Caller: /usr/share/YaST2/lib/bootloader/stage1_proposal.rb:266:in `block in class:Stage1Proposal'

Obviously the architecture is armv6l.

Submitted bug#1057142: https://bugzilla.opensuse.org/show_bug.cgi?id=1057142

Got answer: --- Comment #1 from Ladislav Slezák --- Unfortunately RPi1 is not supported by YaST. YaST supports only aarch64 EFI based boards. On RPi1 you have configure booting manually. You can find some booting hints at https://en.opensuse.org/ HCL:Raspberry_Pi#Installing_the_openSUSE_Tumbleweed_image -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Op dinsdag 5 september 2017 14:00:33 CEST schreef Andreas Färber:

Am 05.09.2017 um 12:11 schrieb Freek de Kruijf:

...

Op dinsdag 5 september 2017 08:53:02 CEST schreef Freek de Kruijf:

...

Op maandag 4 september 2017 14:28:24 CEST schreef u:

...

On 04.09.17 11:49, Freek de Kruijf wrote:

...

I used the latest JeOS image 2017.05.23-Build1.1 for the RPi1 (armv6l) on a SD card and booted the system, which went OK.

After that I did a "zypper dup --no-recommends" on that system which, at the end, shows the following message:

Output of grub2-arm-uboot-2.02-6.1.armv6hl.rpm %posttrans script: update-bootloader: 2017-09-04 11:31:09 <3> update-bootloader-1244

run_command.274: '/usr/lib/bootloader/grub2-efi/install' failed with exit code>

1, output: <<<<<<<<<<<<<<<< target = arm-efi ls: cannot access '/sys/firmware/efi/efivars': No such file or directory + /usr/sbin/grub2-install --target=arm-efi --no-nvram --removable Installing for arm-efi platform.

Can you try to run this command on its own? If it still fails, run it with strace -f and upload the output somewhere (or look at it and search for failures)?

Thanks!

Alex

The RPi1 is not EFI system, so I wonder why the target should be arm-efi.

# /usr/sbin/grub2-install --target=arm-efi --no-nvram --removable Installing for arm-efi platform. /usr/sbin/grub2-install: error: cannot find a GRUB drive for /dev/mmcblk0p2. Check your device.map.

# more /boot/grub2/device.map (hd0) /dev/disk/by-id/mmc-SDC_0x49910339

# ls /dev/disk/by-id/ mmc-SDC_0x49910339 mmc-SDC_0x49910339-part1 mmc-SDC_0x49910339-part2 mmc- SDC_0x49910339-part3

When running yast in ncurses to change the bootloader without any update I also get the same error message: Error Execution of command "[["/usr/bin/grub2-editenv", "list"]]" failed. Exit code: 1 Error output: /usr/bin/grub2-editenv: error: cannot find a GRUB drive for / dev/mmcblk0p2. Check your device.map.

I am able to continue and I get the default "GRUB for EFI", which I change for GRUB2 After that I get the message: Error Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Details: unsuported architecture arm Caller: /usr/share/YaST2/lib/bootloader/stage1_proposal.rb:266:in `block in class:Stage1Proposal'

Obviously the architecture is armv6l.

Submitted bug#1057142: https://bugzilla.opensuse.org/show_bug.cgi?id=1057142> Got answer:

--- Comment #1 from Ladislav Slezák --- Unfortunately RPi1 is not supported by YaST. YaST supports only aarch64 EFI based boards.

On RPi1 you have configure booting manually. You can find some booting hints at https://en.opensuse.org/ HCL:Raspberry_Pi#Installing_the_openSUSE_Tumbleweed_image

I had started preparing arm for yast2-bootloader but I needed to wait until a yast2-core pull request got merged and packaged and I haven't followed up since. Basically we need to check all (Ruby?) code paths in there that check for aarch64 or arm64 and decide whether to extend those to arm as well - any volunteer?

That is independent of the GRUB error.

Regards, Andreas

I tried the suggested steps mentioned in issues following the above section in the wiki and added how to get the application mkimage. I executed the mentioned mkimage command line using the original boot.script. The resulted boot.scr differs from the original boot.scr. Doing a reboot with the newly generarted boot.scr failed. -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Op zaterdag 9 september 2017 18:42:52 CEST schreef Freek de Kruijf:

Op dinsdag 5 september 2017 22:41:54 CEST schreef Freek de Kruijf:

...

Op dinsdag 5 september 2017 14:00:33 CEST schreef Andreas Färber:

...

Am 05.09.2017 um 12:11 schrieb Freek de Kruijf:

...

Op dinsdag 5 september 2017 08:53:02 CEST schreef Freek de Kruijf:

...

Op maandag 4 september 2017 14:28:24 CEST schreef u:

...

On 04.09.17 11:49, Freek de Kruijf wrote: > I used the latest JeOS image 2017.05.23-Build1.1 for the RPi1 > (armv6l) > on > a SD card and booted the system, which went OK.

I repeated these steps, but now I only tried to update kernel-default using zypper which pulled in two other packages, wireless-regdb and crda.

There were no error messages. However a reboot did not succeed. The system could not find an extX file system with a certain UUID.

So I put the SD card in my desktop and used fdisk to list the structure. This structure is totally wrong. See below:

# fdisk -l /dev/sde Disk /dev/sde: 3.7 GiB, 3991928832 bytes, 7796736 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: FF922924-6706-4675-8AED-BB4E3FC84450

Device Start End Sectors Size Type /dev/sde1 2048 67587 65540 32M EFI System /dev/sde2 69632 509955 440324 215M Microsoft basic data /dev/sde3 512000 6763365 6251366 3G Microsoft basic data /dev/sde4 6764544 7796702 1032159 504M Microsoft basic data

Only the first partition sde1 can be mounted. the last one sde4 is a swap partition. The error message when mounting sde2 or sde3 is: wrong fs type, bad option, bad superblock on /dev/sdeX, missing codepage or helper program, or other error.

Bug in dracut?

No. I did put the SD card in the RPi1 and waited till ssh access was established. I did a shutdown of the system and put the SD card in my desktop. The result is the same as above. So it is the initialization of the SD card, creating the swap partition, splitting up the BOOT partition of 250M in 32 EFI and a 215M other partition, and enlarging the system partition, that goes wrong. -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Op zaterdag 9 september 2017 22:53:21 CEST schreef Freek de Kruijf:

Op zaterdag 9 september 2017 18:42:52 CEST schreef Freek de Kruijf:

...

Op dinsdag 5 september 2017 22:41:54 CEST schreef Freek de Kruijf:

...

Op dinsdag 5 september 2017 14:00:33 CEST schreef Andreas Färber:

...

Am 05.09.2017 um 12:11 schrieb Freek de Kruijf:

...

Op dinsdag 5 september 2017 08:53:02 CEST schreef Freek de Kruijf:

...

Op maandag 4 september 2017 14:28:24 CEST schreef u: > On 04.09.17 11:49, Freek de Kruijf wrote: >> I used the latest JeOS image 2017.05.23-Build1.1 for the RPi1 >> (armv6l) >> on >> a SD card and booted the system, which went OK.

I repeated these steps, but now I only tried to update kernel-default using zypper which pulled in two other packages, wireless-regdb and crda.

There were no error messages. However a reboot did not succeed. The system could not find an extX file system with a certain UUID.

So I put the SD card in my desktop and used fdisk to list the structure. This structure is totally wrong. See below:

# fdisk -l /dev/sde Disk /dev/sde: 3.7 GiB, 3991928832 bytes, 7796736 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: FF922924-6706-4675-8AED-BB4E3FC84450

Device Start End Sectors Size Type /dev/sde1 2048 67587 65540 32M EFI System /dev/sde2 69632 509955 440324 215M Microsoft basic data /dev/sde3 512000 6763365 6251366 3G Microsoft basic data /dev/sde4 6764544 7796702 1032159 504M Microsoft basic data

Only the first partition sde1 can be mounted. the last one sde4 is a swap partition. The error message when mounting sde2 or sde3 is: wrong fs type, bad option, bad superblock on /dev/sdeX, missing codepage or helper program, or other error.

Bug in dracut?

No. I did put the SD card in the RPi1 and waited till ssh access was established. I did a shutdown of the system and put the SD card in my desktop. The result is the same as above.

So it is the initialization of the SD card, creating the swap partition, splitting up the BOOT partition of 250M in 32 EFI and a 215M other partition, and enlarging the system partition, that goes wrong.

I initialized the SD card started it in the RPI1 entered with ssh and did the command: fdisk -l /dev/mmcblk0 . The output follows: # fdisk -l /dev/mmcblk0 Disk /dev/mmcblk0: 3,7 GiB, 3991928832 bytes, 7796736 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: FF922924-6706-4675-8AED-BB4E3FC84450 Device Start End Sectors Size Type /dev/mmcblk0p1 2048 67587 65540 32M EFI System /dev/mmcblk0p2 69632 509955 440324 215M Microsoft basic data /dev/mmcblk0p3 512000 6763365 6251366 3G Microsoft basic data /dev/mmcblk0p4 6764544 7796702 1032159 504M Microsoft basic data Right after writing the SD card on my desktop it is: # fdisk -l /dev/sde Schijf /dev/sde: 3,7 GiB, 3991928832 bytes, 7796736 sectoren Eenheid: sectoren van 1 * 512 = 512 bytes Sectorgrootte (logisch/fysiek): 512 bytes / 512 bytes In-/uitvoergrootte (minimaal/optimaal): 512 bytes / 512 bytes Schijflabeltype: dos Schijf-ID: 0xfa09d6bb Apparaat Op. Begin Einde Sectoren Grootte ID Type /dev/sde1 2048 411651 409604 200M c W95 FAT32 (LBA) /dev/sde2 413696 2680704 2267009 1,1G 83 Linux The strange thing is that the Linux partition initially starts on 413696 and none of the newly created partitions start on that location. -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Op maandag 11 september 2017 12:29:53 CEST schreef Alexander Graf:

On 10.09.17 17:14, Freek de Kruijf wrote:

...

Op zaterdag 9 september 2017 22:53:21 CEST schreef Freek de Kruijf:

...

Op zaterdag 9 september 2017 18:42:52 CEST schreef Freek de Kruijf:

...

Op dinsdag 5 september 2017 22:41:54 CEST schreef Freek de Kruijf:

...

Op dinsdag 5 september 2017 14:00:33 CEST schreef Andreas Färber:

...

Am 05.09.2017 um 12:11 schrieb Freek de Kruijf: > Op dinsdag 5 september 2017 08:53:02 CEST schreef Freek de Kruijf: >> Op maandag 4 september 2017 14:28:24 CEST schreef u: >>> On 04.09.17 11:49, Freek de Kruijf wrote: >>>> I used the latest JeOS image 2017.05.23-Build1.1 for the RPi1 >>>> (armv6l) >>>> on >>>> a SD card and booted the system, which went OK.

I repeated these steps, but now I only tried to update kernel-default using zypper which pulled in two other packages, wireless-regdb and crda.

There were no error messages. However a reboot did not succeed. The system could not find an extX file system with a certain UUID.

So I put the SD card in my desktop and used fdisk to list the structure. This structure is totally wrong. See below:

# fdisk -l /dev/sde Disk /dev/sde: 3.7 GiB, 3991928832 bytes, 7796736 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: FF922924-6706-4675-8AED-BB4E3FC84450

Device Start End Sectors Size Type /dev/sde1 2048 67587 65540 32M EFI System /dev/sde2 69632 509955 440324 215M Microsoft basic data /dev/sde3 512000 6763365 6251366 3G Microsoft basic data /dev/sde4 6764544 7796702 1032159 504M Microsoft basic data

Only the first partition sde1 can be mounted. the last one sde4 is a swap partition. The error message when mounting sde2 or sde3 is: wrong fs type, bad option, bad superblock on /dev/sdeX, missing codepage or helper program, or other error.

Bug in dracut?

No. I did put the SD card in the RPi1 and waited till ssh access was established. I did a shutdown of the system and put the SD card in my desktop. The result is the same as above.

So it is the initialization of the SD card, creating the swap partition, splitting up the BOOT partition of 250M in 32 EFI and a 215M other partition, and enlarging the system partition, that goes wrong.

I initialized the SD card started it in the RPI1 entered with ssh and did the command: fdisk -l /dev/mmcblk0 . The output follows:

# fdisk -l /dev/mmcblk0 Disk /dev/mmcblk0: 3,7 GiB, 3991928832 bytes, 7796736 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: FF922924-6706-4675-8AED-BB4E3FC84450

Device Start End Sectors Size Type /dev/mmcblk0p1 2048 67587 65540 32M EFI System /dev/mmcblk0p2 69632 509955 440324 215M Microsoft basic data /dev/mmcblk0p3 512000 6763365 6251366 3G Microsoft basic data /dev/mmcblk0p4 6764544 7796702 1032159 504M Microsoft basic data

Right after writing the SD card on my desktop it is:

# fdisk -l /dev/sde Schijf /dev/sde: 3,7 GiB, 3991928832 bytes, 7796736 sectoren Eenheid: sectoren van 1 * 512 = 512 bytes Sectorgrootte (logisch/fysiek): 512 bytes / 512 bytes In-/uitvoergrootte (minimaal/optimaal): 512 bytes / 512 bytes Schijflabeltype: dos Schijf-ID: 0xfa09d6bb

Apparaat Op. Begin Einde Sectoren Grootte ID Type /dev/sde1 2048 411651 409604 200M c W95 FAT32 (LBA) /dev/sde2 413696 2680704 2267009 1,1G 83 Linux

The strange thing is that the Linux partition initially starts on 413696 and none of the newly created partitions start on that location.

Well, sounds like something went wrong in the repartitioning step. I'm not quite sure what though - in the EFI case we should be quite safe:

https://build.opensuse.org/package/view_file/openSUSE:Factory:ARM/JeOS/uboot -image-install.in?expand=1

So the only repartitioning happening *should be* the one coming from kiwi itself, plus conversion to MBR (see lines 87ff).

I guess you could try to dd a vanilla image onto an SD card, remove the kiwi hooks in /.kiwi-hooks and check the partition table layout after that. If it's sane, do the gdisk steps in the script manually and see what comes out of that.

Alex

The vanilla image should be openSUSE-Tumbleweed-ARM-JeOS- raspberrypi.armv6l-2017.05.23-Build1.1.raw.xz I assume. After dd of that image I found folder /kiwi-hooks on partition with label ROOT. Renamed the folder to /kiwi-hooks.sav and booted the system. The SD with fdisk and parted look like: # fdisk -l /dev/sde Schijf /dev/sde: 7,4 GiB, 7969177600 bytes, 15564800 sectoren Eenheid: sectoren van 1 * 512 = 512 bytes Sectorgrootte (logisch/fysiek): 512 bytes / 512 bytes In-/uitvoergrootte (minimaal/optimaal): 512 bytes / 512 bytes Schijflabeltype: dos Schijf-ID: 0xfa09d6bb Apparaat Op. Begin Einde Sectoren Grootte ID Type /dev/sde1 2048 411651 409604 200M c W95 FAT32 (LBA) /dev/sde2 413696 2680704 2267009 1,1G 83 Linux # parted -l Model: Generic- SD/MMC (scsi) Disk /dev/sde: 7969MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 211MB 210MB primary fat16 lba, type=0c 2 212MB 1373MB 1161MB primary ext4 type=83 After starting the RPi1 with this SD card, I entered via ssh. I got the following results of fdisk and parted: # fdisk -l /dev/mmcblk0 Disk /dev/mmcblk0: 7,4 GiB, 7969177600 bytes, 15564800 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: dos Disk identifier: 0xfa09d6bb Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 2048 411651 409604 200M c W95 FAT32 (LBA) /dev/mmcblk0p2 413696 14554890 14141195 6,8G 83 Linux /dev/mmcblk0p3 14555136 15550919 995784 486,2M 82 Linux swap / Solaris rpitestn:~ # parted -l Model: SD SD08G (sd/mmc) Disk /dev/mmcblk0: 7969MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 211MB 210MB primary fat16 lba, type=0c 2 212MB 7452MB 7240MB primary ext4 type=83 3 7452MB 7962MB 510MB primary linux-swap(v1) type=82 This looks normal. It is not quite clear what gdisk commands I should perform. I did: # more /mnt/ll/root/bin/makeMBR.sh cat >> gdisk.tmp <<-'EOF' x a 1 2 64 m EOF # Convert GPT to hybrid GPT cat >> gdisk.tmp <<-'EOF' x r h 1 2 3 n c n 82 y 83 n w y EOF gdisk /dev/mmcblk0 < gdisk.tmp rm -f gdisk.tmp The resulting partitions look OK. # gdisk -l /dev/mmcblk0 GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: hybrid BSD: not present APM: not present GPT: present Found valid GPT with hybrid MBR; using GPT. Disk /dev/mmcblk0: 15564800 sectors, 7.4 GiB Logical sector size: 512 bytes Disk identifier (GUID): 3E320E69-F543-431B-BAEB-31FDE58CF4C1 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 15564766 Partitions will be aligned on 2048-sector boundaries Total free space is 18150 sectors (8.9 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 411651 200.0 MiB 0700 Microsoft basic data 2 413696 14554890 6.7 GiB 8300 Linux filesystem 3 14555136 15550919 486.2 MiB 8200 Linux swap However a reboot fails to find: /boot/linux.vmx and /boot/initrd.vmx In /boot/grub2/grub.cfg there are two menuentries asking for these two files, but they are not there. So I made two symbolic links in /boot initrd.vmx -> initrd-4.11.1-1-default linux.vmx -> zImage-4.11.1-1-default Now the system boots and I have access via ssh. All seems well. Will try to update all software. -- fr.gr. member openSUSE Freek de Kruijf -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Op maandag 11 september 2017 23:16:23 CEST schreef Freek de Kruijf:

Op maandag 11 september 2017 18:26:28 CEST schreef Freek de Kruijf:

...

All seems well. Will try to update all software.

The resulting system fails to boot after the upgrade. Will investigate further. At least /boot/grub2/grub.cfg did change quite a lot.

It looks like u-boot starts, I get about 15 lines on the screen, but after that the system starts again, showing very fast these lines again. I am lost here. On the FAT32 partition I see most files have been replaced. # ls -l /mnt/ll/ totaal 3244 -rwxr-xr-x 1 root root 50248 11 sep 18:59 bootcode.bin -rwxr-xr-x 1 root root 953 11 sep 18:59 config.txt drwxr-xr-x 3 root root 4096 23 mei 09:47 EFI -rwxr-xr-x 1 root root 6694 11 sep 18:59 fixup.dat -rwxr-xr-x 1 root root 2868644 11 sep 18:59 start.elf -rwxr-xr-x 1 root root 8 23 mei 09:47 startup.nsh -rwxr-xr-x 1 root root 374035 11 sep 18:59 u-boot.bin # ls -l /mnt/ll/EFI/BOOT/ totaal 108 -rwxr-xr-x 1 root root 106496 11 sep 19:31 bootarm.efi -rwxr-xr-x 1 root root 1701 23 mei 09:47 grub.cfg On the second partition I have: # ls -l /mnt/ll/boot totaal 40764 -rw-r--r-- 1 root root 0 23 mei 09:47 0xfa09d6bb lrwxrwxrwx 1 root root 1 23 mei 02:00 boot -> . -rw-r--r-- 1 root root 1725 18 jul 05:39 boot.readme -rw-r--r-- 1 root root 2404 23 mei 09:47 boot.scr -rw-r--r-- 1 root root 2332 23 mei 09:47 boot.script -rw-r--r-- 1 root root 157577 19 mei 00:39 config-4.11.1-1-default -rw-r--r-- 1 root root 159819 7 sep 22:24 config-4.12.11-1-default -rw-r--r-- 1 root root 0 11 sep 19:04 do_purge_kernels lrwxrwxrwx 1 root root 13 11 sep 18:45 dtb -> dtb-4.12.11-1 drwx------ 2 root root 4096 11 sep 18:45 dtb-4.12.11-1 drwxr-xr-x 2 root root 4096 23 mei 02:07 efi drwxr-xr-x 7 root root 4096 11 sep 19:31 grub2 lrwxrwxrwx 1 root root 24 11 sep 19:04 initrd -> initrd-4.12.11-1-default -rw------- 1 root root 6313928 11 sep 19:25 initrd-4.11.1-1-default -rw------- 1 root root 6339152 11 sep 19:30 initrd-4.12.11-1-default lrwxrwxrwx 1 root root 6 11 sep 21:14 initrd.vmx -> initrd lrwxrwxrwx 1 root root 6 11 sep 21:15 linux.vmx -> zImage -rw-r--r-- 1 root root 284101 19 mei 13:53 symvers-4.11.1-1-default.gz -rw-r--r-- 1 root root 287365 8 sep 01:11 symvers-4.12.11-1-default.gz -rw-r--r-- 1 root root 207 19 mei 13:53 sysctl.conf-4.11.1-1-default -rw-r--r-- 1 root root 207 8 sep 01:11 sysctl.conf-4.12.11-1-default -rw-r--r-- 1 root root 2250840 19 mei 13:11 System.map-4.11.1-1-default -rw-r--r-- 1 root root 2282602 8 sep 00:59 System.map-4.12.11-1-default -rw-r--r-- 1 root root 1484762 23 mei 09:47 unicode.pf2 drwxr-xr-x 2 root root 4096 11 sep 18:59 vc -rw-r--r-- 1 root root 6009898 19 mei 15:40 vmlinux-4.11.1-1-default.gz -rw-r--r-- 1 root root 6099742 8 sep 01:21 vmlinux-4.12.11-1-default.gz lrwxrwxrwx 1 root root 24 11 sep 19:04 zImage -> zImage-4.12.11-1-default -rw-r--r-- 1 root root 4959568 19 mei 13:11 zImage-4.11.1-1-default -rw-r--r-- 1 root root 65 19 mei 13:53 .zImage-4.11.1-1-default.hmac -rw-r--r-- 1 root root 5035704 8 sep 00:59 zImage-4.12.11-1-default -rw-r--r-- 1 root root 65 8 sep 01:11 .zImage-4.12.11-1-default.hmac I added the symbolic links linux.vmx and initrd.vmx, but these names are no longer mentioned in grub2/grub.cfg # ls -l /mnt/ll/boot/grub2/ totaal 60 drwxr-xr-x 2 root root 20480 11 sep 19:31 arm-efi drwxr-xr-x 2 root root 4096 19 mei 08:24 backgrounds -rw-r--r-- 1 root root 95 23 mei 09:47 bootpart.cfg -rw-r--r-- 1 root root 43 23 mei 02:00 device.map drwxr-xr-x 2 root root 4096 11 sep 19:31 fonts -rw------- 1 root root 9323 11 sep 19:31 grub.cfg -rw-r--r-- 1 root root 1024 11 sep 19:31 grubenv drwxr-xr-x 2 root root 4096 11 sep 19:31 locale drwxr-xr-x 3 root root 4096 23 mei 09:11 themes -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Op dinsdag 12 september 2017 22:14:54 CEST schreef Freek de Kruijf:

Op dinsdag 12 september 2017 11:32:13 CEST schreef Freek de Kruijf:

I will connect my USB serial cable to the proper pins of the RPi-card to see if any message appears on the console.

Indeed I got the culprit in booting this upgraded system. In the start process things go well until /sysroot needs to be mounted. The log shows this: [ 10.250295] rpitestn systemd[1]: Reached target Basic System. [ 10.264108] rpitestn systemd[1]: Starting File System Check on /dev/disk/ by-id/mmc-SD08G_0x7c498e75-part2... [ 10.598506] rpitestn systemd-fsck[197]: ROOT: clean, 35270/425088 files, 329975/1767649 blocks [ 10.971425] rpitestn systemd[1]: Started File System Check on /dev/disk/by- id/mmc-SD08G_0x7c498e75-part2. [ 10.996954] rpitestn systemd[1]: Mounting /sysroot... [ 11.175363] rpitestn systemd[1]: sysroot.mount: Mount process exited, code=exited status=32 [ 11.164599] rpitestn kernel: EXT4-fs (mmcblk0p2): Unrecognized mount option "size=100%" or missing value [ 11.181939] rpitestn systemd[1]: Failed to mount /sysroot. Somewhere, I can't find it now, an error was reported that the parameter rootflags=size=100% was not recognized, which was the reason for not mounting /sysroot. So I looked into /boot/grub2/grub.cfg and found this parameter twice there. I removed it and started the RPi1. Hooray!!!! The system now boots and I get a prompt on the console. Also ssh connection works. All in all; The upgrade of the system has an error on the FAT32 partition and the parameter bootflags=size=100% in the grub configuration is in error. Should I file bug report? -- fr.gr. Freek de Kruijf member openSUSE -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org