Syslinux - Dec 2014 - [PATCH 0/8] extlinux: support unmounted ext2/3/4 filesystem

On 12/25/2014 01:43 PM, Ady wrote:
>
>>
>>
>> On 12/25/2014 04:33 AM, H. Peter Anvin wrote:
>>> On 12/24/2014 12:16 AM, Robert Yang wrote:
>>>> Hello syslinux,
>>>>
>>>> Merry Christmas! These patches will make extlinux work with
umounted
>>>> ext2/3/4 filesystem, for example:
>>>>
>>>> $ extlinux -i /dev/sdXN
>>>> or
>>>> $ extlinux -i file_block
>>>>
>>>> Also it can work with something like:
>>>> $ extlinux /dev/sdXN  --reset-adv
>>>> or
>>>> $ extlinux file_block --reset-adv
>>>>
>>>> We don't use a new option (I planed to use "-d"
but it is already in
>>>> use), it will check whether the target is a directory or device
and
>>>> decide what to do, it would stop and error if the device is
mounted.
>>>>
>>>> I put these patches on github so that you can easily get them
in case
>>>> you'd like to test them. (The repo's name is sys_tmp,
which avoids
>>>> confusing others, I will remove the repo when these patches are
>>>> reviewed).
>>>>
>>>> More info:
>>>> * It will use libext2fs to read and write the file.
>>>> * It will be used when the target is a extX device or file
block, and
>>>>     work as before when the target is a directory.
>>>> * It will be used for both modifing the existing adv when
>>>>     update_only == -1, and install the files to the filesystem.
>>>>
>>>> We will begin to use this feature in Yocto Project once it is
fine to
>>>> the syslinux community.
>>>>
>>>
>>> I believe we should unify this with the syslinux installer, which
is
>>> used for unmounted FAT filesystems.  Ideally we should unify that
with
>>> the extlinux installer too, but that may be a later project.
>>
>> Hello hpa,
>>
>> What does "unify that with the extlinux installer too" mean,
please ? And
>> I will add the patches to syslinux (not syslinux-mtools), and we
don't require
>> the root privilege if it is ext2/ext3/ext4 since it doesn't need
mount, what's
>> your opinion, please ?
>>
>> // Robert
>>
>>>
>>> 	-hpa
>>>
>>>
>>>
>>>
>>
>
> If I may...
>
> Note: Please do _not_ accept the following descriptions as accurate
> without confirmation that the installers are indeed currently working
> as described here.
>
> _ All the 'syslinux' commands use "device" as argument.
>
> _ The 'linux/syslinux-nomtools' installer uses system calls.
>
> _ The 'mtools/syslinux' installer requires unprivileged write
> permissions and mtools.
>
> So to continue with the same reasoning:
>
> _ An installer capable of writing to extN-formatted "devices"
would
> seemingly mean adding extN support to 'linux/syslinux-nomtools'.
This
> installer shall still be "standalone".
Hi Ady,

Thank you very much, I prefer this one, add the extN support to
linux/syslinux-nomtools, create a new "e2fs/syslinux" may make things
more complicated for the user, I will make it as:

1) If it is a extN device, then root privilege is not required.
2) Otherwise work as before.

Any suggestions is appreciated.

// Robert
>
> _ An installer capable of writing to extN-formatted "devices"
while
> requiring less permissions (i.e. unprivileged write permissions only)
> would seemingly mean an equivalent to the current 'mtools/syslinux'
> installer, but for extN. Perhaps this would mean a new
"e2fs/syslinux"
> installer? (Note that I don't mention the "libext2fs" term
here, as it
> is "too-long" and some distros might use a slightly-different
(package)
> name for the same library/capability/support/tool).
>
> This would also maintain current documentation and so-called
> "tutorials" still (mostly) relevant, avoiding confusions (to
final
> users) about the features and usage of the 'extlinux' command.
>
> Regards,
> Ady.
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>
>

> 
> Hi Ady,
> 
> Thank you very much, I prefer this one, add the extN support to
> linux/syslinux-nomtools, create a new "e2fs/syslinux" may make
things
> more complicated for the user, I will make it as:
> 
> 1) If it is a extN device, then root privilege is not required.
> 2) Otherwise work as before.
> 
> Any suggestions is appreciated.
> 
> // Robert
> 
 
I am not sure that a different installer would make things more 
complicated to users. I don't see why.

I have no "say" (other than my personal opinion) about what
"should"
happen, or how each installer "should" work.

But I would like to clarify (or remind) why things are currently 
working as they are.

The use-case you are presenting here is valid: a user wants to install 
SYSLINUX (EXTLINUX) on ext2/3/4 without requiring root permissions. 
This sounds equivalent/similar to: install SYSLINUX on FAT without 
requiring root permissions. The 'mtools/syslinux' installer responds to 
the latter.

The 'linux/syslinux-nomtools' installer aims at being
"standalone". The
intention is to avoid requesting additional dependencies (as the other 
installers do). To be able to perform the installation without 
additional dependencies, the nomtools installer requests additional 
privileges, so to be able to use system calls. In other words, 
"something gotta give".

In contrast, the 'mtools/syslinux' installer provides a solution for 
the alternative case: it has dependencies (mtools) but requires only 
unprivileged write permissions.

Adding e2fs (e2fsprogs or the respective library) as dependency to the 
'linux/syslinux-nomtools' installer would go against the reasoning to 
having this installer. This is why, to be able to keep current 
reasoning, a new 'e2fs/syslinux' seems a valid possibility.

If, after your (future) patches, the 'linux/syslinux-nomtools' 
installer would still work in FAT without requiring (read as 
"complaining about") e2fsprogs' libraries at all, then it is up to
Peter (hpa) to decide whether this behavior would still be accepted, as 
it would break the concept of being "standalone", at least for extN. 
Unfortunately, even if this behavior would be accepted, the 
'linux/syslinux-nomtools' installer would still list e2fsprogs (or a 
library from it) as dependency, whether the user has the intention to 
use it on FAT only or not.

Let me present a use-case different than the one you are presenting 
here. "A user should be able to install SYSLINUX (EXTLINUX) on ext2/3/4 
without additional dependencies". As with the FAT case, the answer 
should be to have a "standalone" installer using system calls, i.e. 
requiring root permissions. This use-case would be resolved by patching 
'linux/syslinux-nomtools' to support extN.

So, I hope I am clarifying why a different installer (responding to a 
different use-case, as you are presenting here), would be a valid 
possibility.

Now it is up to Syslinux's developers (mainly hpa).

Thank you and Best Regards,
Ady.

On 12/25/2014 04:14 PM, Ady wrote:
>>
>> Hi Ady,
>>
>> Thank you very much, I prefer this one, add the extN support to
>> linux/syslinux-nomtools, create a new "e2fs/syslinux" may
make things
>> more complicated for the user, I will make it as:
>>
>> 1) If it is a extN device, then root privilege is not required.
>> 2) Otherwise work as before.
>>
>> Any suggestions is appreciated.
>>
>> // Robert
>>
>
> I am not sure that a different installer would make things more
> complicated to users. I don't see why.
>
> I have no "say" (other than my personal opinion) about what
"should"
> happen, or how each installer "should" work.
>
> But I would like to clarify (or remind) why things are currently
> working as they are.
Thanks for the explanation, and please see my comments inline.
>
> The use-case you are presenting here is valid: a user wants to install
> SYSLINUX (EXTLINUX) on ext2/3/4 without requiring root permissions.
> This sounds equivalent/similar to: install SYSLINUX on FAT without
> requiring root permissions. The 'mtools/syslinux' installer
responds to
> the latter.
>
> The 'linux/syslinux-nomtools' installer aims at being
"standalone". The
> intention is to avoid requesting additional dependencies (as the other
> installers do). To be able to perform the installation without
> additional dependencies, the nomtools installer requests additional
> privileges, so to be able to use system calls. In other words,
> "something gotta give".
>
> In contrast, the 'mtools/syslinux' installer provides a solution
for
> the alternative case: it has dependencies (mtools) but requires only
> unprivileged write permissions.
>
> Adding e2fs (e2fsprogs or the respective library) as dependency to the
> 'linux/syslinux-nomtools' installer would go against the reasoning
to
> having this installer. This is why, to be able to keep current
> reasoning, a new 'e2fs/syslinux' seems a valid possibility.
>
> If, after your (future) patches, the 'linux/syslinux-nomtools'
> installer would still work in FAT without requiring (read as
> "complaining about") e2fsprogs' libraries at all, then it is
up to
Add hpa in the loop, unfortunately, once the patches are added
to linux/syslinux-nomtools, then the e2fsprogs' libraries are required.

I'm fine to add a e2fs/syslinux. At the moment before we get a final
decision, I will go on working on added the patches to linux/syslinux-nomtools,
it should be easy to split it from linux/syslinux-nomtools to e2fs/syslinux,
and I will split it at once if we decide to do that.

// Robert
> Peter (hpa) to decide whether this behavior would still be accepted, as
> it would break the concept of being "standalone", at least for
extN.
> Unfortunately, even if this behavior would be accepted, the
> 'linux/syslinux-nomtools' installer would still list e2fsprogs (or
a
> library from it) as dependency, whether the user has the intention to
> use it on FAT only or not.
>
> Let me present a use-case different than the one you are presenting
> here. "A user should be able to install SYSLINUX (EXTLINUX) on
ext2/3/4
> without additional dependencies". As with the FAT case, the answer
> should be to have a "standalone" installer using system calls,
i.e.
> requiring root permissions. This use-case would be resolved by patching
> 'linux/syslinux-nomtools' to support extN.
>
> So, I hope I am clarifying why a different installer (responding to a
> different use-case, as you are presenting here), would be a valid
> possibility.
>
> Now it is up to Syslinux's developers (mainly hpa).
>
> Thank you and Best Regards,
> Ady.
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>
>