On Saturday 2017-01-28 11:46, Alexander Graf wrote:

On 28/01/2017 10:55, Paul Neuwirth wrote:

...

Hello group, as I am really unlucky with sd cards, every one has bad sectors, data are partly not fully written without notice... ... I want to try to install openSUSE-Tumbleweed-ARM-JeOS-raspberrypi2 image using a nfsroot. anyone who tried this?

I haven't but it should be reasonably straight forward.

...

my idea was first to install to an sdcard (hope this will work) then try to build a initrd with network/nfs support (or does the original already have?) modify boot params to use nfsroot (and of course put the rootfs on an nfs share).

Basically that should work. To generate a working initrd, just do it within the nfsroot chroot:

$ mount <nfs> /nfs $ for i in dev dev/pts sys proc; do mount --bind /$i /nfs/$i; done $ chroot /nfs $ mkinitrd

That way dracut has the chance to detect that your rootfs (/, which is really /nfs) is located on NFS and include network as well as NFS support.

The resulting initrd obviously resides on your NFS share then though ;).

...

even better would be a pxe-bootloader.. googling around i did not find such for arm/raspberry pi.. any hints?

There is full PXE support on the Raspberry Pi 3:

https://www.raspberrypi.org/blog/pi-3-booting-part-ii-ethernet-all-the-aweso...

But even with a normal SD based boot, U-Boot already has everything it needs to make PXE boot work. Try:

U-Boot# setenv boot_targets dhcp U-Boot# boot

that should try to load grub2 from dhcp rather than SD card. If you want to make this permanent, just remove your bootarm.efi binary on the ESP (/dev/mmcblk0p1).

Once you're in grub2, you can access file paths relative to the PXE loading location IIRC.

Alex

thanks, exactly the information i need. but i am still failing at the first step... copied image on sd card, installation (creating partitions, etc.) seemed to work, after a reboot system did not come up.. (uboot, grub2 worked, loading initrd -> nothing) now i wanted to check the ext-filesystem: # fsck.ext4 -c -f /dev/sdd2 e2fsck 1.42.11 (09-Jul-2014) The filesystem size (according to the superblock) is 1767649 blocks The physical size of the device is 1765641 blocks Either the superblock or the partition table is likely to be corrupt! good start :-/ ok several badblocks, but fsck succeeded not finding any fs errors.. boot... again nothing :( going to try next sd card -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Saturday 2017-01-28 14:34, Johannes Kastl wrote:

Date: Sat, 28 Jan 2017 14:34:15 From: Johannes Kastl To: opensuse-arm@opensuse.org Subject: Re: [opensuse-arm] "installing" openSuSE on raspberry pi2 using nfsroot

On 28.01.17 14:07 Paul Neuwirth wrote:

...

now i wanted to check the ext-filesystem:

# fsck.ext4 -c -f /dev/sdd2 e2fsck 1.42.11 (09-Jul-2014) The filesystem size (according to the superblock) is 1767649 blocks The physical size of the device is 1765641 blocks Either the superblock or the partition table is likely to be corrupt!

good start :-/

Seems like the resizing of the filesystem (so the whole sd is used), that is done on the first (or second?) boot, did not run through.

Johannes

ok.. maybe i was too impatient at the second boot.. but normally a message is produced when removing sd card during this step. that was an 8GB sd card, havin bad blocks somewhere in the middle. the next 32GB card i tried... image got copied.. but partprobe did not find anything after write.. just zeros at the beginnung.. next card is again 32GB.. image got written, ext4fs is ok no bad blocks. wondering how long the resizing for this will need. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Saturday 2017-01-28 14:45, Paul Neuwirth wrote:

...

...

The filesystem size (according to the superblock) is 1767649 blocks The physical size of the device is 1765641 blocks Either the superblock or the partition table is likely to be corrupt!

good start :-/

Seems like the resizing of the filesystem (so the whole sd is used), that is done on the first (or second?) boot, did not run through.

Johannes

ok.. maybe i was too impatient at the second boot.. but normally a message is produced when removing sd card during this step. that was an 8GB sd card, havin bad blocks somewhere in the middle. the next 32GB card i tried... image got copied.. but partprobe did not find anything after write.. just zeros at the beginnung.. next card is again 32GB.. image got written, ext4fs is ok no bad blocks. wondering how long the resizing for this will need.

at boot complain: mmc0: card stuck in programming mode ... error.. timeout.. aborting.. reboot. after reboot same errors.. seems I don't have not even one working card... if I put it into my usb cardreader: [1971190.289615] usb-storage 1-5:1.0: USB Mass Storage device detected [1971190.291394] usb-storage 1-5:1.0: Quirks match for vid 05e3 pid 0723: 8000 [1971190.291431] scsi host7: usb-storage 1-5:1.0 [1971191.290763] scsi 7:0:0:0: Direct-Access Generic STORAGE DEVICE 9451 PQ: 0 ANSI: 0 [1971191.291877] sd 7:0:0:0: Attached scsi generic sg7 type 0 [1971191.367701] sd 7:0:0:0: [sdd] Attached SCSI removable disk # partprobe -s /dev/sdd Error: Error opening /dev/sdd: No medium found double check with another cardreader 1971366.847557] sd 7:0:0:2: [sdf] 61831168 512-byte logical blocks: (31.7 GB/29.5 GiB) [1971366.855309] sd 7:0:0:2: [sdf] Write Protect is off [1971366.855314] sd 7:0:0:2: [sdf] Mode Sense: 03 00 00 00 [1971366.860300] sd 7:0:0:2: [sdf] No Caching mode page found [1971366.860304] sd 7:0:0:2: [sdf] Assuming drive cache: write through [1971366.864298] sd 7:0:0:0: [sdd] Attached SCSI removable disk [1971366.872813] sd 7:0:0:3: [sdg] Attached SCSI removable disk [1971366.884683] sdf: sdf1 sdf2 ok.. fsck.ext4 -cf /dev/sdf2 e2fsck 1.42.11 (09-Jul-2014) Checking for bad blocks (read-only test): done ROOT: Updating bad block inode. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information ROOT: ***** FILE SYSTEM WAS MODIFIED ***** ROOT: 82565/186944 files (0.6% non-contiguous), 650011/746480 blocks seems also ok.. trying again -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org