Skip to content
Permalink
Browse files

最近收到一些特殊的错误报告,最后证明是非标准的Ventoy环境的原因。尤其是单分区下环境下使用 Ventoy 。

虽然 Ventoy 显示了 Unofficial 的标注信息,但是用户并不会关心,仍然会认为是 Ventoy 的问题。

Ventoy 从一开始就是一个整体的设计,并没有考虑过集成在其他bootloader或分区环境中。
Ventoy 的验证和后续新功能开发也都不会考虑这种非标准的使用方式。

因此,我决定禁止 Ventoy 在非标准环境下的使用,并且不再接受放开检查的请求。

当然,这个只是Ventoy的默认行为。Ventoy仍然是100%开源的,如果你希望把Ventoy应用在自己的环境中,你可以fork一个分支,然后修改源代码实现。
  • Loading branch information
ventoy committed Nov 13, 2020
1 parent f7d7db6 commit 8bbd5a14a3ca4820266bed6afc1314c3f41e76c3
@@ -408,12 +408,12 @@ STATIC VOID ventoy_warn_invalid_device(VOID)
gST->ConOut->OutputString(gST->ConOut, VTOY_WARNING L"\r\n");
gST->ConOut->OutputString(gST->ConOut, VTOY_WARNING L"\r\n\r\n\r\n");

gST->ConOut->OutputString(gST->ConOut, L"This is NOT a standard Ventoy device and is NOT officially supported.\r\n\r\n");
gST->ConOut->OutputString(gST->ConOut, L"This is NOT a standard Ventoy device and is NOT supported.\r\n\r\n");
gST->ConOut->OutputString(gST->ConOut, L"You should follow the official instructions in https://www.ventoy.net\r\n");

gST->ConOut->OutputString(gST->ConOut, L"\r\n\r\nWill continue to boot after 15 seconds ...... ");
gST->ConOut->OutputString(gST->ConOut, L"\r\n\r\nWill exit after 10 seconds ...... ");

sleep(15);
sleep(10);
}
#else
STATIC VOID ventoy_warn_invalid_device(VOID)
@@ -718,6 +718,7 @@ STATIC EFI_STATUS EFIAPI ventoy_parse_cmdline(IN EFI_HANDLE ImageHandle)
if (pEnv[0] != '0' || pEnv[1] != 0)
{
ventoy_warn_invalid_device();
return EFI_INVALID_PARAMETER;
}

g_file_replace_list = &pGrubParam->file_replace;
@@ -185,7 +185,7 @@ typedef struct ventoy_virt_chunk
#error Unknown Processor Type
#endif

#define VENTOY_DEVICE_WARN 0
#define VENTOY_DEVICE_WARN 1
#define VTOY_WARNING L"!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!"

typedef struct ventoy_sector_flag
@@ -1639,15 +1639,14 @@ int ventoy_check_device_result(int ret)
grub_env_set("VTOY_CHKDEV_RESULT_STRING", buf);
grub_env_export("VTOY_CHKDEV_RESULT_STRING");

if (ret & 0x1000)
if (ret)
{
grub_printf(VTOY_WARNING"\n");
grub_printf(VTOY_WARNING"\n");
grub_printf(VTOY_WARNING"\n\n\n");

grub_printf("Unsatisfied conditions detected for Ventoy.\n\n");
grub_printf("This is NOT a standard Ventoy device and is NOT officially supported.\n\n");
grub_printf("Recommend to follow the instructions in https://www.ventoy.net to use Ventoy.\n");
grub_printf("This is NOT a standard Ventoy device and is NOT supported.\n\n");
grub_printf("You should follow the instructions in https://www.ventoy.net to use Ventoy.\n");

grub_printf("\n\nWill exit after 10 seconds ...... ");
grub_refresh();
@@ -3522,7 +3521,7 @@ static grub_err_t ventoy_cmd_load_part_table(grub_extcmd_context_t ctxt, int arg
ret = ventoy_check_device(dev);
grub_device_close(dev);

if (ret & 0x1000)
if (ret)
{
grub_exit();
}

22 comments on commit 8bbd5a1

@a1ive

This comment has been minimized.

Copy link
Contributor

@a1ive a1ive replied Nov 13, 2020

因此,我决定禁止 Ventoy 在非标准环境下的使用,并且不再接受放开检查的请求。
Ventoy仍然是100%开源的,如果你希望把Ventoy应用在自己的环境中,你可以fork一个分支,然后修改源代码实现。

如果用户用了其他人 fork 的版本,出现错误,还是会认为是 Ventoy 的问题啊。

@ventoy

This comment has been minimized.

Copy link
Owner Author

@ventoy ventoy replied Nov 13, 2020

是的,这个没法根本避免。不过能避免一些常见的情况,现在看到的都是 UEFI 模式下魔改 grub.cfg 之后集成使用的场景。

@a1ive

This comment has been minimized.

Copy link
Contributor

@a1ive a1ive replied Nov 13, 2020

是的,这个没法根本避免。不过能避免一些常见的情况,现在看到的都是 UEFI 模式下魔改 grub.cfg 之后集成使用的场景。

发布带签名的 EFI 文件,并且校验 EFI 文件的签名怎么样?
这样也为将来更好地支持安全启动做准备。

@ventoy

This comment has been minimized.

Copy link
Owner Author

@ventoy ventoy replied Nov 13, 2020

这也是个思路。现在基本功能里就只剩下安全启动还没有好好弄一下了。

@steve6375

This comment has been minimized.

Copy link

@steve6375 steve6375 replied Nov 14, 2020

Many users of Easy2Boot have contacted me about this new change. Please reconsider this change. Ventoy should test for bad cases and halt. If Single Partition is a bad case then halt. Otherwise just display 'Unofficial' Warning as before. Easy2Boot supports UEFI32, Secure Boot UEFI64, partition image files and much more. Many users also want to add Ventoy.
This will cause forking of Ventoy and much confusion when a user reports a problem to you.

@ventoy

This comment has been minimized.

Copy link
Owner Author

@ventoy ventoy replied Nov 14, 2020

这是一个比较麻烦的问题。因为这偏离了Ventoy设计的初衷。我已经遇到了很多起这样的情况,我花费了很多时间来定位用户的问题,最后发现是分区不标准的问题。
Unofficial的标注用户并不会关心。我也不想每次看问题之前都要问一下“你用的是不是标准的Ventoy?”
即使是这样也还是有很多其他情况,比如很多人喜欢修改原始的 grub.cfg 来适配自己的环境。而这有时会造成Ventoy的某些功能出问题。

@tankmdg

This comment has been minimized.

Copy link

@tankmdg tankmdg replied Nov 14, 2020

Can someone put what unofficial system means? Its in jap/china and cant read

@steve6375

This comment has been minimized.

Copy link

@steve6375 steve6375 replied Nov 14, 2020

I also get many issues with Easy2Boot where it is the users fault where it has been used in non-standard situation. I always ask for basic facts for any problem. Akeo (Rufus) also always asks for basic information with any problem report. It is a common problem with users. I suggest you always ask basic questions:
What version Ventoy?
What USB drive (size/make/model)?
How was it prepared (method, OS, etc.)?
What payload file + download URL?
Steps to reproduce the problem?
What you did?
What you saw?
What you tested it on (VM? Real system? CPU/RAM/OS)?
etc.

The Forum should make it clear that any problem MUST be reported when using an official Ventoy USB drive.
Since Ventoy 1.0.27 used to display (Unofficial Ventoy) in previous versions - this is an easy question to ask.
Ventoy should check for illegal cases only.

@steve6375

This comment has been minimized.

Copy link

@steve6375 steve6375 replied Nov 14, 2020

1.0.28 checks MBR partitions for partition 1 start = 2048, partition 2 size = 65536, partition 2 start = ptn1 start+ptn1 size
maybe some more checks too... So USB drive needs to have been made using the Ventoy Make utility.

@anwar-alsilwy

This comment has been minimized.

Copy link

@anwar-alsilwy anwar-alsilwy replied Nov 14, 2020

We use Ventoy with Easy2boot and a1ivegfm for more than 3 months without any problems,
It just works fine,
I tested many kinds of ISOs/wim/vhd files, without any issues.
We satisfied all your considerations to run Ventoy, and what else??
I think (Unofficial Ventoy) message is more than enough for us.

@a1ive

This comment has been minimized.

Copy link
Contributor

@a1ive a1ive replied Nov 14, 2020

Unofficial的标注用户并不会关心。我也不想每次看问题之前都要问一下“你用的是不是标准的Ventoy?”

可以为 issues 设置模板:
https://docs.github.com/cn/free-pro-team@latest/github/building-a-strong-community/configuring-issue-templates-for-your-repository
示例:
深度截图_选择区域_20201114203140

@C0rn3j

This comment has been minimized.

Copy link

@C0rn3j C0rn3j replied Nov 14, 2020

Personally I don't get why would you even want to use Ventoy with another multi-USB solution, especially a proprietary one?

Commit message translated to english for those who do not speak chinese and are too lazy to use a translator:


Recently, I received some special error reports, which finally proved to be the cause of the non-standard Ventoy environment. Especially use Ventoy in a single partition environment.

Although Ventoy displays Unofficial's label information, users will not care and will still think it is a Ventoy problem.

Ventoy has been an overall design from the beginning, and has not considered integration into other bootloader or partition environments.
Ventoy's verification and subsequent development of new features will not consider this non-standard usage.

Therefore, I decided to prohibit the use of Ventoy in a non-standard environment and no longer accept requests for deregulation.

Of course, this is just the default behavior of Ventoy. Ventoy is still 100% open source. If you want to apply Ventoy in your own environment, you can fork a branch and modify the source code implementation.

@tankmdg

This comment has been minimized.

Copy link

@tankmdg tankmdg replied Nov 15, 2020

@anwar-alsilwy

This comment has been minimized.

Copy link

@anwar-alsilwy anwar-alsilwy replied Nov 15, 2020

We understand that Ventoy has been designed to work on two partitions.
I used (Unofficial) Ventoy, but in very traditional way, it's like:
1st partition(NTFS)= Easy2boot+iso/wim/vhd payloads.
2nd partition(fat32)=Ventoy+a1ivegfm.
3rd partition= my own files.
Ventoy works perfect for me without a single error,
I tested with a lot of ISO types (win , Linux ,..etc).
The developer can prohibit Ventoy from working on single partition environments, Or very aberrant work environments.
it's better for project to be flexible,
And the main goal to be a developer is (listen to people, ask them), so you can improve your project.

@steve6375

This comment has been minimized.

Copy link

@steve6375 steve6375 replied Nov 15, 2020

By adding Ventoy to E2B it allows Secure UEFI64 boot to Ventoy without needing Mok Manager. Ventoy can also boot Linux ISOs without needing for file to be contiguous.

I can make a fork of Ventoy for E2B and make my own version. I will remove the 'Unofficial Ventoy' message and remove the partition test.
LongPanda may then receive bug reports from my version and there will be no way to tell if it is E2B version or LongPanda version!
It makes more sense if LongPanda simply tested for presence of two or more Primary MBR partitions plus other tests as in 1.0.27. By causing Ventoy to be forked it will make even more of a problem for him!

@ventoy

This comment has been minimized.

Copy link
Owner Author

@ventoy ventoy replied Nov 15, 2020

By adding Ventoy to E2B it allows Secure UEFI64 boot to Ventoy without needing Mok Manager. Ventoy can also boot Linux ISOs without needing for file to be contiguous.

I can make a fork of Ventoy for E2B and make my own version. I will remove the 'Unofficial Ventoy' message and remove the partition test.
LongPanda may then receive bug reports from my version and there will be no way to tell if it is E2B version or LongPanda version!
It makes more sense if LongPanda simply tested for presence of two or more Primary MBR partitions plus other tests as in 1.0.27. By causing Ventoy to be forked it will make even more of a problem for him!

我觉得不管是使用Kaspersky的grub漏洞(Easy2Boot的方式)还是使用Super-UEFIinSecureBoot-Disk(Ventoy的方式) 来绕过安全启动的行为都是不合适的。
这违背了安全启动设计的初衷。因此Ventoy后续的版本会修改这一方式,遵循安全启动的本意,只允许签名的EFI运行。

在开源领域,如果fork一个项目,并且会提供给自己的用户使用的话,一般应该修改一个名字用来和原来的项目做区别,并且给用户提供维护。比如 MyEclipse & Eclipse。
因此,如果你fork的话,建议你可以叫E2BVentoy而不是Ventoy。当然并没有一个强制性的条款来规定你必须这样做。这只是开源界的一个一般性准则。

毕竟开源项目给我们带来了方便,我们不应该给作者带来更多的困扰。

Ventoy项目只是我自己的一个爱好,开源也只是我的一个选择。如果Ventoy带给我更多的不再是快乐而变成了困然,我也可以选择不再开发或者不再开源,这对我并没有什么影响,因为Ventoy对我的生活来说并不是不可或缺的。

@pthfdr-42

This comment has been minimized.

Copy link

@pthfdr-42 pthfdr-42 replied Nov 15, 2020

@ventoy
I strongly object your decision.

  1. Non-"standard" GRUB configs/partitioning:

By doing this you completely prohibited user customization to the Ventoy partition.
The nag screen is already disgusting, and THIS CHANGE IS BORDERLINE DRM.
Removing this restriction requires recompilation, which is no easy task:

  • It needs third-party code (specific versions of third-party code)
  • It needs a specific environment (CentOS 7.8)
  • It needs specific packages that would break the host system, like NetworkManager (not everyone want to lick Lennart's "D"), grub2-tools (which would install GRUB2 on the host system), automake/autoconf (there is a reason why they are called "auto* hell")
  • It would also be bad in the long term since after enough changes to the code it would no longer be a trivial task.
  1. SecureBoot:

The real purpose of SecureBoot is for OEMs to implement vendor lock-in so you cannot boot anything other than their own spyware-ridden custom version of Windows. Especially with some Chinese laptops that does not let you disable it or use your own keys. I see no problem in bypassing that BS.

@C0rn3j

Personally I don't get why would you even want to [...]

If the user do it, they have their reasons, and they know what they are doing.

@ventoy

This comment has been minimized.

Copy link
Owner Author

@ventoy ventoy replied Nov 15, 2020

I just want Ventoy to work the way I designed it.

@C0rn3j

This comment has been minimized.

Copy link

@C0rn3j C0rn3j replied Nov 15, 2020

@pthfdr-42

Removing this restriction requires recompilation, which is no easy task

This is a separate issue on its own.
If you think the build process is not as easy as it should be, you can help by documenting it or automating it better.

Spinning up an LXD or a Docker container with CentOS is very easy.
You could make a Docker image that builds Ventoy, and letting others do changes on the build process would be fairly trivial after.

The real purpose of SecureBoot is for OEMs to implement vendor lock-in

I don't really have a horse in this race as I use unmodified Ventoy, but if you want to get this change reverted, spreading garbage about Secure Boot won't help your case.
Yes, Secure Boot can be used for lock-in. No, that is not its primary use.


@ventoy
Some users here suggested having a Github Issue template, which I think should exist no matter if this change stays or not.
It would improve the quality of the issues thus saving your and volunteer's time.

@steve6375

This comment has been minimized.

Copy link

@steve6375 steve6375 replied Nov 15, 2020

If LongPanda wants to limit Ventoy to just work on dedicated Ventoy USB drives then we must respect that decision. It is his code and it is open source so others can use it too.
E2B has 700,000+ downloads in a year and has many users who would also like to help develop and test the Ventoy grub2 code, but it seems that this will no longer be possible.
Also, Linux developers will not want to include 'Ventoy compatible' code into any of their Linux ISOs because it now can only be tested on a very small population of specially prepared, proprietary 'Ventoy' USB drives and so grub2 developers will not be interested in adopting Ventoy code either. It is a shame.

@devdevadev

This comment has been minimized.

Copy link

@devdevadev devdevadev replied Nov 18, 2020

Greetings to Lord LongPanda...
First lots of thanks for blessing Ventoy as a special gift to all of us....

Recently, Lord LongPanda received some special error reports, which finally proved to be the cause of the non-standard Ventoy environment. Especially use Ventoy in a single partition environment. So Lord LongPanda should Prohibit the use of Ventoy in a single partition environments only. While he had also prohibited unofficial use of Ventoy in two partition environment which is totally closed to the official environmnt and have not arises any issue at all. I don't see any logic behind prohibing two Partition environment which was already fulfilling the official Ventoy requirement except Partition 2 size of 65536 sectors.

So I pray to Lord LongPanda to show some kindness and allow his die hard fans to enjoy Ventoy blessings in two partition environments with following changes...

Change 1- pMBR->PartTbl[1].SectorCount >= 65536
Change 2- pMBR->PartTbl[1].SectorCount >= 65536 & pMBR->PartTbl[1].SectorCount < 2097152

We need more spare within FAT32 Partition 2. Please allow us to use (1024 MB < PTN2 >= 32 MB) in our Multiboot USB Drive. Please consider our pray and accept either of above two changes in future release of Ventoy ??

Thanks & Regards...

@pbatard

This comment has been minimized.

Copy link

@pbatard pbatard replied Nov 21, 2020

Rufus developer here.

I'm going to weigh in on this issue by stating that, unless you have a developer of a successful application, I don't think you can get an idea of just how much time is being sunk into trying to support that application, especially with people who feel that you should personally support their very custom workflow.

My e-mail inbox, and I'm pretty sure this is the same for LongPanda/ventoy, is filled with requests from folks who are telling me: "I want to use Rufus/Zadig/<some other app> in a very specific way, that is custom to a specific workflow, and, because you are a Free Software developer, I will be expecting YOU to invest tens of hours of development time to make sure that your application works for this special purpose, even if that's something that 99.9% of the other users of your application will never have any use for"

In other words, one of the harsh truth that people need to hear is that there unfortunately exists A LOT of folks out there who'd like nothing more but treat Free Software developers as if they were their own personal slaves.
I tend to call this the "Steve Jobs complex", in that a lot of these folks also seem to think that they are some kind of new incarnation of Steve Jobs, and that, because they invested some energy coming up with what they think is a great idea, it's only right that they should be able to muster an army of developer, for free, whose sole purpose should be to devote their time to make that idea a reality. Or, another more common term you may hear for that kind of attitude, is "choosing beggars".

Yet, what this minority fails to realize (besides the fact that, no, they are far from having the full technological background that kind of gave Steve Jobs an excuse for tyrannically pursuing his vision with a hefty supply of corporate developers) is that developers of a Free Software application are NOT paid to do anyone's bidding. There isn't even an implicit contract that the application is going to be fit for the purpose you want to use it for. Heck, this is actually one of the most prominent wording of the GPL (that is really in ALL CAPS in the license):

THE PROGRAM (IS PROVIDED) "AS IS" WITHOUT WARRANTY OF ANY KIND (...) INCLUDING (...) FITNESS FOR A PARTICULAR PURPOSE.

It really can't get any clearer than that.

What this means therefore is that, if you want to use an application in a specific way, but the developer sees it differently, then tough luck: You can huff and puff all you want, but the developer of the application always has the final word as to what features they want or do not want to support.

Which brings us back to the main point I am trying to make:

From a developer's perspective, trying to support the use of an application in a configuration that FEW people are going to use is usually a lot more trouble than it's worth

On this subject, one thing I always try to point out is that it's never really the adding of the code to support a specific feature that is the hard part, but it's ensuring that it continues to work from one version to the next. That is because, if you (the developer) inadvertently break it, you bet that you'll be subjected to an immediate string of abuse for "not doing your job properly" or "being a lousy developer" (which are actual messages I got, so yeah, I'm not being theoretical here). The problem is that. as soon as you imply that your application can be used in a specific manner, even if it's only used by 50 people in all, then God forbid that it gets broken even by mistake... And that can get real taxing on a developer real fast, because these "set of rarely used features that are time consuming to support" is always increasing. Also, another important thing that I believe needs to be spelled out, since most people coming from the other side may gloss over this idea, is that a developer is actually trying to do their best to satisfy the majority of users, and that, sometimes, in order to achieve that, they have little choice but to go against the wishes of a minority, no matter how adamant they believe that supporting their pet feature should be one of the developer's priorities, so that they will be in a position to devote enough of their time to properly support the majority.

So, yeah, just like LongPanda did, I too have added limitations in Rufus so as NOT to have to support workflow/features that I estimate would be way too costly to officially support. And I will reaffirm that there's no appeal here: As per the license, it's entirely the developer's choice to decide whether they want to support your pet feature or not. But the nice thing is that, since it's an Open Source application, if you really do believe that the developer is wrong, then you can just go ahead and try to prove them wrong, by creating your own fork (or finding developers who are interested in doing so) and advertising your version as "Application X, but better, because it also includes exciting feature Y!".

Now, this being said, and since it always boils down to trying to reach a compromise when both parties are willing to hear and understand where the other comes from, what I often (but not always) try to do in Rufus is that, if there's a feature that seems to be requested by a fair amount of people, but that I feel that officially trying to support is likely to end up as a big drag of my time, I may try to add it but as an unsupported cheat mode. In other words, I may add the capability to the application, but it will be disabled by default, and if people want to enable it, they can do so with the understanding that, if they do use it, and it doesn't work as they want, they are 100% on their own (which, if you look at the list of Cheat Modes from the Rufus FAQ, you will see that a large amount of these are followed with a clear "UNSUPPORTED" and "you are 100% on your own").

To conclude, I have no idea what the right way to proceed is here, but I can tell you that the GPLv3 license is pretty clear that it is entirely the developer's choice to limit or not limit what their application can do, according to what they feel is best in the long run, and that, whereas you can try to appeal their decision, there's literally zero obligation from someone who is providing you with an application entirely for free to give you what you request. And that's even more so considering that, because this is a GPL application, you are NEVER EVER stuck since you can fork your own version if you really are that unhappy. Or to bring the point home, one thing users of a free application need to realize is that, whereas there are a lot of incentives against ever releasing an application for free (no compensation for your development and support time, no real means to filter annoyances, etc.), one of the main incentive for doing so is that, because there is no paid contract with your users, there's absolutely no obligation, even an implicit one, for a developer to ever satisfy user requests and/or not decide to limit what their application can do. And for some developers, like yours truly, this is actually a big deal, because it means that, since I don't have to answer to anyone, I get to be my own Steve Jobs, and, even if the drawback is that I can't just order a bunch of paid developers to do my bidding, I don't have to compromise my vision of what I think my app should be 😄

Please sign in to comment.