Porteus Kernel Builder

[nanZor]

FAT supports EFI, but you can't boot EFI witih NTFS.

Actually you can. That's one reason why the Rufus burner allows for an NTFS boot for EFI should you choose.

https://github.com/pbatard/rufus/wiki/F ... hould_Blah

I think the keyword here is that this myth got a spin on the internet, and never let go.

[Ed_P]

Have you ever tried that nanZor?

[nanZor]

I have. I just ran it on the latest Porteus x86_64 RC, saved the logs, and rebooted.

Pretty uneventful, although after reboot, it hangs at

Code: Select all

Launching NTFS EFI Loader 'EFI\bootx64.efi'

Which I think means that perhaps ntfs support is not part of the bootx64.efi options? I'm not a bootloader creator, just a peon poking around.

Here's the lengthy details of the log:

Code: Select all

Format operation started
Requesting disk access...
Will use 'D:' as volume mountpoint
Deleting partitions...
Deleting ALL partitions from disk '\\?\PhysicalDrive1':
● Partition 1 (offset: 1048576, size: 14.9 GB)
● Partition 2 (offset: 16007507968, size: 512 KB)
Opened \\.\PhysicalDrive1 for exclusive write access
Analyzing existing boot records...
Drive has a Zeroed Master Boot Record
Clearing MBR/PBR/GPT structures...
Erasing 128 sectors
Deleting partitions...
Partitioning (GPT)...
Adding extra partition
Reserved 33 tracks (1 MB) for extra partition
Writing UEFI:NTFS partition...
Closing existing volume...
Waiting for logical drive to reappear...
Formatting (NTFS)...
Using cluster size: 4096 bytes
Quick format was selected
Creating file system...
Format completed.
Writing master boot record...
Drive has a Zeroed Master Boot Record
Using Rufus protective MBR
Found volume GUID \\?\Volume{412e3094-a2cd-11e9-8596-e82a44c9fd37}\
\\?\Volume{412e3094-a2cd-11e9-8596-e82a44c9fd37}\ was already mounted as D:\
Disabling file indexing...
Successfully remounted \\?\Volume{412e3094-a2cd-11e9-8596-e82a44c9fd37}\ on D:
Copying ISO files...
Extracting files...
Image is an ISO9660 image
This image will be extracted using Joliet extensions (if present)
Extracting: D:\EFI\boot\bootx64.efi (172.2 KB)
Extracting: D:\EFI\boot\chain.c32 (27.8 KB)
Extracting: D:\EFI\boot\ldlinux.e64 (130.7 KB)
Extracting: D:\EFI\boot\libcom32.c32 (191.8 KB)
Extracting: D:\EFI\boot\libmenu.c32 (26.5 KB)
Extracting: D:\EFI\boot\libutil.c32 (23.6 KB)
Extracting: D:\EFI\boot\linux.c32 (5.9 KB)
Extracting: D:\EFI\boot\menu.c32 (31.0 KB)
Extracting: D:\EFI\boot\porteus.png (95.5 KB)
Extracting: D:\EFI\boot\syslinux.c32 (11.5 KB)
Extracting: D:\EFI\boot\syslinux.cfg (40 bytes)
Extracting: D:\EFI\boot\vesamenu.c32 (31.6 KB)
Extracting: D:\USB_INSTALLATION.txt (1.5 KB)
Extracting: D:\boot\Porteus-installer-for-Linux.com (189.2 KB)
Extracting: D:\boot\Porteus-installer-for-Windows.exe (116.2 KB)
Extracting: D:\boot\docs\GNU_GPL (17.6 KB)
Extracting: D:\boot\docs\License.txt (255 bytes)
Extracting: D:\boot\docs\cheatcodes.txt (19.9 KB)
Extracting: D:\boot\docs\install.txt (19.9 KB)
Extracting: D:\boot\docs\requirements.txt (1.4 KB)
Extracting: D:\boot\syslinux\boot.cat (2 KB)
Extracting: D:\boot\syslinux\chain.c32 (37.8 KB)
Extracting: D:\boot\syslinux\extlinux.conf (20 bytes)
Extracting: D:\boot\syslinux\initrd.xz (803.4 KB)
Extracting: D:\boot\syslinux\isolinux.bin (24 KB)
Extracting: D:\boot\syslinux\isolinux.boot (2 KB)
Extracting: D:\boot\syslinux\isolinux.cfg (20 bytes)
Extracting: D:\boot\syslinux\lilo.conf (1.2 KB)
Extracting: D:\boot\syslinux\plpbt (42.6 KB)
Extracting: D:\boot\syslinux\porteus.cfg (3 KB)
Extracting: D:\boot\syslinux\porteus.png (90.5 KB)
Extracting: D:\boot\syslinux\reboot.c32 (800 bytes)
Extracting: D:\boot\syslinux\syslinux.cfg (20 bytes)
Extracting: D:\boot\syslinux\vesamenu.c32 (152.1 KB)
Extracting: D:\boot\syslinux\vmlinuz (4.2 MB)
Extracting: D:\porteus\base\000-kernel.xzm (57.3 MB)
Extracting: D:\porteus\base\001-core.xzm (125.6 MB)
Extracting: D:\porteus\base\002-xorg.xzm (90.7 MB)
Extracting: D:\porteus\base\003-xfce.xzm (18.4 MB)
Extracting: D:\porteus\make_iso.sh (1015 bytes)
Extracting: D:\porteus\porteus-v5.0-x86_64.cfg (681 bytes)
Created: D:\syslinux.cfg
Finalizing, please wait...
Created: D:autorun.inf
Created: D:autorun.ico
NTFS Fixup (Checkdisk)...
Volume label is Porteus.

