Jump to content











Photo
- - - - -

Boot LibreElec with grub4dos from HDD


  • Please log in to reply
99 replies to this topic

#1 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 11 October 2019 - 04:40 AM

Recently I downloaded LibreELEC for PCs: http://releases.libr...64-9.0.2.img.gz

It is a very minimal Linux system just enough to boot and load Kodi.

It contains inside an *.img file wich has inside 2 *.img files: system.img & storage.img

 

And the tool to install it on a SD or USB device (win version): http://releases.libr...eator.Win32.exe

 

The tool installed LibreELEC directly from the gz compressed image fine to an old 2 GB USB, and once booting from the USB it worked fine, I installed some addons and made all settings to my preferences, all working fine. During install the USB was formated and repartitioned this way:

 

No MBR

First partition is FAT-16 (512 MB)  PVR is Syslinux 6.03 (for system)

Second partition is Ext4 (32 MB) no PVR (for storage)

Additional space on the USB is unalocated

 

After first boot selecting <tab> and then run (and now it remains as default option), then the second partition is expanded to ocupy all unalocated space.  Then system reboots, and the program is loaded leting you install some addons and config your preferences.

 

After some time using it on the USB, I started thinking to try to boot it from the HDD by means of grub4dos and it will boot faster, (I know there is Kodi for Win available, but this micro Linux OS running Kodi on top [only 243 MB of 512 MB used] consumes very little resources), then using Clonedisk from erwan.l I captured it as raw (.img) having inside 2 .img files one for each partition.

 

I used the following on my menu.lst to boot it:

 

title Start LibreELEC image from HDD
find --set-root /LibreELEC.img
map /LibreELEC.img (hd0)
map --hook
chainloader (hd0)+1
rootnoverify (hd0)

 

This is the syslinux.cfg file located on first partition:

SAY Wait for installer to start or press <TAB> for more options (live, run)
DEFAULT run
TIMEOUT 50
PROMPT 1

LABEL installer
  KERNEL /KERNEL
  APPEND boot=UUID=0405-1514 installer quiet tty vga=current

LABEL live
  KERNEL /KERNEL
  APPEND boot=UUID=0405-1514 live quiet tty vga=current

LABEL run
  KERNEL /KERNEL
  APPEND boot=UUID=0405-1514 disk=UUID=03a48580-f0a2-4057-b5e3-30fccf817d53 tty portable quiet

grub4dos part seems solved as the program boots, but there is a problem since it said can't find UUID=0405-1514 flash and asks me to type exit, then another message about can't find the other UUID and asks me to type exit. After typing exit the second time it reboots.

 

So far I understand from a post from Wonko on other thread, when making an image of a disk it keeps the same UUID.

 

So then what could be the problem?

 

When I load the .img file using ImDisk it asks me to format it, and I can't open it.

 

How could I check if the UUID is still the same or it has changed when making the copy with Conedisk?

 

To make the changes on the syslinux.config file if required.

 

Any comments helping to solve this are welcome.

 

EDIT: Solution is on post No. 23: http://reboot.pro/to...dd/#entry212959

 

EDIT-2: Latter I was testing another approach trying to make it run from only one partition containing an ext4 image file of second partition inside it, but this appoach has proven to not work see: http://reboot.pro/to...e-4#entry213091& http://reboot.pro/to...e-4#entry213093

 

EDIT-3: If you have a first primary partition with space available (242 MB free or more required), you may use the layout commented on this post: http://reboot.pro/to...e-4#entry213127 and then create only one ext4 partion on your internal disk.

 

alacran


Edited by alacran, 19 October 2019 - 07:52 PM.


#2 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 11 October 2019 - 08:05 AM

Does this help?

http://rmprepusb.blo...o-e2b-kodi.html



#3 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 11 October 2019 - 04:49 PM

Hi steve 6375

I just read it, it seems very usefull when using E2B, but also very specific for that environment and to me it doesn't seem I can adapt it to my case.

Thanks for your kind sugestion my friend.

