Jump to content











Photo
- - - - -

Boot LibreElec with grub4dos from HDD


  • Please log in to reply
99 replies to this topic

#76 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 October 2019 - 08:13 PM

No problem my friend, thanks very much for your time and suggestions/advices.

 

Best Regards

 

alacran



#77 dickfitzwell

dickfitzwell

    Member

  • Members
  • 33 posts

Posted 17 October 2019 - 12:35 AM

Hmmm - unknown filesystem tends to imply that it found the file but did not like what was inside it.

Either that or maybe it does not understand FILE= syntax?

 

this.  looking at the code from "init" for libreelec, "mount_part" only accepts a few types.

mount_part() {
  # Mount a local or network filesystem
  # $1:[TYPE=]target, $2:mountpoint, $3:mount options, [$4:fs type]
  progress "mount filesystem $1 ..."

  MOUNT_TARGET="${1#*=}"
  case $1 in
    /dev/ubi*)
      MOUNT_CMD="mount_ubifs"
      MOUNT_TARGET="$1"
      RUN_FSCK="no"
      ;;
    LABEL=*|UUID=*|/*)
      MOUNT_CMD="mount_common"
      MOUNT_TARGET="$1"
      ;;
    ISCSI=*)
      MOUNT_CMD="mount_iscsi"
      ;;
    NBD=*)
      MOUNT_CMD="mount_nbd"
      ;;
    NFS=*)
      MOUNT_CMD="mount_nfs"
      ;;
    *)
      error "mount_part" "Unknown filesystem $1"
      ;;
esac

I believe the option for a storage file has been removed despite "mount_common" indicating "block devices and filesystem images."

# Mount handlers
# All handlers take the following parameters:
# $1:target, $2:mountpoint, $3:mount options, [$4:fs type]
mount_common() {
  # Common mount handler, handles block devices and filesystem images
  MOUNT_OPTIONS="-o $3"
  [ -n "$4" ] && MOUNT_OPTIONS="-t $4 $MOUNT_OPTIONS"

  for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do
    ERR_ENV=1

    mount $MOUNT_OPTIONS $1 $2 >&$SILENT_OUT 2>&1
    [ "$?" -eq "0" ] && ERR_ENV=0 && break

    usleep 1000000
  done
  [ "$ERR_ENV" -eq "0" ] && return 0
  error "mount_common" "Could not mount $1"
}

at one point I tried diligently to achieve having the flash and storage partition one in the same.  by default the partition containing KERNEL/SYSTEM is mounted "ro" and modifying the code and rebuilding the images is beyond my capabilities.


  • alacran likes this

#78 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 06:21 AM

@ dickfitzwell

 

I also read your Thread here: https://forum.libree...tem-boot-files/

 

Thanks very much for your Post, it has very valuable info to understand a few better the code related to "mount_part", also your last comment makes me think this is in no way an easy task.

 

So the decision taken here on this thread to stop trying to have only one partition was not a bad decision.

 

The 2 partition scheme is working very fine from HDD, now I'm booting from 2 partitions (a Fat-16 and an ext4) again, both now 512 MB each.

 

Again thanks to all people who contributed to this thread with ideas, suggestions and advice by appearance order:

 

steve6375, Wonko, erwan.l,  and dickfitzwell

 

alacran



#79 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 October 2019 - 09:03 AM

@alacran

The point that still needs to be clarified is not actually needing two partitions, meaning that you actually need to have two partitions :w00t:, but that the first one can be another (already existing)  partition, or - if you prefer - that  the KERNEL and SYSTEM can be on *any* partition.

 

@dickfitzwell

The "queer" thing is that I tried checking the github repository for the init file:

https://github.com/O...ox/scripts/init

but couldn't find the patch/diff/mod that removed the FILE access.

We have a data and date point with Steve6375ìs post , october 2013, so logically previous versions should have that provision. :dubbio:

 

 

:duff:

Wonko



#80 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 09:42 AM

@alacran

The point that still needs to be clarified is not actually needing two partitions, meaning that you actually need to have two partitions :w00t:, but that the first one can be another (already existing)  partition, or - if you prefer - that  the KERNEL and SYSTEM can be on *any* partition.

 

:duff:

Wonko

 

Well, it may be possible do it as you say but IMHO it is more professional, clean and better looking if you put all content of System on its own partition (512 MB), also easy to clon (both partitions) to other machine or USB device if you want, using MiniTool Partition Wizard FREE 11.5 to an unasigned space on your disk.

 

But it is only a matter of preferences. I don't have any problem with that.

 

With your approach you could have all you need (extracted from System partition) on a single folder and maybe boot from it, and only have a partition for Storage, but it seems to me the Micro-OS with Kodi running on top may try to find something on what supposed to be sda1/(hd0,0), but that's easy to test.

 

If you want, just give a menu to start testing it, and I can test it in a couple of minuts, as my Storage partition allready exists.

 

EDIT: but I thik it was allready tested by dickfitzwell here: https://forum.libree...tem-boot-files/

 

alacran



#81 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 10:21 AM

@ wonko

 

 I opened the link to https://github.com/O...ox/scripts/init

 

It is another project, some time ago a group of developers there decided to create a (forked from previous) new project LibreELEC, and of course many things may have changed, from the original project and also from old versions of LibreELEC.

 

alacran



#82 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 October 2019 - 12:03 PM

The issue is that IMHO you should actually read what is posted, and if something is not clear, ask for clarifications.

 

I posted a link to that thread by diskfitzwell on post #13:

http://reboot.pro/to...m-hdd/?p=212943

 

And on post #60:

http://reboot.pro/to...m-hdd/?p=213071

 I posted a reference to a post on Steve6375 of October 2013 about OpenElec (Long before LIBREELEC was forked from it) accepting the disk=FILE=xxx parameter.

 

Logically, since the later fork (Libreelec) doesn't work with  disk=FILE=xxx but seemingly also some later versions of Openelec don't accept it, so that Steve6375 changed approach and used the fake partition method, the change must have happened in Openelec BEFORE the fork into Libreelec, around end 2013 beginning 2014, so I looked if I could find a "patch/diff" that removed the disk=FILE=xxx parameter and was not able to find it.

 

Back to topic/original post by dickfitzwell.

Given that the second (EXT4) partition for STORAGE is needed, it seems like what can be "removed" is the first (FAT16) partition, in the sense that if you have *another* partition (probbaly it wil be needed to be anyway FAT16 or FAT32, as NTFS is likely to not work), you can use that one to hold the KERNEL and SYSTEM files.

 

Experiment:

1) have a partition (FAT16 or FAT32) created with *any* partitioning/formatting tool with a label of "ALACRAN"

2) have a second partition (EXT4) cloned from the original LIBRELEC image, with label "STORAGE"
3) copy from the original (FAT16) first partition of the origiinal LIBTELEC image the files KERNEL and SYSTEM to the "ALACRAN" partition

4) try booting with:

find --set-root /kernel

kernel /KERNEL boot=LABEL=ALACRAN disk=LABEL=STORAGE tty portable quiet

boot

5) if it works (and it should) try renaming KERNEL to (say) LIBREKRN and SYSTEM to (still say) LIBREIMG.img

6) try booting with:

find --set-root /kernel

kernel /KERNEL BOOT_IMAGE=LIBREKRN SYSTEM_IMAGE=LIBREIMG.img boot=LABEL=ALACRAN disk=LABEL=STORAGE tty portable quiet

boot

 

The point is that if the results from dickfitzwell are confirmed you can (say) make the "ALACRAN" partition bootable and of *any* size, have on it grub4dos, another Linux, a DOS, etc. as opposed to having a "dedicated" 512 MB partition used to only hold the two kernel and system files (+ the original LIBREELEC syslinux/whatever booting files), i.e. in practice "re-use" an already existing partition/volume.

 

Another avenue of experimenting would be that of try using for the partition(s)  non-primary one(s), making an extended partition and adding in it the volume(s). Though this cannot be done on-the-fly by the grub4dos partnew command, it should be not too difficult :unsure: to make a grub4dos batch capable of adding the volume(s) to an extended chain (though it again would need some experimenting as there might be "overlapping values" seen by other OS's if the volumes are kept as "images" and only mapped through the - nofigied for logical volumes - fake partition method unless, like it works for primary partitions, a partition ID's of 0x00 work).

Since finding the partitions/volumes is connected to their label (or UUID) there should be no differences

 

:duff:

Wonko



#83 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 02:54 PM

I tested the followig:

 

title Start LibreELEC from HDD Option-3
find --set-root /kernel
kernel /KERNEL boot=LABEL=ALACRAN disk=LABEL=STORAGE tty portable quiet
boot

title Start LibreELEC from HDD Option-4
find --set-root /LIBREKRN
kernel /KERNEL BOOT_IMAGE=LIBREKRN SYSTEM_IMAGE=LIBREIMG.img boot=LABEL=ALACRAN disk=LABEL=STORAGE tty portable quiet
boot

title Start LibreELEC from HDD Option-5
find --set-root /LIBREKRN
kernel /LIBREKRN BOOT_IMAGE=LIBREKRN SYSTEM_IMAGE=LIBREIMG.img boot=LABEL=ALACRAN disk=LABEL=STORAGE tty portable quiet
boot

title Start LibreELEC from HDD Option-6
find --set-root /LIBREKRN
kernel /LIBREKRN BOOT_IMAGE=LIBREKRN SYSTEM_IMAGE=LIBREIMG boot=LABEL=ALACRAN disk=LABEL=STORAGE tty portable quiet
boot
 

Only Option 4 does not work: File not found  (your proposed line on previous post was wrong) I intentionally edited only find --set-root /kernel (wich do not exist anymore as it was renamed) and not kernel /KERNEL, then made option 5 correcting both wrong lines, and on option 6 only removed the extension from LIBREIMG.img to see it can work that way too.

 

Experiment:

1) have a partition (FAT16 or FAT32) created with *any* partitioning/formatting tool with a label of "ALACRAN"

2) have a second partition (EXT4) cloned from the original LIBRELEC image, with label "STORAGE"
3) copy from the original (FAT16) first partition of the origiinal LIBTELEC image the files KERNEL and SYSTEM to the "ALACRAN" partition

4) try booting with:

find --set-root /kernel

kernel /KERNEL boot=LABEL=ALACRAN disk=LABEL=STORAGE tty portable quiet

boot

5) if it works (and it should) try renaming KERNEL to (say) LIBREKRN and SYSTEM to (still say) LIBREIMG.img

6) try booting with:

find --set-root /kernel

kernel /KERNEL BOOT_IMAGE=LIBREKRN SYSTEM_IMAGE=LIBREIMG.img boot=LABEL=ALACRAN disk=LABEL=STORAGE tty portable quiet

boot

 

The point is that if the results from dickfitzwell are confirmed you can (say) make the "ALACRAN" partition bootable and of *any* size, have on it grub4dos, another Linux, a DOS, etc. as opposed to having a "dedicated" 512 MB partition used to only hold the two kernel and system files (+ the original LIBREELEC syslinux/whatever booting files), i.e. in practice "re-use" an already existing partition/volume.

 

Another avenue of experimenting would be that of try using for the partition(s)  non-primary one(s), making an extended partition and adding in it the volume(s). Though this cannot be done on-the-fly by the grub4dos partnew command, it should be not too difficult :unsure: to make a grub4dos batch capable of adding the volume(s) to an extended chain (though it again would need some experimenting as there might be "overlapping values" seen by other OS's if the volumes are kept as "images" and only mapped through the - nofigied for logical volumes - fake partition method unless, like it works for primary partitions, a partition ID's of 0x00 work).

Since finding the partitions/volumes is connected to their label (or UUID) there should be no differences

 

:duff:

Wonko

 

It took me some so long because my USB Wifi connection started failling, rebooted the router, and it fixed for some time but then faill again, untill I changed the USB adapter and it seems problem is solved now.

 

EDIT: Forgot to say ALACRAN partition was formated as Fat-32 for a change. Also I was trying to copy KERNEL and SYSTEM files to ext4 partition to verify if it can boot this way, but without success doing it, I will try doing it with a Linux Live  and comment back.

 

alacran



#84 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 October 2019 - 04:35 PM

Yep, good :).

 

My bad about the wrong find --set-root value , I copy/pasted the previous lines and forgot to change that.

 

So you can have both FAT16 and FAT32 as hosting filesystem, I cannot see (at face value) why EXT4 shouldn't work unless (for some reasons) there is a check that boot=LABEL= and disk=LABEL= must have different values.

 

If this (having KERNEL and SYSTEM inside the "STORAGE" volume) works, we are back to one partition/volume.

 

:duff:

Wonko



#85 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 05:47 PM

Let me tell you what I have done so far:

 

Can't copy KERNEL and SYSTEM to Storage ext4 partition/volume on Windows, tools used:

 

Ext2 Volume Manager (it sees it as ext3), asings a letter to it but it does not look formated to Win, and PartitionGuru copy do not work (with or without mounted with Ext2 Volume Manager.

 

From Linux Mint Live also can't do it, it seems I dont have enought permisions to do it, because it said something about it was not created by me.

 

Then tryed another approach, deleted the partition and created a new one with MiniTool Partition Wizard ext4 logic mounted it with Ext2 Volume Manager (it sees it as ext3) and got a letter and it is now accesible from windows, copied the two files directly with Windows and by mens of PartitionGuru copied to it all files/folders from Storage partition on the USB stik, so far all fine. Closed PartitionGuru, dismounted the partition and before reboot edited the menu and changed the names on ALACRAN partition, so no other KERNELL file existed on any other partition of the PC, then rebooted, g4d did his task and even before loading the Icon of the program appeared a message saying: FileSysted corruption detected.... touch any key to shut OFF

 

Second try did exactly the same (but created an ext3), got same result when booting. It seems it has to be just the original ext4 (no matter the size since it is adjusted to ocuppy all the available space on the USB/SD device or the changes made when downloading and installing addons as this is made by the program Kodi.

 

Only thing I as able to do with Gparted when plugged the USB to a machine running Linux Mint a few days ago was reduce size of Storage partition to 512 MB, but it has to be unmounted first. Also it can be deleted.

 

alacran



#86 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 October 2019 - 06:04 PM

I thought it was an Ext4 (which is not Ext2 nor Ext3) filesystem.

 

Anyway, from Mint you shoudl be able to:

https://itsfoss.com/...n-ubuntu-linux/

or:

https://www.linuxque...ive-4175623973/

 

:duff:

Wonko



#87 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 06:30 PM

 

Can't copy KERNEL and SYSTEM to Storage ext4 partition/volume on Windows, tools used:....

 

Then tryed another approach, deleted the partition and created a new one with MiniTool Partition Wizard ext4 logic mounted it with Ext2 Volume Manager (it sees it as ext3)

 

 

Yes, you are right it is ext4, but Ext2 Volume Manager sees it as ext3, so the last try was only a futile intent to avoid miss-understanding of filesystem when mounted, and see if it was able to boot that way (ext3)

 

I will take a look to those links and let you know.

 

alacran



#88 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 08:39 PM

After reading and making notes of those links, an idea came to my mind, and I did the following:

 

On another machine running Linux Mint plugged the USB and partitions were auto mounted, then located on System (ext4) partition right button Open as Admin, the password was requested, typed it and a new window with a red line on top border (with temporary root capavilities) opened leting me to copy KERNEL and SYSTEM to it, from Sytem partition.

 

This way didn't have to change permisions. I don't know why I didn't think in this before, (it was so simple that makes me feel bad) maybe I was with other things on my mind, and that blocked me to have this idea before.

 

Came back to the tests PC and errased previous partitions related to this subject and cloned the ext4 Storage partition (containing now the mentioned files) on the unasigned space. So far all was fine.

 

Tried first:

 

title Start LibreELEC from HDD Option-1
find --set-root /KERNEL
kernel /KERNEL BOOT_IMAGE=KERNEL SYSTEM_IMAGE=SYSTEM disk=LABEL=Storage tty portable quiet

 

No boot=LABEL= on it since there isn't any

it faill: Error in mount_flash: mount_part: Unknown filesystem

Latter tried

title Start LibreELEC from HDD Option-2
find --set-root /KERNEL
kernel /KERNEL BOOT_IMAGE=KERNEL SYSTEM_IMAGE=SYSTEM boot=LABEL=Storage disk=LABEL=Storage tty portable quiet

 

boot=LABEL=Storage disk=LABEL=Storage tested without big hopes as a partition may not be able to be accessed twice. But maybe once the big file SYSTEM was loaded to Ram it was dismissed, and then could be accessed again.

it faill: Error in mount_storage: mount_common: Could not mount LABEL=Storage

 

mount_flash = I understand is System partition (Fat-16 or Fat-32)

 

mount_storage =  I understand is Storage partition (ext4)

 

So I may conclude: it is hard coded to boot using 2 different partitions, and that is something we can't change.

 

Only small hope we have is try a Fat image file (with KERNEL and SYSTEM inside or only SYSTEM) located into Storage partition to make it happy, but I really don't like the idea very much as that is a waste of space.

 

I will try it, and let you know.

 

alacran



#89 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 10:23 PM

After creating a Fat-32 image file named SYSTEM1 and copied into it SYSTEM it was copied inside Storage partition deleting previous SYSTEM file first, then Storage partition was cloned to HDD

tryed following:

title Start LibreELEC from HDD
find --set-root /KERNEL
kernel /KERNEL BOOT_IMAGE=KERNEL SYSTEM_IMAGE=SYSTEM boot=LABEL=SYSTEM1 disk=LABEL=Storage tty portable quiet

it faill: Error in mount_flash: mount_common: Could not mount LABEL=SYSTEM1

Then as dickfitzwell said:

Quote

at one point I tried diligently to achieve having the flash and storage partition one in the same. by default the partition containing KERNEL/SYSTEM is mounted "ro" and modifying the code and rebuilding the images is beyond my capabilities.


alacran

#90 dickfitzwell

dickfitzwell

    Member

  • Members
  • 33 posts

Posted 18 October 2019 - 12:07 AM

this is what I learned in my efforts.

the incomplete boot arguments are located here, but others can be derived from the init script.

partition containing KERNEL/SYSTEM files can be any existing fatXX/extX partition at least big enough to hold both files and/or any other files you care to. it is mounted as /flash and read-only on boot.

if persistent configuration and storage is needed, a second partition requires to be extX because for some reason access permissions are needed. it is mounted as /storage, read-write, and can be relatively small if you do not save any media to it.

I believe a possible reason this partition scheme is required is because of the "soft" and "hard" reset options in libreelec. the "soft" reset option deletes everything under directory /storage/.kodi. the "hard" reset formats/deletes everything under partition mounted /storage. in that case KERNEL/SYSTEM needed to be separated to ensure existence on reboot.

this approach is clean on a device where the only purpose is libreelec, but on multi-boot/multi-os rigs not so much.

my guess is that if one modified the init code with "rw" options rather "ro" a single partition scheme could be achieved. but I never bothered with finding out how to rebuild KERNEL with the updated init. SYSTEM is just a filesystem image.

mount_flash() {
  progress "Mounting flash"

  wakeonlan

  mount_part "$boot" "/flash" "ro,noatime"

  if [ -f /flash/post-flash.sh ]; then
    . /flash/post-flash.sh
  fi
}

I have a travel netbook that has ssd mbr partition scheme and can easily be adapted to removable storage by skipping the windows partition.

primary1: ext2, 4gb, label=home-rw -- grldr/menu.lst, KERNEL/SYSTEM, xubuntu live iso with persistent partition storage (could also be fatXX)
primary2: ext2, 4gb,

Edited by dickfitzwell, 18 October 2019 - 01:02 AM.


#91 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 October 2019 - 08:54 AM

Hmmm, I don't know, the whole stuff is waaay over my head, but the init should be not in KERNEL, but rather in the filesystem image SYSTEM :dubbio:

 

Anyway, since the libreelec uses busybox and systemd, the actual init is AFAICU *transformed* in *something else* (no idea how/what/where). 

 

:duff:

Wonko



#92 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 19 October 2019 - 12:40 AM

Well, I know this is not strictly using a single partition to boot LibreELEC, but anyway it is the closest I was able to do, now I only had to create one partition on the HDD, (not two), to boot it from the HDD using grub4dos:

 

This PC HDD is MBR formated, and has only 4 GB of RAM, I have a dual boot 7x86 (because I have some games that do not run on x64) and also 10x64 (almost never used) and several VHDs and WimPE .wim(s), + now a logical ext4 (512 MB) partition to locate LibreELEC Storage .

 

As in any MBR install the Windows boot partition was NTFS, last time I reinstalled the OS on this PC (about a year ago), I made this first partition of 1 GB, thinking maybe sometime I would like to put here an small WinPE or Iso to boot from it using grub4dos, but latter put several of then on an Isos folder on Documents partition, and never used the extra space.

 

Then the space to put Kernell and SYSTEM files of LibreELEC (242 MB for both) was available, but it was a NTFS partition (and they can't run from NTFS), so I needed a Fat 16 or 32, I decided to change partition format to Fat-32 (without formating it), put the two files there, edited the grub4dos menu.lst and that's all, at the end only one small ext4 partition was added to my HDD.

 

And Windows bootmanager boots as fine from the Fat-32 active partition as it was booting before from the NTFS, nothing new, since long time ago this is commonly used to get MBR + UEFI booting from same USB device.

 

People not having enought space on first partition could reduce some MB from the begining of second partition and use this space to enlarge the first partition, using a good Partition Management Software, there are many Free options available, but be aware this is a risky process and you may damage your installed Windows OS, so it is under your own responsibility as you have been warned.

 

alacran



#93 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 19 October 2019 - 12:13 PM

Hi Alacran,

 

Formating your windows OS partition from ntfs to fat32 is a bit radical / risky.

Furthermore you then lose some potential features like streams, compression, encryption, etc.

Not to mention that there is an extra risk that one OS (Linux or Windows) at some point introduces a change to your FS thus breaking the other OS.

 

Now, still surfing on your idea which is to use your windows partition, what about the below:

-place system.img on your windows ntfs partition

-patch/fix the geometry of this fat32 image either with a hexeditor or with G4D (see previous post from Wonko)

-map it via G4D

 

Regards,

Erwan



#94 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 19 October 2019 - 04:08 PM

@ erwan.l

 

No, I never touched the Windows OS partition, I think you missunderstood the info, please read again previous Post (it is unchanged) and if what I said is not understandable, please let me know to make it more clear, thanks in advance.

 

The way I did is:

 

Rebooted with Win10XPE_x64.wim, ran MiniTool Partition Wizard and selected the very first (hd0,0) partition the boot partition, not the windows partition, and selecting NTFS to FAT was all required, applied changes and rebooted, the OS requiered to check the new Fat-32 partition I let it do it and PC booted fine, then I cheched with BootIce the partition ID and it was Fat-32 0B (C/H/S), changed the ID to 0C (LBA) and all ready, This could be done from MiniTool Partition Wizard, but I noticed it was 0B untill after reboot.

 

So I never touched Windows partition, all was done to the boot partition (hd0,0) wich Windows incorrectly calls SYSTEM.

 

I'm not specting future problems with this, since as dickfitzwell said the partition where KERNELL and SYSTEM are located, is mounted RO, so no chance to get damaged or altered when booting LibreELEC.

 

alacran



#95 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 19 October 2019 - 04:16 PM

I get it, my bad.

Clear to me now : the "boot loader" windows partition, not the actual windows partition.



#96 maro

maro

    Newbie

  • Members
  • 13 posts
  •  
    New Zealand

Posted 20 October 2019 - 05:22 AM

First up my apologies, for being a bit late to this party. But I wanted to share, what I believe to have learned from actually reading the '/init' script. I'm not going to attempt to explain all aspects of it, but merely those I found somewhat "interesting".
 
@ Wonko:
The '/init' script is a part of an embedded initramfs that is contained in the 'KERNEL' file.

You could either extract it by use of the 'binwalk' utility (like explained here), or by booting a system purely using the 'KERNEL' file, and either study the code "in situ", or copy the relevant files.
Spoiler


@ dickfitzwell:
One does not need to rebuild the 'KERNEL' to be able to write to '/flash'. You had in the code snippet in #90 the "hook" that could be used for it.

If a file '/flash/post-flash.sh' exists that simply contains:
mount -o remount,rw /flash
the file system mounted on '/flash' would become writable.

With this I believe it is feasible to use only a single fatXX/extX partition, and still achieve persistence. For this one would have to utilize another "hook" included in the 'mount_storage()' function of '/init' (possibly in an unintended fashion).
 
For my suggestion one needs:
  • a (extX) partition image file (I believe, AKA "super floppy"), e.g. '/flash/storage.img'
    Spoiler
  • a '/flash/mount-storage.sh' file,
    Spoiler
  • and the appropriate boot codes
    Spoiler
In summary: I've got a (single FAT32) USB stick containing (in its root directory): 'KERNEL', 'SYSTEM', 'storage.img', 'post-flash.sh', and 'mount-storage.sh' (plus the respective files for the boot loader) and have achieved the intended persistence. I'd imagine scenarios involving disks are equally possible.

#97 dickfitzwell

dickfitzwell

    Member

  • Members
  • 33 posts

Posted 20 October 2019 - 12:22 PM

@ dickfitzwell:
One does not need to rebuild the 'KERNEL' to be able to write to '/flash'. You had in the code snippet in #90 the "hook" that could be used for it.

If a file '/flash/post-flash.sh' exists that simply contains:
mount -o remount,rw /flash
the file system mounted on '/flash' would become writable.

 

w o w.  you are absolutely correct.

I created a primary partition, formatted as ext2 and labeled as "media."  I copied KERNEL*/SYSTEM* and your post-flash.sh to the root.  I changed permissions for post-flash.sh as executable though I do not know if this is a requirement.  my boot arguments:

kernel /KERNEL boot=LABEL=media disk=LABEL=media quiet

thanks to your incite, with one line of code librelec with boot and persistent configuration storage in a singular extX partition is possible.

/media/xubuntu/media$ ll -hn
total 244M
drwxr-xr-x  2   0 4.0K Oct 20 04:41 backup/
drwxr-xr-x 11   0 4.0K Oct 20 04:41 .cache/
drwxr-xr-x 16   0 4.0K Oct 20 04:48 .config/
drwx------  2   0 4.0K Oct 20 04:41 .fluxbox/
-rw-r--r--  1 999  16M May  4 11:15 KERNEL
-rw-r--r--  1 999   48 May  4 11:15 KERNEL.md5
drwxr-xr-x  7   0 4.0K Oct 20 04:41 .kodi/
drwx------  2   0  16K Oct 20 04:41 lost+found/
drwxr-xr-x  2   0 4.0K Oct 20 04:41 music/
drwxr-xr-x  2   0 4.0K Oct 20 04:41 pictures/
-rwxr-xr-x  1 999   38 Oct 20 00:00 post-flash.sh*
drwxr-xr-x  2   0 4.0K Oct 20 04:41 screenshots/
drwx------  2   0 4.0K Oct 20 04:41 .ssh/
-rw-r--r--  1 999 228M May  4 11:15 SYSTEM
-rw-r--r--  1 999   48 May  4 11:15 SYSTEM.md5
drwxr-xr-x  2   0 4.0K Oct 20 04:41 tvshows/
drwxr-xr-x  2   0 4.0K Oct 20 04:41 .update/
drwxr-xr-x  2   0 4.0K Oct 20 04:41 videos/

Edited by dickfitzwell, 20 October 2019 - 12:24 PM.


#98 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 20 October 2019 - 02:31 PM

@maro

Very good :) , thanks :worship: .

But I will need to ask you a few questions :w00t: to make sure I understand the process :blush: .

The  '/flash/post-flash.sh' :

mount -o remount,rw /flash

remounts the *whatever* was mounted to /flash (which in our case is the volume containing both KERNEL and SYSTEM, ie. the target of the boot=LABEL= or boot=UUID= parameters) as read/write (till now it was mounted as readonly by the init inside the cpio compressed initramfs embedded in KERNEL).

Then the  '/flash/mount-storage.sh' :

mount /flash/storage.img /storage

mounts (rw as no ro is specified) the storage image "storage.img" to the /storage mountpoint. 

 

Question #1:

Cannot both the commands be included in a "same" '/flash/post-flash.sh' file?

I.e. were two .sh files made for clarity (and thus they can be unified) or is it needed to keep them separated/distinct?

 

Question #2:

I don't know how exactly the mounting system in Linux works, but is it needed to have the filesystem containing the image be r/w in order to have the contents of the image writable?

Or, maybe, is there not a more direct way to mount the system.img? (like mapping the extents?)

 

Question #3:

Is there any reason why the system.img should reside on the same partition/volume as KERNEL and SYSTEM?

I mean, in a multi-partition layout, not necessarily this "less partitions is better" one, one could have:
1) a partition with KERNEL and SYSTEM (and mount-storage.sh) and have it mounted in ro mode

2) *another* partition, mounted rw containing the system.img file

And this leads to question #4:

Which filesystems does (at this stage of booting) LIBREELEC understands (besides FAT16/32 and EXT2/3/4)?

 

 

 

@dickfitzwell

Good :) , I thought (evidently wrongly) that ext4 was needed, good to know that a simpler ext2 (simper because there are more compatible tools in Windows for it) works fine as well).

 

What loads the 

 

@all

Usual rant :ranting2: , given that by design in *nix "everything is a file", it still seems *queer* to me how the good Linux guys (not only those making LIBREELEC) do not use fully the features they have available "by default" or "as a basic built in option" :frusty: . 

 

:duff:

Wonko



#99 maro

maro

    Newbie

  • Members
  • 13 posts
  •  
    New Zealand

Posted 21 October 2019 - 08:03 AM

@ Wonko:

I'll try to answer your questions as best as I can (and have assumed you meant 'storage.img', where you wrote 'system.img'):

Q1:
The two scripts are used as there are two different hooks available during different phases of the processing of '/init'.
If you'd look into '/init' (following the comment of '# main boot sequence') there is a loop where the different functions are called one after the other. Looking at the more recent commits in Github, one can see that changes are afoot, which might have a bearing of which file systems are mounted at the different processing stages.
So, whilst it might be technically possible to defer the re-mounting of '/flash' (by eliminating 'post-flash.sh', and moving the re-mount command to become the first step of 'mount-storage.sh' instead) I believe it makes more sense, to keep things to where they more "logically" belong.

Q2:
I'm afraid there is no way around the requirement that an image file (e.g. '/flash/storage.img') will need to be on a writable file system. I've done a round of testing, and either the 'mount' failed, or the mounted 'storage.img' became a read-only file system (which does not work well, if the aim is to achieve persistence).
Your other question (re. directly mapping of extents) is beyond my current knowledge. I'm not aware of a Linux tool to achieve such. But if you have a command etc. in mind, I'm happy to do some digging (time permitting).

Q3:
There is certainly no reason, why a 'storage.img' file will have to be on the same partition/volume as the 'KERNEL' and 'SYSTEM' files.
But it is rather convenient, to have the file system already mounted. Otherwise, one would have to perform the search for the other file system, on which 'storage.img' is located, plus its subsequent r/w mounting, as part of '/flash/mount-storage.sh'.
So, I'd say its quite feasible, just a bit more coding.

Q4:
Yesterday I've asked that very question myself. So I did a:
grep -v '^nodev' /proc/filesystems
and the answer is:
	ext3
	ext2
	ext4
	squashfs
	vfat
	f2fs
	btrfs
So, no it does not support NTFS at this stage.

Having said this, I started to play around, and done a little script (that could be stored as: '/flash/ntfs-addon.sh').
Spoiler

It would need to be run in a "full blown" LibreELEC system, and assumes that '/flash' is writable.
It tries to extract the 'ntfs-3g' utility, and its dependencies (two shared libraries, and a kernel module), and packs it all into an archive (i.e. '/flash/ntfs.tgz').

With '/flash/ntfs.tgz' now in place, one could add the following lines at the start of '/flash/mount-storage.sh':
tar xf /flash/ntfs.tgz -C /
insmod /lib/modules/fuse.ko
Afterwards one could use 'ntfs-3g' to mount a NTFS partition, that might hold a 'storage.img' file.

NOTE 1: This extraction would have to be done for each new release of LibreELEC again, as the kernel module is specific to the kernel used (and the libraries, and the version of 'ntfs-3g' might have changed as well).

NOTE 2: I've done most of my testing via a (temporary) shell (which is akin to your frequently suggested use of the command line mode of G4D). In this case my '/flash/mount-storage.sh' consists only of:
/bin/sh
After I've done my steps I hit 'Ctrl-D' (or enter: 'exit'), and let the remainder of the boot process continue.

NOTE 3: I have not done any coding for the "... search for the other file system, on which 'storage.img' is located ...". I simply avoid on my systems (like hell) the likes of ESP, and MSR. Using BIOS booting with just a single primary partition (plus sometimes a second 'DATA' volume) is enough for my Windows systems. Therefore I simply have not got a setup, in which I could directly test, what I envisage to be possible with the help of 'ntfs-3g'.
Mind you, I've at least played around with a NTFS ("super floppy") image, and confirmed that the mounting with 'ntfs-3g' at the 'mount_storage()' stage would be possible.

#100 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 21 October 2019 - 09:57 AM

Thanks Maro :)
And yes, my bad I wrote system.img when I meant storage.img.
 
About the more direct mounting, I was thinking about something like it can be done in grub4dos, example:
blocklist (hd0,0)/storage.img
(hd0,0)1056705+1122303
map (hd0)1056768+1122303 (fd1) -> Autodetect ...
map --hook
root (fd1) -> Filesystem type is ext2fs, using all disk
ls -> lost+found -please_resize_me
 
or in IMDISK (other example):
imdisk -a -f \\?\physicaldrive1 -b 1056768 -s 1122303 -m #:
 
I believe that something like that is possible via losetup (as always take anything I write about Linux with more than a grain of salt):
https://www.suse.com...ck-image-files/
 
I.e. - loosely - something like:
losetup -v -f -o 541065216 –sizelimit 574619136 /path/to/some_way_to address_the_PhysicalDrive
Loop device is /dev/loop0
 
mount -v -t ext3 /dev/loop0 /storage
/dev/loop0 on /storage type ext3 (rw)
 
IF this is possible, as long as the image is contiguous, it can be mapped even if it resides on a NTFS.
Since the NTFS volume is not mounted, there should be no conflicts.
 
:duff:
Wonko




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users