Stage 1: Examining basic file system structure ...
  256 file records processed.
File verification completed.
  0 large file records processed.
  0 bad file records processed.

Stage 2: Examining file name linkage ...
  298 index entries processed.
Index verification completed.
  0 reparse records processed.
  0 reparse records processed.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
  21 data files processed.

Windows has scanned the file system and found no problems.
No further action is required.

  15631307 KB total disk space.
    323128 KB in 50 files.
        84 KB in 23 indexes.
     24287 KB in use by the system.
     23136 KB occupied by the log file.
  15283808 KB available on disk.
      4096 bytes in each allocation unit.
   3907826 total allocation units on disk.
   3820952 allocation units available on disk.
NTFS Fixup completed.

Found USB 2.0 device 'SanDisk Cruzer Blade USB Device' (0781:5567)
Using autorun.inf label for drive D: 'Porteus'
Found card reader device 'Toshiba 032G34'
1 device found
Disk type: Removable, Disk size: 16 GB, Sector size: 512 bytes
Cylinders: 1946, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 2
Disk GUID: {8FA3C79D-0856-4F28-97AF-7FDFCAC6776E}
Max parts: 128, Start Offset: 17408, Usable = 16008575488 bytes
Partition 1:
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'Microsoft Basic Data'
  ID: {9D606E1E-D898-46F5-9424-E426A86C335C}
  Size: 14.9 GB (16006459392 bytes)
  Start Sector: 2048, Attributes: 0x0000000000000000
Partition 2 (UEFI:NTFS):
  Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7}
  Name: 'UEFI:NTFS'
  ID: {1AA2351F-6B63-490C-B2E9-2D443CD4CBB0}
  Size: 512 KB (524288 bytes)
  Start Sector: 31264664, Attributes: 0x0000000000000000

So although we seem to hang at bootx64.efi, the computer recognizes it as being valid to boot, and attempts to do so.

Had this utility incoporated ext filesystems, I suppose it would work too. Suggest that doing something like this manually would work.

I'm finding it interesting burning other distro iso's, and taking a look at the burn log. It turns up some interesting things, but would take a dev to see if what it finds is benign or useful. I'm not in that pay-grade.