But that's not my case, I'm trying fo boot the *.img (a RAW image file made with CloneDisk) from the internal HDD and from grub4dos booting it as Ramdisk is loaded but during boot, it seems to not find the image loaded in Ram anymore, but as filedisk menu goes all the way to start booting it fine.

Then the control is transfered to syslinux.cfg, and when syslinux.cfg execute the RUN command then this stage of boot starts, and I can see the program logo and got a message: can't find UUID=0405-1514 flash and asks me to type exit, then another message about can't find the other UUID 03a48580-f0a2-4057-b5e3-30fccf817d53 and asks me to type exit. After typing exit the second time it reboots.

So it seems to me one of this two things is happening:

1 - syslinux.cfg can't find anymore the RAW image it is running from.

2 - The UUIDs do not match anymore.



#4 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 October 2019 - 06:35 PM

Let's try to solve the issue.

 

Forget for a moment about the UUID=0405-1514 or disk=UUID=03a48580-f0a2-4057-b5e3-30fccf817d53

 

You have an .img.

 

You map it to (hd0) in grub4dos, ok.

 

How do you think the Linux can find the image? :dubbio:

 

I.e. it is not that the Linux kernel cannot find an image with a given UUID, it simply cannot see *any* image as it is only mapped by grub4dos.

 

In the post you referenced it is not about an .img file, it was about an actual, real volume.

 

So you need to provide to the Linux an actual, real, volume.

 

You need to extract the volume as separate image OR map it partially.

 

Then you may try actually mapping the (partial) image(s) in the MBR partition table via partnew:

http://reboot.pro/to...brided/?p=88531

 

Which is exactly what is done in the .mnu  Steve6375  :thumbup:  just posted a link to.

 

OR

 

 (and this may or may not be possible) pass some info (cheatcodes) to the actual Linux kernel to tell it:

1) that you are booting from an image (and not a real volume)

2) how/where to find that image.

 

It is admirable how you try to have complex things work simply :) , but sometimes complex things can only be achieved through complex methods, i.e. everything should be as simple as possible, but not simpler.

 

Back to the original syslinux entry, I'll try to break it down for you:

KERNEL /KERNEL <- invoke the kernel

APPEND <- pass to the kernel the following parameters 

boot=UUID=0405-1514 <- look in the MBR for all volumes, check their UUID and set as boot volume the one that matches the given UUID

disk=UUID=03a48580-f0a2-4057-b5e3-30fccf817d53 <- look in the MBR for all volumes, check their UUID and set as disk storage volume the one that matches

 tty portable quiet <- other parameters setting the booting mode

 

The entry by Steve6375:

kernel /kernel <- invoke the kernel AND pass to the kernel the following parameters 

boot=UUID=%UUID% <- look in the MBR for all volumes, check their UUID and set as boot volume the one that matches the pteviously calculated UUID

disk=LABEL=DATA  <- look in the MBR for all volumes, check their LABELs and set as disk storage volume the one that matches "DATA" as as label

quiet tty vga=ask <- other parameters setting the booting mode

 

:duff:

Wonko 



#5 erwan.l

erwan.l

    Platinum Member

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

Posted 11 October 2019 - 06:41 PM

Hi Alacran,

 

I am a big fan of Librelec and actually use it every evening (on a RPi3).

This is a great and cheap media player and it will run any crappy divx/mkv, etc I will throw at it.

 

About the image, looking at my arm image i can see 2 parts : a fat32 one at offset 8192 and a ext2/ext3 one .

You should be able to mount the fat32 one in imdisk (by eventually prodiving the offset if imdisk does not prompt about it).

 

CjHwGSa.png

 

Once mounted is what you get.

 

 VBUoPml.png

 

SYSTEM is actually a squashfs file which is (i believe) mounted to memory and is actually your libreelec distro.

 

fBoYGAh.png

 

 

May be this help you with your project...

 

Regards,

Erwan



#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 October 2019 - 07:08 PM

Technically, you can mount via IMDISK also the ext2/3 FS one, if you want to access its contents, then you will need to have installed an EXT2/3FS driver in Windows.

 

