Converting to NOOBS format

[procount]

I am trying to convert your image to be installable by NOOBS/PINN. If I remove the /boot/autoexpand_root_partition sentinel file as recommended then the raspberrypi64 password does not get set. In this case what is the default password for root to login?

As a workaround, I was modifying the etc/local.d/autoexpand_root_partition.startso that the password and graphical login would be set without partition resizing. But for some reason my root partition always ends up being r/o so that the script will not be effective. I'm still investigating that, but any ideas why this partition should end up readonly would be welcome.

[sakaki-]

The default password is supposed to be raspberrypi64 anyway, but this was causing issues for some people (see #1) so I added the belt-and-braces setting to the autoexpand_root_partition.start file. In any event, you can always do sudo su --login root as demouser to get a root prompt (given the /etc/sudoers setup on the image, this requires no password, not even demouser's), then set your own password. No idea why your / should be ro though. Is your root partition ext4, as set up in /boot/cmdline.txt?

[sakaki-]

One thought - on Gentoo under OpenRC, the file /etc/init.d/root is what brings the root filesystem to a writeable state (it is ro in very early boot). This init script may not be be being executed (although in this case you'd expect the system to fail to come up), or your / may have failed an fsck and been retained as ro for that reason... have you tried checking the / filesystem (on a PC, when not mounted)?

[procount]

I'm using a standard procedure to convert the image to NOOBS format. It works on countless other OSes, so I just need to identify which bits are different for gentoo. Here is what I am doing... 1) I extract the image file and loop mount the 2 partitions inside it. 2) I change /boot/autoexpand_root_partition to /boot/autoexpand_root_none 3) I replace /etc/local.d/autoexpand_root_partition.sh to that in PR #14 4) I tar up both partitions and compress with xz 5) NOOBS will create a FAT and an ext4 partition (nominally /dev/mmcblk0p6 and /dev/mmcblk0p7) 6) NOOBS expands the compressed tar.xz files into those partitions. 7) NOOBS will adjust /boot/cmdline.txt to indicate the root is on /dev/mmcblk0p7 8) NOOBS will adjust /etc/fstab to mount the correct partitions (mmcblkp6 & 7) 9) NOOBS will now boot gentoo.

When it boots, autoexpand.... fails to set the default passwords and fails to add xdm, so I am stuck at the login prompt where the default root/demouser logins of raspberrypi64 do not work at all. (The updated script works if I simply apply it to the default image).

So I use my fork of NOOBS (PINN) to change the password of gentoo and reboot into it. Now I can login, but I find the rootfs is r/o, whcih is why the autoexpand script is failing. So something has gone wrong earlier.

Thanks for the above pointers. I will investigate those ideas to see why it is r/o. (I couldn't do sudo su --login root because I can't even login as demouser at that stage)

[sakaki-]

I have merged your PR, thanks, it'll be on the next release (which I am working on at the moment). When you use your NOOBS fork to boot, and have the ro filesystem, are there any hints about what went wrong in dmesg?

[procount]

I finally managed to log in again, without it immediately requesting me to reset my password. As gentoo boots it gets to the * Checking local filesystems ... part The boot partition checks out fine. But then it checks the rootfs... * Remounting root filesystem read/write ... MOUNT: / not mounted or bad option ... Root filesystem could not be mounted read/write

The fstab looks fine to me. I only replaced mmcblk0p2 with mmcblk0p7 for root, and similarly for boot.

/dev/mmcblk0p6          /boot   vfat    defaults                0       2
/dev/mmcblk0p7          /       ext4    defaults,noatime        0       1
/var/cache/swap/swap1   none  swap sw    0   0

The only thing I spotted in dmesg was: [ 8.966408] EXT4-fs (mmcblk0p7): Unrecognized mount option "freely." or missing value. I couldn't find any other logs (because /var is read-only?)

[sakaki-]

/etc/fstab looks OK, but that dmesg is odd. What is in /boot/cmdline.txt after your script has modified it?

[procount]

dwc_otg.lpm_enable=0 root=/dev/mmcblk0p7 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

[sakaki-]

Looks OK but something may be at issue elsewhere - what does cat /proc/cmdline show once you are booted (on the ro root system)?

[procount]

8250.nr_uarts=0 cma=256M@256M dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1680 bcm2708_fb.fbheight=1050 bcm2709.boardrev=0xa02082 bcm2709.serial=0x7882aa2b smsc95xx.macaddr=B8:27:EB:82:AA:2B bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p7 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

Maybe it's the way I created the rootfs partition? I used mkfs.ext4 with option -O ^huge_file and labeled the partition root_gen

[sakaki-]

Looks OK. Must be a filesystem issue then, since the kernel is unchanged.

Possibly you have run out of inodes? Gentoo requires more than most distros because of the from-source nature. Try running df -i (when booted to the ro system) and see what you get for IUse% on /. If full then you probably have a corrupt root filesystem. It can happen with EXT systems on small (e.g. sd-card) partitions under Gentoo (not an issue on large hard drives with the standard mkfs.ext4 settings). As suggested here, you could try using

mkfs.ext4 -i 8192 -t ext4 /dev/mmcblk0p7

to create a filesystem with a higher inode count. Also try leaving off the huge_file option, at least initially. The partition label should not matter.

[procount]

/ has IUse%=22% Inodes 1937712 IUsed 414794 Ifree 1522918

[sakaki-]

OK, not that then, but must be something to do with the root filesystem - the kernel is the booting OK and I assume there is nothing weird going on in config.txt, and the full (/proc/cmdline) kernel command line matches a normal startup. The dmesg output

[ 8.966408] EXT4-fs (mmcblk0p7): Unrecognized mount option "freely." or missing value.

is definitely indicating something is wrong with root. Perhaps if you try making /dev/mmcblk0p7 without huge_file?

One last thing you could try is, when the ro system comes up and you are logged in, to try to manually remount the / filesystem read-write - you might get a better diagnostic from that as to what it thinks is wrong:

pi64 ~ # mount -v -o remount,rw /

Sorry this is chewing up so much of your time! If you still can't get it to start after this then if you can send me an image of your boot and root filesystems (/dev/mmcblk0p6 and /dev/mmcblk0p7), I'd be happy to look at it this end for you.

PS I assume you have rebuilt the container image since the original-sentinel version of autoexpand_root_partition.start ran? The beginning of that file contains:

ROOTDRIVE="/dev/mmcblk0"
ROOTPART="${ROOTDRIVE}p2"

and then it attempts to (given the original sentinel setup):

sfdisk --no-reread -N 2 <<<", +" "${ROOTDRIVE}"

and then

resize2fs -f "${ROOTPART}"

either of which is going to have a potentially nasty effect on /dev/mmcblk0p2, whatever that happens to be... (I appreciate your PR'd version doesn't do this, but the damage may already be done to the partition table, not sure whether you rebuild the full partition structure each test.)

[procount]

I already tried without Huge file - no difference. I also tried mounting root manually (with -n instead of -v) but with the same error. I will try again with -v. Actually I'm sorry this is taking up so much of YOUR time. This is normally a straightforward process. In fact I have a script to do it all for me for 16 or so different OSes. I must be missing something obvious. Rest assured I started with a clean image with SENTINEL3 setfor PR, so none of the resizing happened. I do have to keep restarting from scratch, but the installation only takes 10 mins or so. It's if I have to change my tar files from the original image that it takes the time. I appreciate the offer of looking at my images. It may come to that, but I have another couple of tricks to try first. I'll let you know how they go. (Why is my return key not working..... ;-).

[procount]

I tried -v and it still comes up with the same error. I've still got to try -i 8192 plus some other things....

Assuming I do get this to install properly, I could do with a logo for Gentoo (40x40 pixel png file) plus a few images (about 2-4 png files of size ~384x288 pixels) to be shown as a slideshow during installation, illustrating the main features/benefits of Gentoo. :smile:

[sakaki-]

OK I'll see what I can put together... Do let me know if there's anything else I can do to help debug this boot issue.

[procount]

No rush, especially as I am still struggling. I even extracted the rootfs partition from your image and DD'd it directly to /dev/mmcblk0p7 to eliminate any changes to the format / partitioning, and it was STILL r/o.

I will prepare an image for you so you can have a look at it. All I am essentially trying to do is to move the boot and root partitions to other partition numbers on the SD card. Can you think of any other files that might reference /dev/mmcblk0p2? I am moving them into logical partitions. Would that make a difference? Maybe I will try locating them in different primary partitions next...

[procount]

Finally some good news - I managed to get PINN to boot gentoo64! To do this, I installed gentoo64 to primary partitions 2&3. I'm not sure if this is the only reason, but now I have a working image, I will try installing them to logical partitions.

[procount]

And now it works on partitions 6&7 as well. So I think it's something to do with the original image rootfs failing fsck or something. I had to do an fsck on it prior to writing it to the SD card. The rootfs seems to pass an fsck on ubuntu, but then failed it under gentoo (?) But it's looking promising at last. I just need to make the procedure repeatable!

[sakaki-]

Good news - well done.

[sakaki-]

Are there examples of the slideshow images for other O/S installs I could take a quick look at to see the kind of thing you're after? Various formats of the Gentoo logo itself are available here.

[procount]

You can have a look here for a list of OSes. https://sourceforge.net/projects/pinn/files/os/ In each OS folder, have a look in the slides_vga subfolder. Some are better than others :) Thanks.

[sakaki-]

Hi - haven't forgotten about this, but have been busy putting the 1.1.0 release out, which has a number of significant improvements (inclusion of packages like libreoffice thunderbird & gimp, binary kernel package support, easier updating etc.)

Would you mind trying to see if the new image works for your installer? I have migrated your PR #14 into an OpenRC service on the image (visible here) but the logic remains the same - you should be able to use autoexpand_root_none rather than autoexpand_root_partition sentinel files.

Now I have some bandwidth, I'll put some slides together for you over the next few days, with screenshots from the new image. Thanks!

[procount]

Hey, no worries! I've been busy myself. Will try the new version shortly. Hopefully it will be easier than last time :) thanks.

[sakaki-]

OK I have posted six first-cut png files here; is that the sort of thing you need? I can make the background white easily if that works better. (PS the benchmarks quoted are from these results). I am going to be putting out a 1.1.1 release, hopefully today, addressing some minor issues with 1.1.0 (the overscan cursor alignment issue #17 being the most annoying); so it'd be worth using that version if you could. Also, I intend switching the root (and boot) filesystem to PARTUUID naming in the cmdline.txt and /etc/fstab (I've had a request to do this for people not booting the image from a microSD card); I guess this shouldn't matter too much to you, as you modify these in your installer anyway?

[procount]

Looking good. Thanks! And I'd just started converting v1.1.0..... :) OK. I'll hold off til the next release. Yes, I switch mountpoint references during install and use PARTUUID if installing to a USB drive, otherwise I think it just uses the normal partition references, so it shouldn't make any difference. I'll check it when I convert v1.1.1

[sakaki-]

Hi - v.1.1.1 is out now. Things to look at that might possibly cause breakage on your side:

• cmdline.txt now has root=PARTUUID=7A0C8BB0-02 in there, in place of root=/dev/mmcblk0p2;
• similarly, the autoexpand-root service now looks up the root= entry in /proc/cmdline, and then (if a PARTUUID) canonicalizes it; however, this should only happen for the standard sentinel types; the logic should not run with an autoexpand_root_none sentinel;
• lastly, the /etc/fstab now reads (last three lines):

  PARTUUID=7a0c8bb0-01    /boot       vfat    defaults          0       2
  PARTUUID=7a0c8bb0-02    /       ext4    defaults,noatime  0       1
  /var/cache/swap/swap1   none        swap    sw        0   0

Please let me know if you encounter any issues trying to get the image prepared for your installer, or if there is anything else that you need.

thanks!

[procount]

Thanks. Downloading now.

[procount]

interim report Just had a chance to test the v1.1.1 PINN installation. It installed first time and allowed me to enter the correct password for demouser at the cmdline login prompt. However, the rootfs was r/o again, so I'll have to apply some magic....

[sakaki-]

OK, thanks. Strange about the r/o thing. I have added explicit fsck -f checking to the end of the image prepare script, so both partitions should be clean when shipped (and obviously the vanilla image boots up OK from microSD).

One other thing you could try - because the Pi has no RTC, the image uses Gentoo's swclock service; this saves the last shutdown time (in /lib64/rc/cache/shutdowntime) and restores this in early boot (eventually the chronyd NTP client sets the correct time). Large superblock time offsets (last write more than a day in the future, according to the cached shutdown time) will force an fsck to happen during boot. The edits you are making to the two partitions when loop mounted will probably have this effect.

So, you could try touching the file ${YOURLOOPMOUNT}/lib64/rc/cache/shutdowntime as the last step when editing the image, to see if this makes any difference.

[procount]

I still haven't quite got to the bottom of why it goes read-only, but I think it is something to do with the timestamps of modified files, as you suggested. If PINN is installing gentoo offline, it may not have a sense of the time either, so it uses a similar fake clock which will again be different (maybe in the past or future relative to the last real gentoo fs access time.) This maybe giving different results from when PINN is connected to a network with the real time.

However, I managed to hand-hold the installation through, and with a few manual tweaks, PINN managed to load Gentoo64 v1.1.1, from a USB boot (not SD card), complete with a nice icon and shiny slideshow!

I'm going to have to take a break from this for a while, but I'll do some more testing and make my scripts more robust to avoid this read-only problem. Then I hope to release it in a week or so (time permitting) :smile:

BTW, the cursor no longer disappears when the screen blanks. I guess this is an artefact of the use of the new software cursor?

[sakaki-]

Then I hope to release it in a week or so (time permitting)

Great, thanks for all your time on this. I look forward to trying it out!

BTW, the cursor no longer disappears when the screen blanks. I guess this is an artefact of the use of the new software cursor?

The software cursor will only kick in if overscan is enabled (and it is now disabled by default in the shipped config.txt, unless your installer modifies this). However, there's an upgraded mesa library in the 1.1.1 too, so that could explain it.

[procount]

Arrgghhh! I thought I had cracked it, but even keeping all the timestamps the same, it still went r/o.

[sakaki-]

Happy to look at an image if you want to upload one somewhere (a dummy project release on GitHub for example)? Are you still getting the same mount error?

[ 8.966408] EXT4-fs (mmcblk0p7): Unrecognized mount option "freely." or missing value.

Here's what the root init script is doing:

#!/sbin/openrc-run
# Copyright (c) 2007-2015 The OpenRC Authors.
# See the Authors file at the top-level directory of this distribution and
# https://github.com/OpenRC/openrc/blob/master/AUTHORS
#
# This file is part of OpenRC. It is subject to the license terms in
# the LICENSE file found in the top-level directory of this
# distribution and at https://github.com/OpenRC/openrc/blob/master/LICENSE
# This file may not be copied, modified, propagated, or distributed
# except according to the terms contained in the LICENSE file.

description="Mount the root fs read/write"

depend()
{
    after clock
    need fsck
    keyword -docker -jail -lxc -openvz -prefix -systemd-nspawn -vserver
}

start()
{
    case ",$(fstabinfo -o /)," in
        *,ro,*)
        ;;
        *)
            # Check if the rootfs isn't already writable.
            if checkpath -W /; then
                rm -f /fastboot /forcefsck
            else
                ebegin "Remounting root filesystem read/write"
                case "$RC_UNAME" in
                    Linux)
                        mount -n -o remount,rw /
                    ;;
                    *)
                        mount -u -o rw /
                    ;;
                esac
                eend $? "Root filesystem could not be mounted read/write"
                if [ $?  -eq 0 ]; then
                    rm -f /fastboot /forcefsck
                fi
            fi
        ;;
    esac

    ebegin "Remounting filesystems"
    local mountpoint
    for mountpoint in $(fstabinfo); do
        case "${mountpoint}" in
            /)
            ;;
            /*)
                mountinfo -q "${mountpoint}" && \
                    fstabinfo --remount "${mountpoint}"
            ;;
        esac
    done
    eend 0
}

So once booted r/o, does:

pi64 ~ # mount -n -o remount,rw /

work? If not, what is going to dmesg?

[procount]

No it won't mount rw. If I find time later I will post it up for you to try.

[sakaki-]

OK thanks, I'll definitely have a look if you do get a chance to post it.

[procount]

I have uploaded the gentoo64 installation files for you to play with :)

Just follow these instructions (a bit more complicated than usual due to the manual test installation)

1. Get a 16GB or larger SD card (or USB stick if your RPi3 has been programmed for USB boot, but it is slower to boot)
2. Format it to FAT32. I recommend the SDformatter v4 tool on WIndows with size adjustment on to ensure ALL partitions are deleted and the FAT32 partition fills the entire card.
3. Go to https://sourceforge.net/projects/pinn/files/ and download pinn-lite.zip.
4. unzip pinn-lite.zip onto the SD card preserving any folder structure.
5. in the /os folder, create a folder named gentoo64
6. Go to https://sourceforge.net/projects/pinn/files/testing/gentoo64/ and download all files (including the slides_vga folder and it's contents) and put them in the /os/gentoo64 folder on the SD card for local installation. (once released, these files are downloaded directly from the internet)
7. (Optional) in the root of the SD card, edit the recovery.cmdline. This just consists of 1 single line. 7a. Add the keywords 'ssh vncshare forcetrigger' to this line (no quotes). 7b. This enables ssh and vnc support to enable headless use/debugging. forcetrigger forces PINN to display its menu on each boot. For ssh login use 'root/raspberry'. 7c. You can also press ctrl-alt-f2 to get to a local debug terminal with the same password. Either is useful for looking at the SD card or gentoo partitions on the RPi whilst in-situ, although you only have a minimal busybox shell.
8. Insert SD card into the RPi3 and boot.
9. You will see gentoo64 as an option in the list. Select the checkbox and select the install button. If the RPI3 is connected to the internet, you will also get a whole lot of other OSes as well.
10. Once installed click on the OK button. The RPi should boot into Gentoo (if you are lucky)
11. On subsequent reboots, just Exit PINN to boot into gentoo64. (with no forcetrigger option, it will boot gentoo64 after a timeout automatically)

What has PINN done? The original gentoo64 image was loop mounted. The 2 partitions have been converted to 2 .tar.xz files, 1 for each partition, with no modifications. It's just a change in format. It created /dev/mmcblk0p6 for the fat32 boot partition and /dev/mmcblk0p7 for the ext4 root partition. The 2 tar.xz files are copied onto the respective partitions. /os/gentoo64/partition_setup.sh is used to modify the gentoo64 files post-installation. Namely, the cmdline.txt file and the etc/fstab Then it reboots into partition 6 to load gentoo64. The problem then is that it fails to load root r/w for some unknown reason.

Note that PINN will change the diskid and thus the PARTUUIDs used by gentoo64 on a USB stick. SD Cards may still use /dev/mmcblk0pX format.

For more info on how to use PINN and what it does see: https://github.com/procount/pinn https://github.com/procount/pinn/blob/master/README_PINN.md https://github.com/procount/pinn/blob/master/README_PINN.md#how-to-create-a-custom-os-version

Enjoy!

[sakaki-]

OK been through the install process, looks great! I have reproduced the r/o issue my side. Will dig into it in the next few days. Thanks, sakaki

[sakaki-]

Seems to be either the filesystem or tarball contents for partition 7. If I take your (r/o booting) image and dd my image's partition 2 contents over partition 7, then manually edit the /etc/fstab entries, touch /lib64/rc/cache/shutdowntime and reboot, it all comes up fine. I will revert your image and try rm -rf on partition 7, then cp -ax-ing the files from my partition 2 into it next. That should indicate if it is the ext4 filesystem or the root tarball. Will keep you posted.

[sakaki-]

Doesn't look to be the ext4 filesystem itself - the cp -ax'd system (with modified fstab & shutdowntime) boots fine (to r/w & desktop). So, looks like there may be an issue with the root tarball somehow. I'll unpack it, and do a recursive diff against my baseline image's root filesystem next.

[sakaki-]

Hmmm... the tarball looks almost but not quite the same as the 1.1.1 root... for example, /usr/include/bsd/sys seems to be empty in the tarball, but not on 1.1.1. Although I can't understand why that should matter, it's a little odd, so I'm going to try rolling my own tar.xz now and see if PINN will install from that.

[sakaki-]

OK, interesting. Here are the steps I took to create root_gen.tar.xz (the genpi64.img.xz image I used is exactly the version posted on GitHub):

root@build1 ~ # cp -iv /home/sakaki/rpi3/1.1.1/genpi64.img.xz .
'/home/sakaki/rpi3/1.1.1/genpi64.img.xz' -> './genpi64.img.xz'
root@build1 ~ # unxz genpi64.img.xz 
root@build1 ~ # kpartx -s -v -a genpi64.img
add map loop1p1 (253:13): 0 129024 linear 7:1 2048
add map loop1p2 (253:14): 0 15200000 linear 7:1 131072
root@build1 ~ # mkdir /mnt/genpi64root
root@build1 ~ # mount -r /dev/mapper/loop1p2 /mnt/genpi64root
root@build1 ~ # du -sh /mnt/genpi64root
6.2G    /mnt/genpi64root
root@build1 ~ # tar cf root_gen.tar -C /mnt/genpi64root .
root@build1 ~ # ls -lh root_gen.tar 
-rw-r--r-- 1 root root 5.4G Jul 28 03:40 root_gen.tar
root@build1 ~ # xz -v -9e -T0 root_gen.tar 
root_gen.tar (1/1)
  100 %     774.8 MiB / 5,461.3 MiB = 0.142    32 MiB/s       2:50             
root@build1 ~ # ls -lh root_gen.tar.xz 
-rw-r--r-- 1 root root 775M Jul 28 03:40 root_gen.tar.xz

Copied this to the os/gentoo64 folder in the PINN first partition's filesystem. Booted PINN and installed Gentoo using this tarball.

Got the r/o issue again.

OK, then after that mounted /dev/mmcblk0p7 on a PC. rm -rf *'d the filesystem (but did not reformat), and then untarred the above root_gen.tar.xz into the now-blank root. Fixed up fstab, timestamp, touched autoexpand_root_none on /dev/mmcblk0p6. Unmounted and booted.

Went through fine this time.

So, looks like:

• the ext4 filesystem is OK
• the tarball contents are OK (at least the one I just created), but
• somehow, the tarball is not getting written correctly by the installer

Should be easy to check this: untar the tarball to HDD, then mount the post-PINN-install /dev/mmcblk0p7 and recursively diff these two (with meld or similar tool). Most likely one or more binaries or libs has been corrupted during the installer untar - although why this should be so I have no idea.

Must run now but perhaps you could run that test your side? Thanks!

[procount]

Thanks for your investigations. Very similar to what I was doing. Can't do anything at the moment I'm afraid but will try when I can. PINN can also install img files so we could also extract the 2 partitions from the original image to 2 separate image files but it will probably require resizing the filesystem to the new disk size on 1st boot. Dunno why tar is acting to strange. We use bsdtar now if that makes a difference.

[sakaki-]

Found it. Nothing to do with decompression at all, but it was useful to run the recursive diff, as it pinpointed the issue.

Have a look at your patched /etc/fstab (after PINN has modified it). On my system at least, looks like:

# /etc/fstab: static file system information.
#
# noatime turns off atimes for increased performance (atimes normally aren't 
# needed); notail increases performance of ReiserFS (at the expense of storage 
# efficiency).  It's safe to drop the noatime options if you want and to 
/dev/mmcblk0p7  / tail freely.
#
# The root filesystem should have a pass number of either 0 or 1.
# All other filesystems should have a pass number of 0 or greater than 1.
#
# See the manpage fstab(5) for more information.
#

# <fs>   <mountpoint> <type>  <opts>  <dump/pass>

# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
/dev/mmcblk0p6  /boot  vfat    defaults          0       2
/dev/mmcblk0p7  /  ext4    defaults,noatime  0       1
/var/cache/swap/swap1   none  swap sw    0   0

Look at that sixth line from the top. Explains the "freely." bad option message in dmesg too! Your partition_setup.sh sed line:

sed /tmp/2/etc/fstab -i -e "s|^.* / |${part2}  / |"

is a little aggressive, as it doesn't check for "#" characters, maybe something like:

sed /tmp/2/etc/fstab -i -e "s|^\s*[^#].* / |${part2}  / |"

instead?

Other than that, I think we're good to go, modulo:

• probably worth regenerating the root_gen.tar.xz file from the original image (does seem to be missing some header files, see my point above)
• the json metadata states this is for Pi2/3, but as a 64-bit image it'll only work on a Pi3

Best, sakaki

[procount]

Excellent! Well done! Will be able to release when I get back. Many thanks.

[sakaki-]

Hi, I've recently put out v1.1.2, as well as a variant image for those using a Pi-Top (sort of RPi3-based DIY laptop). To save you time, I've created the required tarballs (and tested these with PINN, with the modified sed rule), and these are downloadable as follows:

• Standard RPi3 image (v1.1.2):
  • boot_gen.tar.xz, MD5 f75761101e3087f7628a4d0135115bba
  • root_gen.tar.xz, MD5 973ba9d1c6202f5f75b52a6d1a1c3be8
• Pi-Top variant image (NB image names must be changed in json) (v1.1.2):
  • boot_genpt.tar.xz, MD5 712fda8bcf1d00df6e686c7c67a99f21
  • root_genpt.tar.xz, MD5 a07d1d4e556160dcb4bf55b7a750b31c

The same slides etc. can be used for both images.

Thanks! sakaki

PS I have noticed that Xfce shows the 'Settings' filesystem on the desktop (as mountable) but I guess that is to be expected given the NOOBS/PINN layout?

[procount]

Hi, That's excellent. Many thanks. I will copy them onto sourceforge for hosting and let you know when it's done. (Just got back so I've got some sorting out to do first...) I see you are getting very adept at converting your images to PINN format. So, if you prefer to host them yourself, just let me know. You could then have complete control over the issue of new versions and additional ones, such as for the PiTop. Re: Settings, Yes, I guess that is to be expected. Unless you know of a way to hide it.

[sakaki-]

OK well let's see how this goes and then I may start hosting the files for the next release onwards. PS according to this thread if the Settings partition is present in the /etc/fstab (as a noauto entry) it will not show up on the desktop. So I guess you could mkdir -p /mnt/Settings on the root and then >> the necessary line to the end of /etc/fstab (in partition_setup.sh)?

[procount]

I've downloaded them now, so will test and host them shortly.

[procount]

Re; Settings, I will need to have a think about that - whether I can infer the partition device ( /dev/sda5, /dev/mmcblk0p5, or a PARTUUID=xxxx-05) or whether I need to pass it as an additional parameter to the script, so I'll leave it for the moment.

[sakaki-]

OK no problem. FWIW, I've tried manually setting the line (/dev/mmcblk0p5 /mnt/Settings ext4 defaults,noatime,noauto 0 0) into /etc/fstab, and it does indeed stop the "Settings" icon showing up greyed out on the desktop.