New USB installation will not boot, but there are no error messages.[SOLVED]

[Karmi]

Problem solved. The issue was that the partition needed to be recognized as bootable from the get go. I had assumed that the installation process would give me a bootable drive, but that was silly of me. I used fdisk to label the partition as EFI and after that I had no more issues. No more than one partition necessary. Now I can get to learning the OS.

I guess this is just part of what control and responsibility over your machine looks like.

Great job at sticking wid the problem!!! Believe I will add a new post on how I, as a Windows 11 Pro user, I install Porteus 5.0 Cinnamon onto a 32GB SanDisk (or Samsung) USB formatted into a fat32 & ext4 partitions. Porteus is incredibly flexible, IMHO!

[Ed_P]

A good write up rusty, thank you.

umount /dev/PENDRIVE_PARTITION
mkfs.fat -F 32 /dev/PENDRIVE_PARTITION

Shouldn't these commands be reversed? If the PENDRIVE is unmounted how can the mkfs.fat command make any changes to it?

[bour59]

@Ed_P if the device is mounted, mkfs can't execute

[Ed_P]

Thank you bour59.

[Rava]

Just as heads up for the lurkers.

I had a 2 GB SD card (obviously not a SDHC card) that I had no real use for (too small for a digital camera), so I decided to use it as my main Porteus external USB boot drive.

Some issues here to consider

The internal SD-card-reader is not only slooooow (it is usually internally connected as USB1.1) but is also unable to boot from, so trying to use that internal SD-card-reader will fail.

There are cheap USB-plug-in SD-card readers but these are often unreliable as hell, I cannot recommend any of the no-brand cheap ones. I use one of my several Delock ones, and they might be more expensive, none of these ever failed me. Choose whatever brand USB-plug-in SD-card reader your local trusted PC store sells, mine just happens to sell Delock.

I formatted the 2 GB into ext2 to keep the read/writing on it to a minimum (because of the lack of journaling), even when my system crashed and I was unable to use REISUB aka the drive was not umounted safely the missing journaling never created any issue.

I just used first fdisk to create the partition and then mkfs.ext2 to format the drive.

This is what fdisk -l /dev/DEVICE tells me:

Code: Select all

Disk /dev/sdc: 1.84 GiB, 1977614336 bytes, 3862528 sectors
Disk model: STORAGE DEVICE  
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: 0x7790a0a0

Device     Boot Start     End Sectors  Size Id Type
/dev/sdc1  *      135 3862527 3862393  1.8G 83 Linux

Know that "Disk model: STORAGE DEVICE " is not really the name of the drive, it is the generic vague name the Delock USB SD-card-reader reports to the system.

When you press the whatever key is needed for your PC to select the drive to boot from, initially better not have any other USB drives plugged in as well (like an external USB hardrive, or a regular USB thumbdrive) so that you see what your drive is called - and compare that to later booting when you have other USB media present and remember what you SD card in USB SD-card-reader is called at your boot media selection screen at boot time.

[Ed_P]

I formatted the 2 GB into ext2

Does your 2 GB SD ext2 card boot on UEFI systems?

[Rava]

Does your 2 GB SD ext2 card boot on UEFI systems?

I have no UEFI system, so I cannot tell.

Also, the 2 GB SD ext2 card is mainly used for one specific system as it only loads the initrd and kernel (since my kernel issue loading from the internal hard disk is still unresolved) and loads all other modules from the internal drives as its default boot.
There also exists the option of loading everything from the 2 GB SD ext2 card … but usually all of my most-recently-updated modules are outdated on it since my automated creating and updating scripts only work for the internal solution. (I mean my 991-usr_local_bin_RECENT.xzm and 992-rootcopy_5.0-RECENT.xzm modules via my make-991-usr_local_bin.sh and make-992-rootcopy.sh module creation and updating via base/ script [*])

_____________
[*] indeed "script" is correct since it is one script and a symlink to to, and the script determines what to do based on the name it was executed as:

Code: Select all

root@porteus:/# file /usr/local/bin/make-992-rootcopy.sh
/usr/local/bin/make-992-rootcopy.sh: symbolic link to make-991-usr_local_bin.sh

[Ed_P]

ext2 formats do not boot on EFI systems. ext4 doesn't either.

[Rava]

ext2 formats do not boot on EFI systems. ext4 doesn't either.

Thanks for the headsup.
I presume you either gave to use VFAT or NTFS?

[Ed_P]

Actually FAT32 is the requirement.

[Rava]

Actually FAT32 is the requirement.

So, windows no longer uses NTFS as boot partition?

[beny]

fat 32 is used for the ESP partition, the core of uefi system.

[itrukrakso]

Addition:https://wiki.archlinux.org/title/EFI_system_partition

The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see UEFI specification version 2.9, section 13.3.1.1), but any conformant vendor can optionally add support for additional file systems; for example, the firmware in Apple Macs supports the HFS+ file system.

To prevent potential issues with other operating systems and since the UEFI specification says that UEFI "encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media"[4], it is recommended to use FAT32. Use the mkfs.fat(8) utility from dosfstools:

# mkfs.fat -F 32 /dev/sdxY

If you get the message WARNING: Not enough clusters for a 32 bit FAT!, reduce cluster size with mkfs.fat -s2 -F32 ... or -s1; otherwise the partition may be unreadable by UEFI. See mkfs.fat(8) for supported cluster sizes.

For partitions smaller than 32 MiB using FAT32 may not be possible. In which case, format it to FAT16 or even FAT12. For example, a 2 MiB ESP will only be able to support FAT12:

# mkfs.fat -F 12 /dev/sdxY

[Rava]

but any conformant vendor can optionally add support for additional file systems; for example, the firmware in Apple Macs supports the HFS+ file system.

That means, if a hardware vendor wants it to, it could add in its firmware support for ext[234] if they wanted?

[nanZor]

Awesome info.

For most new users, starting with a fresh usb taken out of the package, copying the files, and running the proper installer script should suffice.

But if you are using a well-used stick that has had many projects on it, and you have Windows handy, I can recommend using RUFUS to create a "non bootable" stick. It will wipe the drive and any remnants of funky partitioning that other utils might miss. Most notably, if you see what was once a 32gb stick show up as say with only 21gb or some other funkiness, the "non bootable" option in Rufus can clear it properly while Windows own formatter won't and you can start the Porteus process again.

But sure, gparted is my friend too.

If one is using SD cards for Porteus, and you have Windows / Mac handy, you can make sure it is formatted properly by those who wrote the specs for oem's. At least once in it's lifetime. And unlike *anything* else, these guys have the ability to rewrite the firmware inside your SD card's actual controller in case it is corrupt - which gparted, windows, mac and others can't touch:

https://www.sdcard.org/downloads/formatter/

Sometimes I'll use this to make sure the SD card controller's internal firmware is programmed properly and THEN use gparted or other utils for special formatting. This was very important when I was running SBC or single-board computers using SDcards - the sdcard.org formatter is the only one that knows how to gain access to rewrite the internal firmware for best performance / corruption fixes before I installed the OS on it. But use a real sdcard port - I'm not sure a usb<>sdcard dongle will do this correctly.