As a side note, the CHS geometry of the volumes you posted a view of in Clonedisk, is "bonkers", as often happens with Linux images, the device must have a CHS geometry of n/4/32 :w00t:

 

Quick question:

If something starts on 1023/3/32 and ends on 1023/3/32, how large it is?  ;)

 

Probably also the BPB of the volumes is "crazy".

 

:duff:

Wonko



#7 erwan.l

erwan.l

    Platinum Member

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

Posted 11 October 2019 - 07:22 PM

Technically, you can mount via IMDISK also the ext2/3 FS one, if you want to access its contents, then you will need to have installed an EXT2/3FS driver in Windows.

 

As a side note, the CHS geometry of the volumes you posted a view of in Clonedisk, is "bonkers", as often happens with Linux images, the device must have a CHS geometry of n/4/32 :w00t:

 

Quick question:

If something starts on 1023/3/32 and ends on 1023/3/32, how large it is?  ;)

 

Probably also the BPB of the volumes is "crazy".

 

:duff:

Wonko

 

Who uses CHS these days? :) 

By nature, it is limited to small partitions and most modern bios/software will ignore it, not ?

Whenever I have to create an image, I "stuff" 1023/254/63 as starting/ending CHS : will make some guys scream but I always get away with it.

 

About the ext2/3 partition, it contains nothing but one file named "toberesized" : possibly a swap partition.

 

If of interest, below the boot sector of the fat32 partition.

 

M3MYGTf.png



#8 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 October 2019 - 07:33 PM

Who uses CHS these days? :)

By nature, it is limited to small partitions and most modern bios/software will ignore it, not ?

Whenever I have to create an image, I "stuff" 1023/254/63 as starting/ending CHS : will make some guys scream but I always get away with it.

Yep, though I wouldn't actually call a 1048576 sectors volume a "large" partition.

 

And of course "stuffing" 1023/254/63 everywhere will work just fine, until it doesn't.

 

:duff:

Wonko



#9 erwan.l

erwan.l

    Platinum Member

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

Posted 11 October 2019 - 07:44 PM

Coming back on the UUID, which is a wording you will rather find under unix :

Are we ok that in a MBR, it will be 4 bytes in the form of aabb-ccdd and that in a GPT it will be 16 bytes aka a GUID in the form of 3F2504E0-4F89-11D3-9A0C-0305E82C3301 ?

 

If so, there are lots of tools to help one retrieve that information ("disk id" aka UUID under Unix) under windows, including CloneDisk.

 

Note that with GPT, the (windows) volume GUID is not to be confused with the partition GUID (even if changing the later will affect the first one...) which itself shall not be confused with the partition type (which also in a form of a GUID).

And of course, you also have a GPT disk GUID.

This has been discussed in length on another thread over here (which as always I cannot find/remember :( ) and diskpart itself introduces some confusion around all these GUID's...



#10 erwan.l

erwan.l

    Platinum Member

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

Posted 11 October 2019 - 07:50 PM

 

 will work just fine, until it doesn't.

 

 

This is how I run my IT services  :punk:



#11 erwan.l

erwan.l

    Platinum Member

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

Posted 11 October 2019 - 08:05 PM

I checked the generic.x86_64 libreelec image which Alacran referred to.

 

It is a GPT disk with 2 parts (similar to the ARM image I referred to : one fat32 and one ext2/3 partition).

 

0WnjN1S.png

DEFAULT installer
TIMEOUT 50
PROMPT 1

LABEL installer
  KERNEL /KERNEL
  APPEND boot=UUID=0405-1514 installer quiet tty vga=current

LABEL live
  KERNEL /KERNEL
  APPEND boot=UUID=0405-1514 live quiet tty vga=current

LABEL run
  KERNEL /KERNEL
  APPEND boot=UUID=0405-1514 disk=UUID=03a48580-f0a2-4057-b5e3-30fccf817d53 tty portable quiet

About the above syslinux.cfg :

-0405-1514 matches the volume serial.

-03a48580-f0a2-4057-b5e3-30fccf817d53 ? I have no idea what it relates to as I find a different GPT DiskID (edit: ignore this one, lets not confuse volume serial with GPT disk/part ID).

 

@Alacran : you can mount the fat32 part with imdisk with offset bytes=4194304.

(if you are only looking for that offset, 7zip can easily parse a mbr/gpt and give the basic informations you need).

And you can then check the volume serial with :

C:\>vol f:
 Le volume dans le lecteur F s'appelle LIBREELEC
 Le numéro de série du volume est 0405-1514


#12 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 October 2019 - 08:04 AM

Coming back on the UUID, which is a wording you will rather find under unix :

Are we ok that in a MBR, it will be 4 bytes in the form of aabb-ccdd and that in a GPT it will be 16 bytes aka a GUID in the form of 3F2504E0-4F89-11D3-9A0C-0305E82C3301 ?

No we are not. :w00t:

 

The 4 bytes in the MBR are a Disk Signature (and NOT an UUID), and the disk signature is only used by Windows NT systems.

 

In GPT there is an UUID of the disk (outside the MBR).

 

But I don't think that the :

disk=UUID=03a48580-f0a2-4057-b5e3-30fccf817d53

in the given example has anything to do with it, that UUID is most probably that of the (second) volume/partition, i.e. it is the case of a "misnamed" kernel parameter/variable, if that was not the case, Steve6375 couldn't have replaced it with:

disk=LABEL=DATA

 

Should have probably been named "Storagevolume", these would then start making sense:

StorageVolume=UUID=03a48580-f0a2-4057-b5e3-30fccf817d53

StorageVolume=LABEL=DATA

 

The first (original) passes a reference to a volume by UUID, the second passes a reference to a volume by label

 

Also the given RMPREPUSB/Easy2boot page confirms that there is no real need of a GPT style disk, and that a MBR style one works just fine.

 

:duff:

Wonko 



#13 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 October 2019 - 08:46 AM

Now, it is seemingly impossible to find a single §@ç#ing simple page listing the kernel parameters that this thingy accepts, but:

https://forum.libree...tem-boot-files/

 

So it is possible to map the "SYSTEM" (squashfs filesystem) directly, at least when the file is in root..

 

The above example seemingly misses the "storage" (i.e. DISK= ) parameter, so it either needs to be added or it is not strictly-strictly needed :unsure:

 

Some further experiments are needed.

 

:duff:

Wonko 



#14 erwan.l

erwan.l

    Platinum Member

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

Posted 12 October 2019 - 11:39 AM

No we are not. :w00t:

 

The 4 bytes in the MBR are a Disk Signature (and NOT an UUID), and the disk signature is only used by Windows NT systems.

 

In GPT there is an UUID of the disk (outside the MBR).

 

But I don't think that the :

disk=UUID=03a48580-f0a2-4057-b5e3-30fccf817d53

in the given example has anything to do with it, that UUID is most probably that of the (second) volume/partition, i.e. it is the case of a "misnamed" kernel parameter/variable, if that was not the case, Steve6375 couldn't have replaced it with:

disk=LABEL=DATA

 

Should have probably been named "Storagevolume", these would then start making sense:

StorageVolume=UUID=03a48580-f0a2-4057-b5e3-30fccf817d53

StorageVolume=LABEL=DATA

 

The first (original) passes a reference to a volume by UUID, the second passes a reference to a volume by label

 

Also the given RMPREPUSB/Easy2boot page confirms that there is no real need of a GPT style disk, and that a MBR style one works just fine.

 

:duff:

Wonko 

 

Glad I ask :)

So we have a disk signature in the MBR header (4 bytes) and a disk GUID (16 bytes) in the GPT header.

On top of that we also have a partition GUID (still in the GPT header).

All this is fully indepedant of the OS (even if some disk attributes can eventually influence some of the OS attributes but this is deviating).

 

Now in the partition (which will become a volume at the OS level), we have a "volume serial" (at least this is how this called for FAT32).

This is stored in the partition boot sector.

 

I can see the link now between the syslinux UUID and the partition/volume.

 

About this 03a48580-f0a2-4057-b5e3-30fccf817d53, spot on !

I checked and this indeed the UUID of the second partition.

 

PART#1

 

bN9r71s.png

 

PART2#

 

lGGepnQ.png



#15 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 October 2019 - 01:31 PM

Yes and no (again).

 

On MBR  the Serial Number or UUID  is a VOLUME "characteristic".

 

On GPT the UUID  is a VOLUME "characteristic".

 

On GPT since a volume is also a (primary) partition, you could say that you have the UUID of the partition, but it would be technically "wrong".

 

A VOLUME "id" exists the moment it is formatted/a filesystem is assigned to it (and a Serial or UUID is written to it in the bootsector), or if you prefer, do try creating a partition without formatting/creating/deploying a filesystem to it, and check the Serial (or the UUID) of that partition.

 

Even on MBR a volume is often the same thing of a primary partition (but not the same as an extended one), but we are used to tools that all assume, when formatting a primary partition (thus making it into a volume) use all the space in the partition for the filesystem (but not the NTFS that has a backup copy of the bootsector outside the volume but inside the partition).

 

Now (thought experiment) what happens if you create a (say) 500 MB partition BUT instead of formatting it apply (dd or similar) a 250 MB volume to it?

You will have (in the MBR or GPT partition table) an extent of 500 MB mapped to a partition, but when you open/mount access the volume it will be only 250 MB in size.

 

And nothing prevents you from using those "non-existing" or "missing" megabytes.

 

As an example using grub4dos mapping or - wait for it ;) - using IMdisk to map it (the extent, which is NOT a partition) to a drive (which is actually a volume) :frusty: :

http://reboot.pro/to...image/?p=192170

 

:duff:

Wonko



#16 erwan.l

erwan.l

    Platinum Member

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

Posted 12 October 2019 - 02:04 PM

Correct, there is indeed a close relationship between the disk/partition and OS as :

-introducing a disk or partition without an "ID" (purposedly using a generic term here) will have the OS (windows at least) set a new "ID" (which is not always wishable by the way) and therefore update the MBR/GPT

-changing the GPT partition "ID" will have the OS (windows at least) update its volume GUID.

 

Now, and for the purpose to try to answer Alacran's question i.e "How could I check if the UUID is still the same or it has changed when making the copy with Conedisk?", would you say that the "volume UUID" always relates to the "volume serial", an information which is stored in the boot sector and not in the partition table (stored in MBR or GPT) - and should never change unless you reformat your volume.

Does the form of this UUID (4 bytes for FAT32 versus 16 bytes for EXT2/3/4) also changes depending on the filesystem?

 

Below :

-on the left, a MBR disk with a windows volume guid and a volume serial number (set during the OS formating)

-on the right, a GPT disk with a GPT partition ID, a volume GUID and a volume serial number (set during the OS formating)

 

ckP2uz0.png



#17 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 12 October 2019 - 02:50 PM

@ Wonko and @ erwan.l

Thanks for your info.

Well this are my findings so far:

If I use the grub4dos entrance on menu.lst (on fist post) when the USB device is plugged it boots just fine from the disk and partitions located on the USB.

Whith no dubt UUID=0405-1514 is the Fat-16 partition and UUID 03a48580-f0a2-4057-b5e3-30fccf817d53 is the ext4 partition.

 

As using an .img file or create the two small partitions on my HDD take same space. Then I decided to try another approach (just to test) and made 2 more logical partitions (same sizes as on USB) on my (MBR) HDD and cloned directly from the USB both partitions.

The Fat-16 512 MB partition wich I can see from Win7 keept the UUID=0405-1514 (same as the USB and in the syslinux.cfg)

To check the ext4 partition I had to boot Linux Mint from my AIO Boot USB and the UUID changed from 03a48580-f0a2-4057-b5e3-30fccf817d53 (as on syslinux.cfg and on the USB) to UUID=03a48580-f0a2-4057-b5e3-30fccf817d531 (on the HDD partition), also BootIce says the ext4 partition ID is 00 on the USB and 070 on the HDD,

The change in UUID and ID may be caused during cloning since it was done from Win and usually cloning programs ran on Win do not handle very fine Linux partitions or maybe because it is now a logical partition.

So far I can't change the ext4 partition Label even with Gparted ran from Linux Mint, it may be good if I would do it (as Wonko sugested) and then if its UUID change I will not care.

But then tryed a new entrace on my menu.lst as following:

title Start LibreELEC from HDD (Test-2)
find --set-root /syslinux.cfg
kernel /kernel boot=UUID=0405-1514 disk=UUID=03a48580-f0a2-4057-b5e3-30fccf817d531 tty portable quiet

It seems it finds and boots fine UUID=0405-1514 (Fat-16 partition) since there are no more messages saying it was not find, but even with the new UUID of the ext4 partition it can't be found.

The way I see it is (on the USB) the Fat-16 was first partition (sda1) and the ext4 was second partition (sda2) and as there are some hiden folders on the ext4 partition containing addons and other info maybe related to my settings there has to be some links to them but as sda2, so I need to map both partitions to be loaded (like sda1 and sda2) as on their original locations on the USB when they are called by the kernel.

The problem is I don't know how to do this, any suggestions are wellcome.

 

EDIT: After finally make this work (see post No. 23 ) , I found the program used here to clone, didn't cloned the ext4 fine.

 

alacran


Edited by alacran, 13 October 2019 - 04:47 AM.


#18 erwan.l

erwan.l

    Platinum Member

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

Posted 12 October 2019 - 03:08 PM

About the UUID changing on the EXT part, this is surprising and I am wondering "what" changes this.
Simply cloning it should surely not change this field.

Not that you can use an hexeditor under windows to read/modify this UUID (to make your life easier and not having to boot under linux).

You could even go as far as installing an EXT driver (like Wonko suggested) but I am not sure for now what would really bring in your experiment.

Edit.

7zip will give you lots of useful details.

the parts within your disk.
the offset for each part (which can be handy if you want to mount it or edit it with a hexeditor).
the LABEL and UUID.

DEXtenD.png

B6rTkFR.png

#19 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 October 2019 - 03:10 PM

 

The problem is I don't know how to do this, any suggestions
 

FORGET about the UUID if you have issues with it, and use the LABEL instead.

If you cannot change the partition/volume LABEL, use the current one (or it has it not? :dubbio: )

Bootice and partition id mean nothing (70 or 00 are NOT volume serials/UUID's).

Anyway booted from Mint (or whatever other Linux) a LABEL can be changed just fine e2label or tune2fs

https://www.tecmint....n-label-names/ 

 

 

 would you say that the "volume UUID" always relates to the "volume serial", an information which is stored in the boot sector and not in the partition table (stored in MBR or GPT) - and should never change unless you reformat your volume.

Does the form of this UUID (4 bytes for FAT32 versus 16 bytes for EXT2/3/4) also changes depending on the filesystem?

 

Yes. 

If a volume is actually cloned, its serial (or UUID) does not change.

 

 

 

Does the form of this UUID (4 bytes for FAT32 versus 16 bytes for EXT2/3/4) also changes depending on the filesystem?

Sure it does.

"MS-derived" filesystems/volumes have a volume serial (and NOT an UUID).

"Linux-derived" filesystems/volumes have a volume UUID (and NOT a serial).

 

But since they are both a sort of "ID" of the volume, they are both called indifferently "volume serial" or "volume UUID".

 

If you prefer the command uuid (in grub4dos) or blkid (in Linux) returns:

volume serials for FAT/NTFS and similar

volume UUID's for Ext2/3/4 and similar

 

 

see:

https://askubuntu.co...ter-than-normal

 

BTW NTFS volume serials are actually 8 bytes, but you will only normally see in windows 4 of them, heck, I believe we already had this conversation :unsure:

http://reboot.pro/to...ed-drive-image/

 

 

Both have NOTHING to do with volume GUID (what you see in mountvol).

 

:duff:

Wonko 



#20 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 12 October 2019 - 03:22 PM

@ Wonko

 

The ext4 partition do not has a LABEL on the USB, and as said on my previous post I can't change (or apply) a LABEL to it even from Gparted ran from Linux Mint

 

The change in UUID and ID may be caused during cloning since it was done from Win and usually cloning programs ran on Win do not handle very fine Linux partitions or maybe because it is now a logical partition.

So far I can't change the ext4 partition Label even with Gparted ran from Linux Mint, it may be good if I would do it (as Wonko sugested) and then if its UUID change I will not care.

 

I would like to try this:

 

 

But then tryed a new entrace on my menu.lst as following:

title Start LibreELEC from HDD (Test-2)
find --set-root /syslinux.cfg
kernel /kernel boot=UUID=0405-1514 disk=UUID=03a48580-f0a2-4057-b5e3-30fccf817d531 tty portable quiet

It seems it finds and boots fine UUID=0405-1514 (Fat-16 partition) since there are no more messages saying it was not find, but even with the new UUID of the ext4 partition it can't be found.

The way I see it is (on the USB) the Fat-16 was first partition (sda1) and the ext4 was second partition (sda2) and as there are some hiden folders on the ext4 partition containing addons and other info maybe related to my settings there has to be some links to them but as sda2, so I need to map both partitions to be loaded (like sda1 and sda2) as on their original locations on the USB when they are called by the kernel.

The problem is I don't know how to do this, any suggestions are wellcome.

 

alacran



#21 erwan.l

erwan.l

    Platinum Member

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

Posted 12 October 2019 - 03:31 PM

@ Wonko

 

The ext4 partition do not has a LABEL on the USB, and as said on my previous post I can't change (or apply) a LABEL to it even from Gparted ran from Linux Mint

 

Try editing the ext4 part with an hexeditor : label seems to be at offset 0x478 right after the 16 bytes UUID ?

 

See my previous mail, if you are dealing with disk or part images, you can always open it with 7zip (readonly) and check its content but also its label and UUID (and therefore verify possibly changes you would have introduced by hexediting the UUID or label).

 

EDIT 

Example below, i have changed the label to ERWANXX in my EXT image (via Hxd) and i can see it reflected in 7zip.

 

uaQJTUt.png



#22 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 October 2019 - 04:32 PM

Hexediting it will be just fine :thumbsup: , but it is simply not possible  :frusty:  that alacran cannot run either of the two mentioned tools from "a" booted Linux.

There might be other problems with the volume/partition? :unsure:

 

Alternatively create a new storage partition Ext3FS with RMPREPUSB (from that same post by Steve6375):

 

4. Run RMPrepUSB with the E2B USB drive connected and selected. Make a \LibreElec-rw ext3 Filesystem file with a Volume Label of DATA. The size is up to you!

 

Or get a Windows driver (it has to be seen if it works on stupid Windows 10 though):

http://www.fs-driver.org/

 

 

 

  • All operations you would expect: Reading and writing files, listing directories, creating, renaming, moving and deleting files or directories, querying and modifying the volume's label.

 

or:

https://sourceforge....ojects/ext2fsd/

 

:duff:

Wonko



#23 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 12 October 2019 - 10:07 PM

@ erwan.l and @ Wonko

 

Thanks for all the info, using it and running some tests I was able to solve it.

 

Finally i can boot LibreELEC from the HDD.

 

On the USB the ext4 partition was hiden and with no permisions to write on it from outside of the LibreELEC running Kodi on top.

 

In order to make it easier to understand the procedure followed, I will use this names:

 

USB-1: The inicial USB with all my addons and setting and having on Ext4 partition a backup folder with my backup file 2109xxxxxx.tar

 

USB-2: A second 2 GB USB stick.

 

I booted from USB-1 and selected the option install and make an install on USB-2, when finished it asked to extract the install device wich I did and rebooted from USB-2 fine but without all my addons and settings and no backup present on backup file, then plugged again the USB-1 and it was mounted and from USB-2 selected to recover the backup from the USB-1 and after two reboots (one to apply the changes and second to boot with changes applied) all was as i like it, of course I made a fresh backup on USB-2 to have it available there if required.

 

Now USB-2 do not have anymore install or live options available, new Fat-16 partition UUID=5DA1-E8D7 and ext4 partition new ID is 83 and not hiden, and now both partitions on (USB-2) after the install procedure have LABELS, System on FAT-16 and Storage on ext4.

 

This is the new syslinux.cfg on USB-2

DEFAULT linux
PROMPT 0

LABEL linux
 KERNEL /KERNEL
 APPEND boot=UUID=5DA1-E8D7 disk=UUID=16e52db7-2c78-44f1-9003-a33d919292a4  quiet

As you can see both partitions UUIDs are different from those on USB-1.

 

Then by means of Partition Wizard 10.2 deleted both logical partitions created on my HDD and copied (they use copy not clone) the first partition from the USB-2 to unasigned space and it made an exact copy (I prefer the word clone) there, doing the same with the ext4 partition it was copied (cloned as I prefer) to a new partition on HDD too.

 

Then just edited a little my last entrance on menu.lst to:

 

 

title Start LibreELEC from HDD
find --set-root /syslinux.cfg
kernel /kernel boot=LABEL=System disk=LABEL=Storage tty portable quiet

 

And now I can boot by means of grub4dos from a 512 MB FAT-16 small partition + its storage partition 1.4 GB ext4 on my HDD.

 

 

If you prefer to boot from the USB by means of grub4dos, and do not want to make both little partitions on the internal disk, following entrace on menu.lst work fine:

 

 

title Start LibreELEC from USB
find --set-root /syslinux.cfg
map --hook
chainloader (hd0)+1
rootnoverify (hd0)

 

alacran



#24 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 12 October 2019 - 11:30 PM

Using RMPrepUSB from steve6375 (Drive to File button)  I made a .img image (using default settings) of my USB-2 and by means of the LibreELEC installer tool it can be re-installed on a SD or other USB device keeping all the addons and settings, and then there is no need to load the backup in this case.

 

RMPrepUSB from steve6375 also has File to Drive button, but I haven't tested it yet, nevertheless I assume it will work fine too.

 

The advantage of using the installer tool from LibreElect is that after making the .img with RMPrepUSB it can be compressed with 7-zip as .gz or .zip, and the installer can install directly from it, wich is good to save space.

 

And this install on SD or USB is portable, I mean it boots on different PCs, and only thing I needed to do is connect to the Router with the new found WIFI device.

 

alacran



#25 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 October 2019 - 09:25 AM

Good :) , now you should go back to post #13 ;

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

 

