NOOBS won't boot on SDXC (256 & 512GB) cards

[ThomasFreedman]

NOOBS 3.0.0 - Used gparted 0.25,9 on Debian Linux (Stretch v 9.8, OS kernel v 4.14) to format the entire card with fat32. Copied all of the unzipped files downloaded from the Raspberry Pi website (https://www.raspberrypi.org/downloads/noobs/) to the root of the sd card. Booted in RPi3 (not +), but got an error on 256 stating it could not resize the fat32 partition. I answered that dialog and another progress bar appeared and never got beyond that.

On the 512GB sd card I just got a kernel panic and system froze.

This behavior was repeatable. Both sd cards were Samsung EVO. The 512GB card was green & white, class 3, write speed 90MB/s. The 256GB sd card is red and white, but had same specs. I had no difficulty using either of those cards with Raspbian Lite, installed with dd on a linux desktop. The cards are fine.

When I put the sd cards back in the Linux system and review their structure it appears to be the same as a 32GB sd card, except the root partition size is very big. Gparted shows no errors.

[procount]

Formatting any SD card >32GB with a standard tool like gparted will result in the format being exFAT, not FAT32, because "themz the rulez"! For such large size SD cards you need to use a special tool to force FAT32, but I forget the name of this app.

So an easy way is to DD raspbian Lite onto your card as you did before. Then delete the files on the boot partition and replace them with the files from the noobs_lite.zip file (not full noobs) and boot it. NOOBS should be able to partition the rest of the drive ok following that.

Why are you using such large cards with NOOBS?

NOOBS is primarily used to get beginners started (you don't sound like a beginner) or to multi-boot several OSes. If you are in neither of these categories, you might find it easier to flash your chosen OS onto the SD card with Etcher.

If you are using them to multi-boot many OSes, be aware that NOOBS can only install the OSes all at once at the initial installation. It is not so easy after that to change an OS, or reinstall it without re-doing the whole card. if that is your aim, you might want to look at PINN which gives you more features to backup/restore/replace individual OSes without affecting the other OSes. PINN is also available as an image you can flash with Etcher, which is another way to avoid this FAT32 formatting problem.

[ThomasFreedman]

'because "themz the rulez" '

Hmmm... sounds wrong, but NOT saying it is. With a GNU tools like gparted which I've used zillions of times over the years, AND which provides initialization for many different file types, it seems odd it would say fat32 and format to a different standard.

I use NOOBS cuz it was expedient and convenient. Also the project I'm working on has many "NEWBIE" user types and there is much more documentation for such users with much less confusing jargon etc.

I have noticed odd behavior that leads me to believe you are right about gparted formating to exFAT. When I fire up the Pi with a sdxc card formated with it there are strange delays. One for example is that df -h doesn't show full capacity right away, it progressively increases (and rather slowly at that) until it finally stabilizes at the proper amount for that size sd card. I hypothesized it was being resized in the background and when the resize was done the capacity would be right.

Weird thing to counter your idea is I don't see that on a 64GB sd card; those seem to work identically to 32GB. Also, I can use the sd card duplicator utility in the non-light version installed with NOOBS to dupe a 32GB card onto a 64GB card and when it is booted resizing occurs and rather quickly, in fact prior to the OS actually being booted as I recall.

Thanks for the tip / work around for installing NOOBS tho, that may be a good way to go.

If I understand what you said properly, I should be able to install NOOBS normally if I insure the full capacity is formated to FAT32, if that's even possible. I also prefer to use more native tools rather than 3rd party tools like etcher.

[procount]

The biggest sd card I have used is 64GB which formatted as exFAT with the SDA formatting tool and wouldn't boot, so I used my etcher image and it then worked fine. So the rest is speculation on my behalf and passing on info from other people who have experienced this issue.

You don't have to format the whole card as FAT32 for noobs (which can cause the exfat issue depending on the tool you use and the size of the card). You only need the first partition on the card to be fat32 so that it will boot. Noobs will partition the rest of the card for you.

So you can just create a 64MB partition, format it as fat32, unzip noobs to it and boot it. Noobs will do the rest. That's essentially what my Etcher image does.

[lurch]

@procount see https://github.com/raspberrypi/documentation/blob/master/installation/sdxc_formatting.md (which I mentioned on @ThomasFreedman 's other issue ). Does gparted natively support exFAT now? (it didn't last time I checked, but that was a long time ago)

[procount]

Ah yes. I guess that's the tool I was thinking of. No idea about gparted. I admit to my speculation about that aspect thinking it would agree with the standards as your link refers.

[lurch]

Just did a bit of searching, and found https://gparted.org/features.php

For those not aware, one of the problems with exFAT is that it contains Microsoft patents https://en.wikipedia.org/wiki/ExFAT#Other_implementations

[ThomasFreedman]

I updated my OP, as it was missing a crucial NOT. Glad there were no trolls ready to pounce on that mistake! :)

I've been looking for a native Linux tool to format to FAT32, not exFAT for sdxc cards, but I can't find any. So it's good to know NOOBS will resize the base partition to fill the entire card. This may be another reason to use NOOBS, b/c using dd to copy an image to the card results in multiple partitions, at least for the latest Raspbian Lite version.

I'm not sure how to create a partition table for a large sdxc card on Linux tho. I mean, I suspect the partition table is format specific, so on an sdxc card it would be exFAT, not FAT32, unless dd creates the partition table as well.

I'll use gparted, format to FAT32, then create an EXT4 linux partition on it. Then, I'll dd a Raspian Lite image over to it and see if it works. If it does it tells me the dd writes a new partition table. If the img shows up under EXT4 then it doesn't.

[lurch]

@ThomasFreedman I think you're getting very confused, and unfortunately the slight misinformation from @procount didn't help :wink:

Regarding "themz the rulez" see https://www.sdcard.org/developers/overview/capacity/

Partition tables come in two flavours, MBR and GPT. More info at Wikipedia: https://en.wikipedia.org/wiki/Disk_partitioning https://en.wikipedia.org/wiki/Master_boot_record https://en.wikipedia.org/wiki/GUID_Partition_Table (generally only needed for disks larger than 2TB)

The Pi can only boot from cards with an MBR partition table.

The partition table isn't format-specific. An out-of-the-box SDHC card (i.e. one that's 32GB or smaller) will have an MBR partition table with a single FAT32 partition. An out-of-the-box SDXC card (i.e. one that's 64GB or larger) will have an MBR partition with a single exFAT partition.

Gparted doesn't support creating exFAT partitions, see the link I posted earlier https://gparted.org/features.php It's fine to use it for making a large FAT32 partition.

The bootloader in the Pi's ROM can only boot from FAT16 and FAT32 partitions - AFAIK if you tried to boot off an exFAT partiton then you wouldn't even get as far as the Pi's rainbow-square screen.

The partition table is simply the first 512 bytes on a disk, so writing an image with dd (or Etcher) also writes the partition table. Which is why the Raspbian image contain multiple (fixed size) partitions. When you first boot Raspbian after having written it onto an SD card, it then looks at the actual size of the SD card, and resizes the root partition (and the filesystem on the root partition) to use up all the free space on the SD card (and this process indeed might be slow for very large SD cards). More info at https://github.com/raspberrypi/noobs/wiki/Standalone-partitioning-explained

NOOBS doesn't resize the base image to fill the entire card - it actually resizes the boot partition to be just-big-enough to contain all the NOOBS files; and then partitions up the rest of the card for installing the other OSes into. More info at https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained

So, hopefully that all answers more questions than it causes :rofl:

And WRT your original problem: if you're getting errors displayed by NOOBS, then your card must have been formatted with a FAT32 partition (and an MBR partition table), otherwise your Pi wouldn't have even got that far. However I don't know why you're getting those errors. @XECDesign has NOOBS ever been tested on such big SD cards? Perhaps the filesystem-resizing code in NOOBS has trouble coping with such large partitions? (in which case @procount 's suggestion of using his "PINN Etcher image" would be a valid workaround for now)

[procount]

Apologies if I misled :wink:

(@lurch - I'd nearly finished this post, when yours popped up saying the same things, but yours is better so I trashed mine 🥇 )

I think the problem with partitioning is due to the way the technology has advanced and yet still has to maintain backwards compatibility. So it creates artificial C,H,S references for an LBA accessed partition that must end on a cylinder boundary and on some other boundary (4K/MB or something?), even though C,H,S values have no relevance to an SD card. I think sometimes these constraints conflict and hence cause problems. Maybe this is the issue with 256/512GB cards 🤷‍♂️

[ThomasFreedman]

Thanks everyone and especially you @lurch for the detailed info, including the note that the Pi can't boot GPT partitioned cards.

Since now you've confirmed what I originally thought that gparted does support large FAT32 partitions (and the 0.25 version doesn't provide an exFAT format option. idk about latest 0.33 version) then I should be able to use that to resize the root partition to fill the entire remaining capacity so NOOBS or Lite won't need to. idk how it determines is a resize is required, but hopefully using gparted as noted above will prevent the auto resize and therefore I should see full capacity reported by df -h immediately.

[lurch]

@ThomasFreedman I think you're still getting mixed up between "NOOBS", "boot" and "root" partitions, and what gets resized and when :wink: Re-read the two "partitioning explained" NOOBS wiki links I posted above :arrow_up: :smiley_cat:

[ThomasFreedman]

I believe I'm pretty clear on the distinctions, tho more familiar with Lite as it only has 2 partitions. I don't recall looking at a Lite sd card after it was booted with gparted.

I'll certainly review the info. For one thing it may clear up confusion regarding how a MSDOS partition table can contain so many partitions that I see with NOOBS cards after booting. I know about extended partitions, but gparted should show those as extended and I don't think it did.

[ThomasFreedman]

I'll need to review gparted again with NOOBS and Lite installations both before and after booting to visualize the partitions. I reviewed the wiki on MBR, very detailed info there, most of which I am familiar with.

Regarding the resizing operation performed by the Pi, that is only done for the root partition right? All I was saying was I could use gparted to do the resize so the Pi wouldn't need to. That would eliminate a bug in the Pi resize code as the cause of hanging problem for extra large sdxc cards, as well as seeing if it eliminated the delay in df -h showing full capacity.

[procount]

Here is an image from gparted of a NOOBS-style formatted SD card with 3 OSes installed. Note how all the logical partitions (5-11) are contained within the extended partition 2 (in cyan)

[procount]

I think the resizing errors you are referring to are the initial reformatting of the SD card that NOOBS does BEFORE it installs any OSes, so it has nothing to do with boot or root partitions. If you have formatted the whole SD card as FAT32, installed NOOBS and then booted it, NOOBS will attempt to shrink partition 1 from 256/512GB down to its minimum size and then create an extended partition to cover the rest of the disk. My hypothesis is that this FAT32 shrinking is causing the issue. A small partition of 64MB in size is better off using FAT16, as in the image above. So you could use Gparted to create a smaller initial FAT16/32 partition to install NOOBS onto. This is similar to using Etcher to install my PINN image. NOOBS will still resize it, but maybe resizing it from a much more similar size instead of from a HUGE size to a TINY size will be less problematic? 🤷‍♂️

[procount]

NOOBS does not resize any OS partitions, it only resizes the initial partition 1 to make space for the extended partition. Thereafter it simply creates OS partitions of the correct size and copies the files into each partition. In fact, I remove code in any OS that resizes the root partition on installation for any OS that I convert, because this is simply not needed in a NOOBS/PINN installation.

[ThomasFreedman]

Ahhhh, I grok you now @procount. And thx for the gparted pic, I haven't confirmed it here yet. It will be a bit different if only 1 OS, but the structure (and the use of an extended partition for all other items / OSs) should be the same.

So I will try to format 1 small partition to put NOOBS in, and leave the rest unpartitioned and see if that boots. If so it would seem to confirm your theory.

It still doesn't explain the slow incremental rise of capacity shown by df tho. That is taking place in the root partition, while it's active ! I therefore don't think it is actually a resize of the partition, but something else.

[ThomasFreedman]

I created a MBR partition table and then created a 4GB FAT32 partition on it, leaving the rest unallocated. I copied NOOBS 3.0.0 over to it. When it booted in my new RPi3+ it took some time to resize the partition, but then NOOBS popped up. I tried to connect to the net with WiFi to my unsecured SSID which always works on the RPi3, but no go on the 3+. It finds the SSID just fine, but it leaves the username & password fields grayed out, which I thought was normal. However I waited 5 minutes and I finally just canceled the attempt and went on to install Raspbian. It's now showing the slide show, but after 10 minutes progress shows only "20MB of 4079MB written (3.0 MB/sec). Just changed to "Raspbian Full: creating filesystem (ext4)"

Looks to me like it will work. It definitely confirms @procount's theory about why it was locking up. It appears the resize code fails in resizing the single huge FAT32 partition.

I'll let it continue. It went back to slide show, but the status remains the same, no further progress shown, but green light is on solid so it may just take it awhile to format that space to ext4. We'll see...

[lurch]

Hmmm, one thing I didn't think to suggest yet: it'll probably take a long time to run, but given how big your microSD cards are it might be worth running h2testw or F3 over them, to check they're genuine and that they're functioning correctly.

[ThomasFreedman]

Not so fast - it timed out with a popup saying: "Raspian Full: Error mounting filesystem".

I pulled the card and put it into my linux system. I can't take a screenshot as the screen memory is protected by the OS for security reasons. The structure looks good, there are 2 partitions: RECOVERY, and the extended, which contains SETTINGS (ext4), boot (FAT32), and root (ext4). The root partition is 248.16GB, but with an error. This is most of the info screen on that ext4 partition:

Filesystem volume name: root Last mounted on: Filesystem UUID: 878f7996-dcae-44ba-b94f-3699a872d1ad Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file uninit_bg dir_nlink extra_isize Filesystem flags: unsigned_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 16269312 Block count: 65053696 Reserved block count: 3252684 Free blocks: 63984743 Free inodes: 16269301 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1008 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Wed Dec 31 19:03:04 1969 Last mount time: n/a Last write time: Wed Dec 31 19:31:16 1969 Mount count: 0 Maximum mount count: -1 Last checked: Wed Dec 31 19:03:04 1969 Check interval: 0 () Lifetime writes: 133 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 3f991dd5-943a-4350-8663-c71abba9aed0 Journal backup: inode blocks

dumpe2fs 1.43.4 (31-Jan-2017) Journal superblock magic number invalid!

Unable to read the contents of this file system! Because of this some operations may be unavailable. The cause might be a missing software package. The following list of software packages is required for ext4 file system support: e2fsprogs v1.41+.

[ThomasFreedman]

That is a mighty old utility. I would prefer the tool by RMPrepUSB, who I've corresponded with quite a bit. He's a developer that knows his stuff and creates some great tools.

I may chk it, but I'd be very surprised if the problem was the card. They came from Amazon and from different sellers, plus packaging was pristine and identical to other Samsung sd cards I've bought before.

Wouldn't hurt to check to rule that out tho.

The 256GB Plus card does appear to be defective. Even gparted can't format that partition without errors. I repeated the exact same procedure with the 512GB card and the installation was successful.

The new RPi3+ board refuses to connect to my unsecured WiFi tho. I looked at the wpa_suplicant conf and it was setup correctly. I pulled the card out of the RPi3+ and put it in a RPi3, and it failed to connect as well during the initial setup. However after completing that initial setup I used the WiFi icon at the top right of the screen and it connected. Although I know the WiFi / Blutooth chip is different on the 3+, it still (apparently) uses the same I/F.

[lurch]

Even gparted can't format that partition without errors.

If the NOOBS partition-resizing code is getting confused by such large SD cards, I guess it's possible that NOOBS is writing an 'invalid' MBR to the card, which might then cause problems with formatting tools? Might be worth totally blanking the card and writing a new MBR, just to be sure?

[lurch]

And I think @procount has much more experience with WiFi configuration on NOOBS / PINN than I do... :smile_cat:

[procount]

Unable to read the contents of this file system! Because of this some operations may be unavailable. The cause might be a missing software package. The following list of software packages is required for ext4 file system support: e2fsprogs v1.41+.

You probably know this already, but I'll say anyway.... I got that error a lot when looking at recent OSes using my aging Ubuntu 14.04 Linux system, due to it not having the latest e2fsprogs. It just means the ext2fs on the SD card is newer than your Linux OS on your PC. I had to swap to using "Debian with Raspbian Desktop" to convert my OSes.

And I think @procount has much more experience with WiFi configuration on NOOBS / PINN than I do...

Not really, I think @XECDesign did all that stuff. I just converted/added some additional wifi drivers for PINN (most of which I have to do again for the latest kernel, when I have some time). I've never tested with an unsecured SSID, although I did manage to connect it to an EAP wifi network by manually editing wpa_supplicant.conf

Large SD cards shouldn't be a problem for the MBR. I've used PINN on a 256GB HDD (not an SD card) without problem, but I installed it with Etcher.

So if the 256GB SD card has been found to be defective, and the 512GB card can be installed OK by creating a small FAT32 partition, can we now conclude that it's the initial resizing of the huge FAT32 partition down to a tiny one for NOOBS that is causing the issue?

[procount]

@ThomasFreedman - Are you willing to do some tests?

Am I right in thinking that you are using the FULL version of NOOBS that includes Raspbian and LibreELec? If so, could you try formatting your whole 512GB card as FAT32 and trying to install the NOOBS-LITE version? It does not include any OSes and is a lot smaller, resulting in different NOOBS behaviour.

Secondly, it would be interesting to know the size of partition that causes the resizing to fail (assuming my theory is correct). So could you repeat your creation of an initial FAT32 partition using gparted, but use initial sizes of say, 15GB, 30GB, 62GB, 126GB, 254GB and 510GB and then try to install the FULL NOOBS version, noting at which initial size the resizing failed?

[lurch]

@procount Also worth noting that it might not be a specific size of partition that fails, but a combination of partition size and whole-disk size? ISTR there were issues before where somebody with a particular-size card had problems with the partition resizing? Might be something to do with the CHS-translation that you referred to earlier? :man_shrugging: https://github.com/raspberrypi/noobs/search?q=Unable+to+satisfy+all+constraints+on+the+partition&type=Issues

[ThomasFreedman]

I'll be happy to do that testing, but it will be Sunday at the earliest. I just got a text that a dear friend is in intensive care ward and I need to go see him. Tomorrow I have a long conf. call, and tonight I need to prepare for it.

As for using Lite, I have installed that as well as I described above. Not sure if you wanted me to test Lite along with NOOBS, please explain how you want that done, as I use dd to copy the Lite to the SD card. And yes, the NOOBS version is 3.0.0 with 2 OSs LibreElec and Raspbian Full.

[lurch]

I hope your friend recovers okay.

As for using Lite...

There's both Raspbian Lite and NOOBS Lite, so referring to just "Lite" will probably cause confusion... :wink:

[ThomasFreedman]

Ahh, I didn't know there was a NOOBS lite. I'll have to search for that.

[lurch]

Oh, and one more point... in your original message you said

but got an error on 256 stating it could not resize the fat32 partition. I answered that dialog and another progress bar appeared and never got beyond that. On the 512GB sd card I just got a kernel panic and system froze.

If you get those error dialogs / messages / panics again during your testing, it'd be useful if you could take photos of them and attach them to this issue :camera: :+1:

I didn't know there was a NOOBS lite. I'll have to search for that.

I provided a link to it above :laughing:

[ThomasFreedman]

I'll see what I can do regarding the photos.

Thanks for the link too!

Also, NOOBS Lite may be a problem on the RPi3+ due to it being a network installer, so I will use the non + unit.

[procount]

Ditto on hoping your friend recovers.

Yes, I meant NOOBS-LITE. It's exactly the same as NOOBS FULL just without the OSes. So in fact you can convert your NOOBS-FULL to NOOBS-Lite just by deleting the folders within the /os folder. One of the problems we're trying to resolve is the initial resizing of the SD card and for this it doesn't matter about the OS installation, network or otherwise, so you can still do it on the 3B or 3B+.

If you have trouble with photos, or viewing the entire error message, it should also be available in the debug log==> press ctrl-alt-f2, login as root/raspberry and view the /tmp/debug file. This is only a temporary file and will be lost if you power down or reboot the pi. As you have another Linux machine, I would suggest copying /tmp/debug to /settings. Then you can read it from the /dev/sdX5 partition if you put your SD card in your linux machine. (press ctrl-alt-f1 if you need to return to the NOOBS GUI screen).

[ThomasFreedman]

I had a little time tonight so I tried to install NOOBS_lite and boot it on the RPi3.

First attempt was to remove the 3 OSs from the os folder of NOOBS_Full. I wiped the 512GB sdxc card by creating a new partition table with gparted, then format the entire card as FAT32. Then I simply did a cp -R /media/<user>/<sdcard>/.

When I put it in the RPi3 it did nothing, no flashing green light, nothing at all.

So I downloaded the actual NOOBS_lite.zip and repeated the process. Same result. I waited 5 minutes but I never saw the green light so the card was never accessed.

Then, I used tar czf to create separate archives for NOOBS_full (without contents of os folder) and NOOBS_lite. The length of the full archive was only 9 bytes larger than the lite version, but I suspect they are essentially identical, except perhaps the version name or something innocuous like that.

Next I resized the card from 512GB down to 256GB, leaving the extra space unallocated. That booted immediately and the noobs menu appeared. I decided to download & install Raspian Lite rather than pull the card and inspect it's structure after it was booted. The install went normally without a hitch.

I pulled the card and inspected with gparted. 3 partitions: boot, settings and root. Root was resized to full capacity (476GB). Now I'll try to increase the size to 384 and see if that works. I would guess that if it boots it will work.

[ThomasFreedman]

384GB does NOT work either. Going down to 320GB... No go. 258GB worked. I pulled the card and gparted showed an extended partition of full capacity (476.84GB) and a SETTINGS partition of 32MB and unallocated 476.81GB.

One last trial I went to was 288GB which did NOT work. The boundary is somewhere in the 30GB between 258 and 288.

I didn't bother to figure out the next higher bit above 256 to toggle, and just hoped 258 was big enough to do it. It may not have been.

[ThomasFreedman]

Really frustrating. There is something strange related to raspi.config OR passwd. After I go thru my routine to set wifi, password and many other items, including locale settings, after I reboot I can't login. When I login initially which works as expected, I do a sudo /bin/bash and then passwd and set the root password. Next I launch raspi.config. When I reboot I can't login under pi or root or ssh.

There is something getting screwed up with locale I suspect, although when I type my passwords as the account name to test the characters appear correctly, they show up properly.

This will be the 3rd time I've redone the sdcard with Raspian lite.

This time I will only set wifi, not change locale at all or keyboard opts. That means it will be British locale & char set. I will set root passwd prior to running raspi.config.

Another annoying thing is that I can't append init=/bin/sh to cmdtext fileto get root prompt as so many posts claim is how to recover passwords. It does not work and never has for me.

[lurch]

This is a totally separate issue to what's being discussed here, and is probably better suited for the Raspberry Pi forums. But why are you trying to explicitly set a root password? Raspbian is designed to work with sudo - see https://www.raspberrypi.org/documentation/linux/usage/root.md

[ThomasFreedman]

It's a habit. If I can't login to Pi account that is a redundant failsafe. But you're right, and I'll bet it was due to fatigue or similar. Last time I left the en_british locale in place rather than removing it, tho I did add the en_us.ut8 as well. Probably a sequence issue. Setting pwrds before running raspi.config is not the way to go. Anyway, nuf said about that. Off topic here.

I did confirm the boundary tho was really close to 256GB. Just adding 4GB and it won't boot, so hopefully that testing will be useful to @procount or whoever.

[procount]

Yes, thank you for the testing. I think that will be useful. So if I read you correctly, the resizing was all done with the LITE version of NOOBS that consumed < 63MB of disk space? It was interesting that even that failed above 256GB. I wasn't expecting that, because NOOBS should have just recreated the whole partition table rather than resizing it. Did you repeat the tests with the FULL version of NOOBS? That would be a truer test of resizability.

[ThomasFreedman]

I think I tried full once, not sure, but you requested I focus on Lite so with only an exception or 2 that's what I did. I think I tried full when I started having these login issues, but it was unrelated to that. I was getting tired and managed to get into a bad sequence I believe. I did at least 3 trials where after rebooting and expecting to run a IPFS install script I've been working on, I couldn't login. Still perplexed about why adding init=/bin/sh no longer seems to work. The boot sequence just stops. I can plug & unplug usb keyboard / mouse and see it reflected on the console. With the Lite version it would be nice to know how to get to a root prompt. From all my googling I saw nothing that indicated the appendage no longer works.

[ThomasFreedman]

Also, holding shift didn't seem to work either.

[procount]

[continuing off-topic: PINN includes the ability to reset your password to whatever you want, without having to mess with init parameters. Adding rescueshell to recovery.cmdline should boot you into a command shell (lite or full are the same) - I think that's still valid in NOOBS. Sometimes you have to wait until you see the raspberry logo before you press the shift key. Alternatively, keep hammering the shift key until it works].

In my post about testing, the first paragraph was about using the Lite version, but the second was actually all about testing with the FULL version. Apologies if I wrote it ambiguously. Nevertheless your test showed up something unexpected anyway.

The reason for testing with both versions is that NOOBS does different things depending on the size of the files on /dev/mmcblk0p1. If they are small (<63MB like in the LITE version) NOOBS will copy them to RAM, recreate the partition table, and then copy the files back again. (So I was surprised with your results of using the Lite version with >256GB partition size). if the files are large (like in the NOOBS FULL version), it cannot copy them to RAM so it relies on parted resizing the partition. My theory is that parted will struggle to convert a very large FAT32 disk size down to a very small disk size. I don't know if it will automatically convert the FAT32 to a more practical FAT16 format?

[ThomasFreedman]

OK, I see. Thx for the details. I just found a (the?) bug in my IPFS script, and it was a Doh! moment of missing the extra > so I was truncating the file.

I'll see what I can do for additional testing. Now that I understand better the distinction between the full and lite boot process, and how RAM is involved.

You guys have a great day. Not sure where in the world you are, but here it sunny and springtime, and I intend to enjoy it!

[lurch]

If I can't login to Pi account that is a redundant failsafe.

See https://www.raspberrypi.org/documentation/linux/usage/users.md

Regarding the init=/bin/sh issue, that's either because Raspbian is using systemd and that doesn't work now, or I wonder if you might be editing the NOOBS cmdline (i.e. recovery.cmdline on partition 1) and not the Raspbian cmdline (e.g. cmdline.txt on partition 6) ? See https://github.com/raspberrypi/noobs/wiki/NOOBS-partitioning-explained again. When you use NOOBS you have a boot partition for NOOBS itself, and a separate boot partition for each of the OSes you install with NOOBS.

Also, the "hammering shift" is a NOOBS thing and not a Raspbian thing :wink:

Myself and @procount are both based in (different areas of) the UK, and it's currently sunny but still a bit chilly :sun_behind_small_cloud:

[ThomasFreedman]

I was confused about which OS adding init=/bin/sh was applicable to. I was using Raspbian Lite created with dd. I was adding init=/bin/sh to cmdline.txt. which doesn't work.

I tried to install NOOBS (not NOOBS-Lite) with an initial partition size of 300GB which failed, as I expected. If the lite version can't handle booting, I didn't expect the full version to boot either. There is some type of firmware boot loader issue related to the partition / card size or their combo. As I said I see zero activity on the green LED, once the threshold is crossed.

[lurch]

ping @ghollingworth - is there any kind of limitation in the bootrom or firmware that might prevent it booting off such massive FAT32 partitions? If so, do we need to need to mention this in the NOOBS documentation?

[ghollingworth]

Yes, there was a bug in the Pi 3 bootrom which used 16 bit integers for some multiplications which limits to 256G

Fixed in Pi 3+

[lurch]

Ahh, interesting!

@ghollingworth Given the beginner-focused modus operandi of NOOBS, I guess we cant't really expect people to create a smaller-sized partition on their card in order to boot NOOBS; so does it make sense to tell a small white lie and say that NOOBS will only work on micro SD cards larger than 256GB on the Pi Model 3B+ and Pi Model 3A+, but that NOOBS is compatible with cards up to 256GB on all other models of Pi?

Has @XECDesign tested NOOBS on such large SD cards?

[maxnet]

Has @XECDesign tested NOOBS on such large SD cards?

Easier to test with USB hard drives, which had same problem in the past.

[ThomasFreedman]

Ahh, so mystery solved regarding booting sdxc cards > 256GB on the Pi3. Now that I have a 3+ I will test noobs-lite with an initial 512GB FAT32 (the entire sdxc card) and verify that works. Probly still has the problem it won't connect to my unsecured SSID, but that's irrelevant to this discussion.

Not even sure how to boot the pi from an external USB device to test as @maxnet suggested, but not necessary since I have a 512GB sdxc card to use.

[lurch]

Not even sure how to boot the pi from an external USB device to test as @maxnet suggested, but not necessary since I have a 512GB sdxc card to use.

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md :slightly_smiling_face: