[ SOLVED ] Booting Live from ext4

[Was_Just19]

I have noticed that the PCLOS ISOs will not boot live from an ext4 partition ........  whether on a USB device or on a fixed disk.

So I am wondering if this is in the mix for attention for the next round of ISO releases?

Any info would be welcome

thanks.

[Was_Just19]

This limitation seems to be still present -- or was in the last ISO I created with mylivecd.

Unfortunately it applies to running live from USB and fixed disk, so LiveUSB and Poorman installs are affected.

It would be advantageous if ext4 was supported for such live installs.

regards.

[Was_Just19]

I have been searching about for some reason this may not be working, but I am groping in the dark 

Is there something in the Busybox build that affects this? ....  on the assumption that Busybox is what is being used at the time ....

Does the content of    /etc/filesystems   have any bearing on things?

Anyone with ideas?

[pags]

Could this be a kernel/etx4 issue, not unlike the previous VirtualBox vdi on ext4 issue?

Just thinking out loud...could be waaaay off base, here!

[AS]

Hi,

when a live image is placed on an ext4 filesystem, it really does boot, failing at time of mounting the rootfs; I think that the reason is that at time of booting the kernel has support only for ext2 filesystem (not even ext3).

While an ext3 filesystem is allowed to be mounted as ext2, ext4 look like not.

However, the system is left with a /bin/ash prompt, dmesg show the following output:

EXT2-fs: (sdb1) couldn't mount because of unsupported optional features (240)

clearly is trying to mount /dev/sdb1, which is ext4, as an ext2 type fs.
further: cat /proc/filesystems show an entry for ext2 but no entry for ext3 or ext4.

Hopefully someone with better knowledge than me about kernel/initrd features can provide additional input about how to fix this issue.

AS

[Was_Just19]

when a live image is placed on an ext4 filesystem

Does the device type matter?
Do you see the same results if the device is removable or fixed?


I do not see how Grub can be involved in this case.

Grub successfully calls the initrd and after that has no further involvement AFAIK.

[AS]

when a live image is placed on an ext4 filesystem

Does the device type matter?
Do you see the same results if the device is removable or fixed?


I do not see how Grub can be involved in this case.

Grub successfully calls the initrd and after that has no further involvement AFAIK.

will post a screenshot about in a few minutes ... here it is.
And no, it's not grub here, i get confused by the similar output of "Searching for loop image:".

Only tested from an hard-disk partition (/dev/sdb1) actually.



dmesg output, loot at /dev/sdb1:

[Was_Just19]

Thanks  as   ......  that brings me back to    Busybox?  or is it  ash?    support for ext4 ...... I dunno for sure what is being used at that time ...

[AS]

Thanks  as   ......  that brings me back to    Busybox?  or is it  ash?    support for ext4 ...... I dunno for sure what is being used at that time ...

it is really busybox, /initrd/bin/ash is an hard link to /initrd/bin/busybox, the ext4 support should be provided from kernel, but as I understand,
being a module it's actually not loaded until rootfs is mounted, and rootfs is not mounted because the mount statement actually fail.

ext3 doesn't fail because because can be mounted as ext2.

if you format a partition as ext3, and then you try to mount it as ext2 (mount /dev/sdaX /mnt -t ext2) will succed.
if you format a partition as ext4, and then you try to mount it as ext2 (mount /dev/sdaX /mnt -t ext2) will fail.

AS

[Was_Just19]

Thanks  as   ......  that brings me back to    Busybox?  or is it  ash?    support for ext4 ...... I dunno for sure what is being used at that time ...

it is really busybox, /initrd/bin/ash is an hard link to /initrd/bin/busybox, the ext4 support should be provided from kernel, but as I understand,
being a module it's actually not loaded until rootfs is mounted, and rootfs is not mounted because the mount statement actually fail.

ext3 doesn't fail because because can be mounted as ext2.

if you format a partition as ext3, and then you try to mount it as ext2 (mount /dev/sdaX /mnt -t ext2) will succed.
if you format a partition as ext4, and then you try to mount it as ext2 (mount /dev/sdaX /mnt -t ext2) will fail.

AS

Therin lies my confusion ........  I understood that Busybox is supposed to have ext4 support.

Is it then possible that this support has been omitted in the Busybox build and that is what is at the root of the problem?

A reply in this link from 2009, seems to say it has ext4 support
http://www.0x61.com/forum/busybox-linux-f110/does-busybox-mount-support-ext4-t1267025.html

busybox will exec mount.ext4 (See discussion: Re: Silent failure of busybox mount for unknown fs type few days ago).  therefore if you have mount.ext4 it will work.

Maybe it needs to be called explicitly rather than the general mount ?

regards.

[Was_Just19]

While trawling I picked up a reference to Busybox mount command being equal to mount.ext2

That would seem to confirm what  as  said above about an ext3 being mounted as ext2.

I find it difficult to find up to date info, but it looks like explicitly specifying the file system in the command might solve the problem .......  use

mount.ext2
mount.ext3
mount.ext4
                    where appropriate ....  or use them in series, moving to the next as each one fails .....

mount.ext4 || mount.ext3 || mount.ext2

If something like that were possible the all three fs types should mount as the correct type.


regards.

[AS]

Therin lies my confusion ........  I understood that Busybox is supposed to have ext4 support.

Busybox provide a "mount" command, including option "-t FSTYPE", doesn't provide mount.ext2, mount.ext3, mount.ext4:
http://www.busybox.net/downloads/BusyBox.html

As I understand, however, busybox only provide the mount command, ext4 filesystem support is still provided from kernel which is responsible for all hardware interfaces, isn't that busybox "mount" command, at time of failure, is simply called with the option "-t ext2" ?

AS

[AS]

... at time of mount failure, the root filesystem is that one provided from initrd, that in fact is mounted as rootfs;
a listing of fs modules, show that there is no ext3 module, nor ext4 module. (ext2 is built-in in kernel).

(Note: the KDE2012 in win title is a short for KDE2010-12    )

[AS]

Finally succeed in booting from ext4!

I have tweaked the mylivecd script to include ext4 and jbd2 modules in initrd, now livehdd is booting and mounting correctly ext4 rootfs.

AS

[Was_Just19]

Finally succeed in booting from ext4!

I have tweaked the mylivecd script to include ext4 and jbd2 modules in initrd, now livehdd is booting and mounting correctly ext4 rootfs.

AS

Great news!!!!!!!!!!!

Can you post details of the changes please?   

(adding the modules to the linuxrc file?)