[Ed_P]

Interesting. Thank you for the update.

I wonder if all EFI machines support NTFS.

[neko]

Most recent versions of build examples were updated.

Please refer to the top article of this thread.
Porteus Kernel Builder

-----------------------------
Maybe, a trouble about kernel build is depending on 3 reasons.
1. Config
2. AUFS patch
3. Compiler

Now, there are 2 problems.
(1) "Paragon NTFS" problem that was reported by @babam.
Porteus Kernel Builder (Post by babam #72695)

(2) "Slow boot times" problem that was reported by @M. Eerie
Porteus Kernel Builder (Post by M. Eerie #72743)

Both problems had done no trouble on old kernel version.
Therefor I change AUFS patch applying way.
First All AUFS patches are applied.
If it is fail, "basic patches and optional patch" are applied.
If it is fail, only "basic patches" are applied.

Thanks

[nanZor]

Neko - thank you very much for all your kernel work! Outstanding.

Ed - the UEFI spec doesn't really mandate use of vfat. You can use ANY filesystem you want for EFI partitions, as long as your efi driver supports it.

Hence, if one really wanted to, they could be "fat free" and run solely say from an ext filesystem setup throughout. But, not many people try it and rely solely on heresay or glossed-over specs.

[Rava]

Hi neko, some folks again ran into the already known issue when trying to compile Nvidia drivers or building VirtualBox under the official 5.0rc1 due to the very unfortunate mismatch between system gcc and kernel gcc:

@all and @Rava, my and fulalas's request with update kernel for Porteus-5.0rc1 under GCC 9.1.0 was ignored.
brokenman builded (not neko) kernel 5.1.5 under GCC 8.3.0!
In Russian topic the user SaintAnd get this error

The kernel was built with gcc version 8.3.0 (GCC), but the current compiler version is cc (GCC) 9.1.0.

when he tried to build nvidia driver.

Sadly, you gave no info if the 5.1.17 kernel from the initial post is compiled using the correct gcc version of (GCC) 9.1.0:

64bit-ALL-kernel5.1.17.tar (92 M)
http://www.mediafire.com/file/r6l6s2at2 ... 5.1.17.tar

If it is, please can you keep this version uploaded for a while and also tell us that we can use 64bit-ALL-kernel5.1.17.tar for 5.0rc1 as replacement.

If it is not compiled using the correct gcc version of GCC 9.1.0 can you please compile a recent 5.1.* kernel for x86-64 for replacing the one in 5.0rc1 official, so that folks like Blaze, fulalas, SaintAnd and yours truly can either compile a Nvidia driver for e.g. older hardware, or create Virtual box.

And you can either please compile a 5.1.5 kernel using GCC 9.1.0 or a never one - but then we would need the matching 000-kernel.xzm as well.

Or is 000-kernel.xzm always part of your kernel*.tar files?

[neko]

@Rava

Sadly, you gave no info if the 5.1.17 kernel from the initial post is compiled using the correct gcc version of (GCC) 9.1.0:

---->
Please refer to Porteus Kernel Builder (Post by neko #52232)

--------------------------------------------------------------
[Current AUFS Patch version]
AUFS_VERSION "5.x-rcN-20190610"
AUFS_VERSION "5.1-20190610"
AUFS_VERSION "4.19-20190610"


--------------------------------------------------------------
[Updated kernel Example]
==== AUFS Kernel only for Porteus ====
Simple package (vmlinuz, 000-kernel.xzm, 06-crippled_sources-NNN-XXbit.xzm)
...
...
[5.1.17] <---NEW : "All patches" patching was done by manual operation.
32bit-ALL-kernel5.1.17.tar (87 M)
http://www.mediafire.com/file/ulwpb1izx ... 5.1.17.tar
md5sum: 1238d86840b59199a82457b6571744e1 32bit-ALL-kernel5.1.17.tar

64bit-ALL-kernel5.1.17.tar (92 M)
http://www.mediafire.com/file/r6l6s2at2 ... 5.1.17.tar
md5sum: 1c8dc8e36541468f04a97b3abbc9ae2b 64bit-ALL-kernel5.1.17.tar
...
...

Note 1: Compiler was used at building 5.1.3
gcc-8.3.0-x86_64-1

Note 2: Compiler was used at building 5.2, 5.1.17, 4.19.58
gcc-9.1.0-x86_64-1

If it is, please can you keep this version uploaded for a while and also tell us that we can use 64bit-ALL-kernel5.1.17.tar for 5.0rc1 as replacement.

---->
The config that was used at build 64bit kernel 5.1.17: v5.1.17/64/64bit.config:# Compiler: gcc (GCC) 9.1.0

Porteus-OPENBOX-v5.0rc1-k5.1.17-x86_64.iso was built
by replacing (vmlinuz & 000-kernel.xzm) of Porteus-OPENBOX-v5.0rc1-x86_64.iso
with ones of 64bit-ALL-kernel5.1.17.tar.

Porteus-OPENBOX-v5.0rc1-k5.1.17-x86_64.iso (335 M)
http://www.mediafire.com/file/1a7orwa9z ... x86_64.iso
md5sum: dcb01dc66c38d5a263753dd0b62ecb9e Porteus-OPENBOX-v5.0rc1-k5.1.17-x86_64.iso


Thanks.

[Rava]

@Rava

Sadly, you gave no info if the 5.1.17 kernel from the initial post is compiled using the correct gcc version of (GCC) 9.1.0:

Sorry, dummy me only read the paragraph about 5.1.17 kernel and missed the above more generic info. Curse you selected but quick reading.

As you quoted, all we need is there.
___________________________________________________________

Could you please keep the x86-64 version

64bit-ALL-kernel5.1.17.tar (92 M)
http://www.mediafire.com/file/r6l6s2at2 ... 5.1.17.tar
md5sum: 1c8dc8e36541468f04a97b3abbc9ae2b 64bit-ALL-kernel5.1.17.tar

uploaded for the time being so that everyone using the official 5.0rc1 can get a kernel compatible with the system's gcc - so that we can all use the very same kernel if we need to compile e.g. nvidia drivers or create virtualbox or such - at least as long the official 5.0rc1 is not replaced by the official 5.0rc2. (And hopefully with 5.0rc2 we get ISOs with kernel, 000-kernel.xzm and system and 0*-devel.xzm all having compiled using the very same gcc version.) That would be greatly appreciated.

[Blaze]

I think that not bad if brokenman replace kernel and all stuff (vmlinuz, 000-kernel.xzm, 06-crippled_sources.xzm) for him to current 5.1.xx kernel by neko in all ISO files and sync updated ISO files in the all Porteus mirrors.

[M. Eerie]

I think that not bad if brokenman replace kernel and all stuff (vmlinuz, 000-kernel.xzm, 06-crippled_sources.xzm) for him to current 5.1.xx kernel by neko in all ISO files and sync updated ISO files in the all Porteus mirrors.

+1

[M. Eerie]

Neko - thank you very much for all your kernel work! Outstanding.

Ed - the UEFI spec doesn't really mandate use of vfat. You can use ANY filesystem you want for EFI partitions, as long as your efi driver supports it.

Hence, if one really wanted to, they could be "fat free" and run solely say from an ext filesystem setup throughout. But, not many people try it and rely solely on heresay or glossed-over specs.

nanZor marry me

[M. Eerie]

The config that was used at build 64bit kernel 5.1.17: v5.1.17/64/64bit.config:# Compiler: gcc (GCC) 9.1.0

Porteus-OPENBOX-v5.0rc1-k5.1.17-x86_64.iso was built
by replacing (vmlinuz & 000-kernel.xzm) of Porteus-OPENBOX-v5.0rc1-x86_64.iso
with ones of 64bit-ALL-kernel5.1.17.tar.

Thanks very much, neko
I've tried the 5.1.17 kernel at work and after 15' didn't boot. Will try the version of OPENBOX 5.01 RC iso and report.

EDIT:

Will try the version of OPENBOX 5.01 RC iso and report.

--> This one WORKS

Cheers!

[Blaze]

Porteus 5.0 RC1 x86_64 + kernel 5.1.17 on old NVIDIA GeForce GTS 250

Code: Select all

   cc1: some warnings being treated as errors
   make[3]: *** [/usr/src/linux-5.1.17/scripts/Makefile.build:276: /tmp/selfgz1110/NVIDIA-Linux-x86_64-340.107/kernel/nv-drm.o] Error 1
   make[2]: *** [/usr/src/linux-5.1.17/Makefile:1571: _module_/tmp/selfgz1110/NVIDIA-Linux-x86_64-340.107/kernel] Error 2
   make[2]: Leaving directory '/usr/src/linux-5.1.17'
   make[1]: *** [Makefile:169: sub-make] Error 2
   make[1]: Leaving directory '/usr/src/linux-5.1.17'
   NVIDIA: left KBUILD.
   nvidia.ko failed to build!
   make: *** [Makefile:192: nvidia.ko] Error 1
-> Error.
ERROR: Unable to build the NVIDIA kernel module.
ERROR: Installation has failed.  Please see the file '/var/log/nvidia-installer.log' for details.  You may find suggestions on fixing installation problems in the README available on the Linux driver download page at www.nvidia.com.

Full log >>> https://pastebin.com/ixqgefsN

Probably this problem in the old nvidia driver and it is not compatible with the new Porteus 5.0 RC1 base (xorg-server etc) and a new kernel.
If look at NVIDIA drivers - version: 340.107 from 2018.6.6

• Updated nvidia-installer in the 340.xx legacy driver series to default to installing the driver without the NVIDIA Unified Memory kernel module if this module fails to build at installation time. The 340.xx legacy Unified Memory kernel module is incompatible with recent Linux kernels, and the GPU hardware generations that the 340.xx legacy driver series is intended to support do not support Unified Memory.
• Added support for X.Org xserver ABI 24 (xorg-server 1.20).
• Improved nvidia-bug-report.sh to check for kern.log which is the default kernel log-file location for many Debian-based Linux distributions.
• Fixed a bug which could cause X servers that export a Video Driver ABI earlier than 0.8 to crash when running X11 applications which call XRenderAddTraps().

*****

Porteus v4.0 x86_64 + kernel 4.15.0-rc7 on old NVIDIA GeForce GTS 250 = all good


https://my-files.ru/4z2gnp (this is full toolkit archive and the driver 08-nvidia-340.107-k.4.15.0-rc7-porteus-v4.0-x86_64 itself)

Code: Select all

# glxinfo | grep -i NVIDIA
server glx vendor string: NVIDIA Corporation
client glx vendor string: NVIDIA Corporation
OpenGL vendor string: NVIDIA Corporation
OpenGL core profile version string: 3.3.0 NVIDIA 340.107
OpenGL core profile shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL version string: 3.3.0 NVIDIA 340.107
OpenGL shading language version string: 3.30 NVIDIA via Cg compiler
OpenGL ES profile version string: OpenGL ES 2.0 NVIDIA 340.107 340.107

[Rava]

I think that not bad if brokenman replace kernel and all stuff (vmlinuz, 000-kernel.xzm, 06-crippled_sources.xzm) for him to current 5.1.xx kernel by neko in all ISO files and sync updated ISO files in the all Porteus mirrors.

I think that would be even better. +2

But will also put workload on brokenman.

And we might call it 5.0rc2 then cause - you know - users might otherwise get confused when Porteus 5.0rc1 differs to Porteus 5.0rc1. Just my 2 cents.