And experiment with the system image *like*:

 

 

kernel /MYKERNEL BOOT_IMAGE=MYKERNEL SYSTEM_IMAGE=MYSYSTEM boot=LABEL=FLASH live quiet

 

Possibly adding a "disk=LABEL=Storage".

 

That would allow you to have not any mapping in the MBR as long as you "extract" the kernel and system from the first partition of the image and save them as "plain" files   :unsure:

 

About the use of "copy" vs. "clone" in this (or that) software it is not entirely unlike what happens with disk, drive, partition. volume, the issue here is that a clone (by defintion) is an exact, sector by sector byte by byte, copy, i.e. it is identical, what I personally call "forensic sound" or "dd-like" copy/image.

What most cloning programs do however is not strictly speaking a "clone" but rather an "adaptive clone", i.e. most (like 99.9999% of sectors/bytes are actually exactly the same but at least one value (the LBA offset or "Sectors Before") is "adapted" to reflect the (different) placement of the volume and other fields (H/S geometry) may well (should) be "adapted" to a different underlying device geometry. 

Additionally (depending on the specific program and the settings chosen) they may also ignore non-indexed areas (unlallocated space) and even "compact" (or "defrag") files.

But even in this latter case the "clone" (which is much more a "copy" than a "clone") will normally work just fine to most practical purposes, so it is in practice a sort of  "good enough clone" or possibly a "functional copy".

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users