[arch-general] How to install archlinux using a specific parition of usb instead of the whole usb?
Hi, I try to use a specific partition of usb to install archlinux, the following is the step: Suppose the /dev/sdc is my usb: $ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 Then I reboot my computer with the grub standalone bootloader and from within the command line of grub, I do the following: Suppose the (hd2,2) is the partition which corresponding to the /dev/sdc2, then I run the following commands: grub> set root=hd2,2 grub> chainloader /EFI/boot/bootx64.efi grub> boot But, the above step failed to boot, with the error similar to this in my ming: Failed to find the loader.efi OTOH, if I dd'ed the arch iso onto the whole usb disk like the following: $ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc Then, it will be successfully booted into the installation menu of archlinux. So I want to know whether is is possible for me to use a specific partition of usb instead of the whole usb disk for installation archlinux? Regards -- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
Hi,
I try to use a specific partition of usb to install archlinux, the following is the step:
Suppose the /dev/sdc is my usb:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 The ISO contains multiple partitions, so probably not. Why are you
On 11/5/19 8:35 PM, Hongyi Zhao via arch-general wrote: trying to do this, precisely? Maybe you want to install archlinux following the install guide, but installing to the USB partition instead of an HDD. For example, https://wiki.archlinux.org/index.php/Installing_Arch_Linux_on_a_USB_key Alternatively, you can use grub to boot an ISO *file* as a loopback device. Some people do this to create multiboot USBs. -- Eli Schwartz Bug Wrangler and Trusted User
On 11/5/19 8:41 PM, Eli Schwartz via arch-general wrote:
Hi,
I try to use a specific partition of usb to install archlinux, the following is the step:
Suppose the /dev/sdc is my usb:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 The ISO contains multiple partitions, so probably not. Why are you
On 11/5/19 8:35 PM, Hongyi Zhao via arch-general wrote: trying to do this, precisely? Maybe you want to install archlinux following the install guide, but installing to the USB partition instead of an HDD. For example,
https://wiki.archlinux.org/index.php/Installing_Arch_Linux_on_a_USB_key
Alternatively, you can use grub to boot an ISO *file* as a loopback device. Some people do this to create multiboot USBs.
As usual, Eli beat me to the punch. :) Really need to tell my MUA to fetch more frequently. As shown in my other reply, the .iso image has a partition table on it. Attempting to image this onto a partition leaves you with a partition table on a partition which is... *technically* possible, but parted/fdisk will complain about it (as they should, because we're talking about something that's "you goofed something hard or you have a REALLY technical, and probably very silly, reason to need nested partition tables"). Eli has a great suggestion about using Grub's loopback capabilities. I do this on my machines and it's saved my tuchas more than once, and highly recommend it even if you don't need it for install reasons. You can find instructions/information on it on the Arch wiki: https://wiki.archlinux.org/index.php/Multiboot_USB_drive#Using_GRUB_and_loop... and I *very* recently even wrote briefly directly about this (using SystemRescueCD instead of the Arch ISO, but I mention it): https://sysadministrivia.com/news/howto-grubrescue -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
brent s. <bts@square-r00t.net> 于2019年11月6日周三 上午9:57写道：
On 11/5/19 8:41 PM, Eli Schwartz via arch-general wrote:
Hi,
I try to use a specific partition of usb to install archlinux, the following is the step:
Suppose the /dev/sdc is my usb:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 The ISO contains multiple partitions, so probably not. Why are you
On 11/5/19 8:35 PM, Hongyi Zhao via arch-general wrote: trying to do this, precisely? Maybe you want to install archlinux following the install guide, but installing to the USB partition instead of an HDD. For example,
https://wiki.archlinux.org/index.php/Installing_Arch_Linux_on_a_USB_key
Alternatively, you can use grub to boot an ISO *file* as a loopback device. Some people do this to create multiboot USBs.
As usual, Eli beat me to the punch. :) Really need to tell my MUA to fetch more frequently.
As shown in my other reply, the .iso image has a partition table on it. Attempting to image this onto a partition leaves you with a partition table on a partition which is... *technically* possible, but parted/fdisk will complain about it (as they should, because we're talking about something that's "you goofed something hard or you have a REALLY technical, and probably very silly, reason to need nested partition tables").
Eli has a great suggestion about using Grub's loopback capabilities. I do this on my machines and it's saved my tuchas more than once, and highly recommend it even if you don't need it for install reasons. You can find instructions/information on it on the Arch wiki:
https://wiki.archlinux.org/index.php/Multiboot_USB_drive#Using_GRUB_and_loop...
and I *very* recently even wrote briefly directly about this (using SystemRescueCD instead of the Arch ISO, but I mention it):
Thanks a lot for your job. I also have tried to do the same thing with Debian's install iso, but failed to figure out the params used for ``linux'' command in grub. Just as you told on your website above, the most difficult thing using this method is to figure out the correct linux ... and initrd ... lines. While with the dd-based method, the chainloader method may be used which doesn't need to figure out the linux ... and initrd ... lines due to the chainloaded bootloader will tack over and do the corresponding things.
-- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
Eli Schwartz via arch-general <arch-general@archlinux.org> 于2019年11月6日周三 上午9:41写道：
On 11/5/19 8:35 PM, Hongyi Zhao via arch-general wrote:
Hi,
I try to use a specific partition of usb to install archlinux, the following is the step:
Suppose the /dev/sdc is my usb:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 The ISO contains multiple partitions, so probably not.
Why when using the whole usb disk, the problem will disappear?
Why are you trying to do this, precisely?
I want to use a usb disk for installation of multiple distros, say, Debian, Ubuntu, Arch, and so on. In this case, I must not using the whole usb disk for only one iso, and on the other hand, using whole usb disk for only one iso, is wasting of the usb's space, considering that we cannot use it for doing other things. Furthermore, I noticed that the dd-based method is more robust than using the iso directly with grub's loopback module. To say the least, for the Debian iso, the dd-based method can do the trick while the loopback method will fail to detect the cd-rom during the installation progress.
Maybe you want to install archlinux following the install guide, but installing to the USB partition instead of an HDD. For example,
https://wiki.archlinux.org/index.php/Installing_Arch_Linux_on_a_USB_key
This is not the aim that I want to achieve.
Alternatively, you can use grub to boot an ISO *file* as a loopback device. Some people do this to create multiboot USBs.
As I said above, this method is not so robust as the dd-based method. In detail, the most robust method for using the usb disk to installation a unix/linux OS, should be the dd-based method which using the whole usb disk. But this method has the shortcoming that it will occupy the whole usb disk with only a small iso image and prohibit us for using the usb disk to do other things at the same time.
-- Eli Schwartz Bug Wrangler and Trusted User
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
On 11/5/19 9:11 PM, Hongyi Zhao via arch-general wrote:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 The ISO contains multiple partitions, so probably not.
Why when using the whole usb disk, the problem will disappear?
As both Eli and I have both explained, because if you use the whole disk you're writing a partition table as *the partition table for the device*. If you try to write to a partition, you end up with nested partition tables. The .iso file is a *disk image*, not a *partition image*.
Why are you trying to do this, precisely?
I want to use a usb disk for installation of multiple distros, say, Debian, Ubuntu, Arch, and so on. In this case, I must not using the whole usb disk for only one iso, and on the other hand, using whole usb disk for only one iso, is wasting of the usb's space, considering that we cannot use it for doing other things. Furthermore, I noticed that the dd-based method is more robust than using the iso directly with grub's loopback module.
In what way? I do not agree with this. It's far easier to update the ISO, it's far easier to add new distributions to the bootloader (and both updating and adding new entries can even be done by regular users without granting disk reformatting permissions), etc. with grub loopback.
To say the least, for the Debian iso, the dd-based method can do the trick while the loopback method will fail to detect the cd-rom during the installation progress.
Are you using the appropriate kernel cmdline args in the menu entry? They're different from Arch's grub loopback menu entry. https://wiki.debian.org/DebianLive/MultibootISO
Alternatively, you can use grub to boot an ISO *file* as a loopback device. Some people do this to create multiboot USBs.
As I said above, this method is not so robust as the dd-based method. In detail, the most robust method for using the usb disk to installation a unix/linux OS, should be the dd-based method which using the whole usb disk. But this method has the shortcoming that it will occupy the whole usb disk with only a small iso image and prohibit us for using the usb disk to do other things at the same time.
This seems highly subjective. What makes using DD superior to a loopback? It occupies the same exact disk space as if you dd'd to a partition except requires no modifications to the host disk. Now, if you *really* want to save space, you'd extract the squashed filesystems/initrds/kernels from each ISO you want to add and create grub entries that boot those directly, but that only affords you a couple extra megabytes per distribution. However, *that is not what grub loopback is*. Grub boots an iso file *directly*, with no modifications required. I guarantee it's far more maintainable and robust than any use of dd. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
brent s. <bts@square-r00t.net> 于2019年11月6日周三 上午10:42写道：
On 11/5/19 9:11 PM, Hongyi Zhao via arch-general wrote:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 The ISO contains multiple partitions, so probably not.
Why when using the whole usb disk, the problem will disappear?
As both Eli and I have both explained, because if you use the whole disk you're writing a partition table as *the partition table for the device*. If you try to write to a partition, you end up with nested partition tables. The .iso file is a *disk image*, not a *partition image*.
Why are you trying to do this, precisely?
I want to use a usb disk for installation of multiple distros, say, Debian, Ubuntu, Arch, and so on. In this case, I must not using the whole usb disk for only one iso, and on the other hand, using whole usb disk for only one iso, is wasting of the usb's space, considering that we cannot use it for doing other things. Furthermore, I noticed that the dd-based method is more robust than using the iso directly with grub's loopback module.
In what way? I do not agree with this. It's far easier to update the ISO, it's far easier to add new distributions to the bootloader (and both updating and adding new entries can even be done by regular users without granting disk reformatting permissions), etc. with grub loopback.
To say the least, for the Debian iso, the dd-based method can do the trick while the loopback method will fail to detect the cd-rom during the installation progress.
Are you using the appropriate kernel cmdline args in the menu entry? They're different from Arch's grub loopback menu entry.
This is just what I stucked on. I failed to figure out the correct cmdline args used for linux and initrd.
Useless. This is for Debian *live* instead of Debian *install* iso, the image I use for install Debian is: http://mirrors.ustc.edu.cn/debian-cd/10.1.0/amd64/iso-dvd/debian-10.1.0-amd6...
Alternatively, you can use grub to boot an ISO *file* as a loopback device. Some people do this to create multiboot USBs.
As I said above, this method is not so robust as the dd-based method. In detail, the most robust method for using the usb disk to installation a unix/linux OS, should be the dd-based method which using the whole usb disk. But this method has the shortcoming that it will occupy the whole usb disk with only a small iso image and prohibit us for using the usb disk to do other things at the same time.
This seems highly subjective. What makes using DD superior to a loopback? It occupies the same exact disk space as if you dd'd to a partition except requires no modifications to the host disk.
Now, if you *really* want to save space, you'd extract the squashed filesystems/initrds/kernels from each ISO you want to add and create grub entries that boot those directly, but that only affords you a couple extra megabytes per distribution. However, *that is not what grub loopback is*. Grub boots an iso file *directly*, with no modifications required. I guarantee it's far more maintainable and robust than any use of dd.
-- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
You can use multiboot usb to set up multiple distro live images on one usb drive: https://aur.archlinux.org/packages/multibootusb/ I've used it, it works well. Looks like there's a build issue at the moment, but in general it works :p On Tue., 5 Nov. 2019, 22:50 Hongyi Zhao via arch-general, < arch-general@archlinux.org> wrote:
brent s. <bts@square-r00t.net> 于2019年11月6日周三 上午10:42写道：
On 11/5/19 9:11 PM, Hongyi Zhao via arch-general wrote:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 The ISO contains multiple partitions, so probably not.
Why when using the whole usb disk, the problem will disappear?
As both Eli and I have both explained, because if you use the whole disk you're writing a partition table as *the partition table for the device*. If you try to write to a partition, you end up with nested partition tables. The .iso file is a *disk image*, not a *partition
image*.
Why are you trying to do this, precisely?
I want to use a usb disk for installation of multiple distros, say, Debian, Ubuntu, Arch, and so on. In this case, I must not using the whole usb disk for only one iso, and on the other hand, using whole usb disk for only one iso, is wasting of the usb's space, considering that we cannot use it for doing other things. Furthermore, I noticed that the dd-based method is more robust than using the iso directly with grub's loopback module.
In what way? I do not agree with this. It's far easier to update the ISO, it's far easier to add new distributions to the bootloader (and both updating and adding new entries can even be done by regular users without granting disk reformatting permissions), etc. with grub loopback.
To say the least, for the Debian iso, the dd-based method can do the trick while the loopback method will fail to detect the cd-rom during the installation progress.
Are you using the appropriate kernel cmdline args in the menu entry? They're different from Arch's grub loopback menu entry.
This is just what I stucked on. I failed to figure out the correct cmdline args used for linux and initrd.
Useless. This is for Debian *live* instead of Debian *install* iso, the image I use for install Debian is:
http://mirrors.ustc.edu.cn/debian-cd/10.1.0/amd64/iso-dvd/debian-10.1.0-amd6...
Alternatively, you can use grub to boot an ISO *file* as a loopback device. Some people do this to create multiboot USBs.
As I said above, this method is not so robust as the dd-based method. In detail, the most robust method for using the usb disk to installation a unix/linux OS, should be the dd-based method which using the whole usb disk. But this method has the shortcoming that it will occupy the whole usb disk with only a small iso image and prohibit us for using the usb disk to do other things at the same time.
This seems highly subjective. What makes using DD superior to a loopback? It occupies the same exact disk space as if you dd'd to a partition except requires no modifications to the host disk.
Now, if you *really* want to save space, you'd extract the squashed filesystems/initrds/kernels from each ISO you want to add and create grub entries that boot those directly, but that only affords you a couple extra megabytes per distribution. However, *that is not what grub loopback is*. Grub boots an iso file *directly*, with no modifications required. I guarantee it's far more maintainable and robust than any use of dd.
-- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
Chris Billington via arch-general <arch-general@archlinux.org> 于2019年11月6日周三 下午12:04写道：
You can use multiboot usb to set up multiple distro live images on one usb drive:
I want to use it for booting both live and install images. It seems this tool is mainly for live images.
I've used it, it works well. Looks like there's a build issue at the moment, but in general it works :p
On Tue., 5 Nov. 2019, 22:50 Hongyi Zhao via arch-general, < arch-general@archlinux.org> wrote:
brent s. <bts@square-r00t.net> 于2019年11月6日周三 上午10:42写道：
On 11/5/19 9:11 PM, Hongyi Zhao via arch-general wrote:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 The ISO contains multiple partitions, so probably not.
Why when using the whole usb disk, the problem will disappear?
As both Eli and I have both explained, because if you use the whole disk you're writing a partition table as *the partition table for the device*. If you try to write to a partition, you end up with nested partition tables. The .iso file is a *disk image*, not a *partition
image*.
Why are you trying to do this, precisely?
I want to use a usb disk for installation of multiple distros, say, Debian, Ubuntu, Arch, and so on. In this case, I must not using the whole usb disk for only one iso, and on the other hand, using whole usb disk for only one iso, is wasting of the usb's space, considering that we cannot use it for doing other things. Furthermore, I noticed that the dd-based method is more robust than using the iso directly with grub's loopback module.
In what way? I do not agree with this. It's far easier to update the ISO, it's far easier to add new distributions to the bootloader (and both updating and adding new entries can even be done by regular users without granting disk reformatting permissions), etc. with grub loopback.
To say the least, for the Debian iso, the dd-based method can do the trick while the loopback method will fail to detect the cd-rom during the installation progress.
Are you using the appropriate kernel cmdline args in the menu entry? They're different from Arch's grub loopback menu entry.
This is just what I stucked on. I failed to figure out the correct cmdline args used for linux and initrd.
Useless. This is for Debian *live* instead of Debian *install* iso, the image I use for install Debian is:
http://mirrors.ustc.edu.cn/debian-cd/10.1.0/amd64/iso-dvd/debian-10.1.0-amd6...
Alternatively, you can use grub to boot an ISO *file* as a loopback device. Some people do this to create multiboot USBs.
As I said above, this method is not so robust as the dd-based method. In detail, the most robust method for using the usb disk to installation a unix/linux OS, should be the dd-based method which using the whole usb disk. But this method has the shortcoming that it will occupy the whole usb disk with only a small iso image and prohibit us for using the usb disk to do other things at the same time.
This seems highly subjective. What makes using DD superior to a loopback? It occupies the same exact disk space as if you dd'd to a partition except requires no modifications to the host disk.
Now, if you *really* want to save space, you'd extract the squashed filesystems/initrds/kernels from each ISO you want to add and create grub entries that boot those directly, but that only affords you a couple extra megabytes per distribution. However, *that is not what grub loopback is*. Grub boots an iso file *directly*, with no modifications required. I guarantee it's far more maintainable and robust than any use of dd.
-- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
On 11/5/19 10:50 PM, Hongyi Zhao via arch-general wrote:
Are you using the appropriate kernel cmdline args in the menu entry? They're different from Arch's grub loopback menu entry.
This is just what I stucked on. I failed to figure out the correct cmdline args used for linux and initrd.
Useless. This is for Debian *live* instead of Debian *install* iso, the image I use for install Debian is:
http://mirrors.ustc.edu.cn/debian-cd/10.1.0/amd64/iso-dvd/debian-10.1.0-amd6...
The live CD contains the installer. They're functionally the same, more or less, and are created by the same tool/use the same init. The only difference from that article is: bootoptions="findiso=$iso_path boot=live components quiet splash" would instead match the boot entry of the installer ISO. e.g. these are directly from the install ISO's grub menu ([iso]/boot/grub/grub.cfg): menuentry --hotkey=g 'Graphical install' { set background_color=black linux /install.amd/vmlinuz vga=788 --- quiet initrd /install.amd/gtk/initrd.gz } menuentry --hotkey=i 'Install' { set background_color=black linux /install.amd/vmlinuz vga=788 --- quiet initrd /install.amd/initrd.gz } (...) SO you can either: 1.) Use the following: set iso_path=path/to/debian-10.1.0-amd64-DVD-1.iso loopback loop "$iso_path" menuentry --hotkey=g 'Graphical install' { set background_color=black linux (loop)/install.amd/vmlinux vga=788 findiso=$iso_path components --- quiet initrd (loop)/install.amd/gtk/initrd.gz } menuentry --hotkey=i 'Install' { set background_color=black linux (loop)/install.amd/vmlinuz vga=788 findiso=$iso_path components --- quiet initrd /install.amd/initrd.gz } or even, 2.) Use the ISO's grub file directly: set iso_path=path/to/debian-10.1.0-amd64-DVD-1.iso loopback loop "$iso_path" menuentry 'Debian' { configfile (loop)/boot/grub/grub.cfg } But the latter is unlikely to work because again, that config is expecting to be running grub itself so the paths are probably not going to be correct. I recommend instead using a generic name for the ISOs (e.g. "debian.iso") so you don't need to edit/regenerate the grub.cfg for the USB device every time you update the ISO. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
brent s. <bts@square-r00t.net> 于2019年11月6日周三 下午12:33写道：
On 11/5/19 10:50 PM, Hongyi Zhao via arch-general wrote:
Are you using the appropriate kernel cmdline args in the menu entry? They're different from Arch's grub loopback menu entry.
This is just what I stucked on. I failed to figure out the correct cmdline args used for linux and initrd.
Useless. This is for Debian *live* instead of Debian *install* iso, the image I use for install Debian is:
http://mirrors.ustc.edu.cn/debian-cd/10.1.0/amd64/iso-dvd/debian-10.1.0-amd6...
The live CD contains the installer. They're functionally the same, more or less, and are created by the same tool/use the same init.
The only difference from that article is:
bootoptions="findiso=$iso_path boot=live components quiet splash"
would instead match the boot entry of the installer ISO. e.g. these are directly from the install ISO's grub menu ([iso]/boot/grub/grub.cfg):
menuentry --hotkey=g 'Graphical install' { set background_color=black linux /install.amd/vmlinuz vga=788 --- quiet initrd /install.amd/gtk/initrd.gz } menuentry --hotkey=i 'Install' { set background_color=black linux /install.amd/vmlinuz vga=788 --- quiet initrd /install.amd/initrd.gz } (...)
SO you can either:
1.) Use the following:
set iso_path=path/to/debian-10.1.0-amd64-DVD-1.iso loopback loop "$iso_path"
menuentry --hotkey=g 'Graphical install' { set background_color=black linux (loop)/install.amd/vmlinux vga=788 findiso=$iso_path components --- quiet
IMO, this is the most difficult thing to figure out a workable menuentry, I mean, the follownig code inserted here: findiso=$iso_path components And from where can I find the full manual for this? I have inspected the following webpage: https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt And I cannot find out the parameters/arguments used here: `findiso' and `components'.
initrd (loop)/install.amd/gtk/initrd.gz } menuentry --hotkey=i 'Install' { set background_color=black linux (loop)/install.amd/vmlinuz vga=788 findiso=$iso_path components --- quiet initrd /install.amd/initrd.gz }
or even, 2.) Use the ISO's grub file directly:
set iso_path=path/to/debian-10.1.0-amd64-DVD-1.iso loopback loop "$iso_path"
menuentry 'Debian' { configfile (loop)/boot/grub/grub.cfg
No, this is not the initial grub.cfg used by the iso when running in the efi mode which is the de-facto nowsdays. The first grub.cfg used by the iso is: /EFI/debian/grub.cfg This file will then source all of the other grub.cfg, including the one in /boot/grub/grub.cfg, which is the last grub.cfg in the chain.
}
But the latter is unlikely to work because again, that config is expecting to be running grub itself so the paths are probably not going to be correct.
I recommend instead using a generic name for the ISOs (e.g. "debian.iso") so you don't need to edit/regenerate the grub.cfg for the USB device every time you update the ISO.
-- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
On 11/6/19 12:01 AM, Hongyi Zhao via arch-general wrote:
menuentry --hotkey=g 'Graphical install' { set background_color=black linux (loop)/install.amd/vmlinux vga=788 findiso=$iso_path components --- quiet
IMO, this is the most difficult thing to figure out a workable menuentry, I mean, the follownig code inserted here:
findiso=$iso_path components
And from where can I find the full manual for this? I have inspected the following webpage:
https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
And I cannot find out the parameters/arguments used here: `findiso' and `components'.
"findiso" and "components" are unique to Debian's initialization scripts. The ones at https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt are generic ones that the *kernel* uses, but others are used by the OS itself during initialization. They're both passed to /proc/cmdline (because it's the only reliable way of passing boot-time parameters to runtime kernel operations and the initrd/initramfs). "findiso" is documented here: https://manpages.debian.org/testing/live-boot-doc/live-boot.7.en.html As for "components", I have no idea what it does. You can extract the ISO's initrd and check the init system in there, though, to find out.
No, this is not the initial grub.cfg used by the iso when running in the efi mode which is the de-facto nowsdays. The first grub.cfg used by the iso is:
/EFI/debian/grub.cfg
This file will then source all of the other grub.cfg, including the one in /boot/grub/grub.cfg, which is the last grub.cfg in the chain.
All that does is call other cfgs and do insmods. Follow the "source" directives and you will find that, yes, the one I mentioned is the menu config (the one you actually want, because you want to create *menu entries*) that is used by the Debian ISO. You *definitely* will not be able to use the "linking"/parent configs because they refer to paths inside the Debian ISO, not your USB drive. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
brent s. <bts@square-r00t.net> 于2019年11月6日周三 下午1:15写道：
On 11/6/19 12:01 AM, Hongyi Zhao via arch-general wrote:
menuentry --hotkey=g 'Graphical install' { set background_color=black linux (loop)/install.amd/vmlinux vga=788 findiso=$iso_path components --- quiet
IMO, this is the most difficult thing to figure out a workable menuentry, I mean, the follownig code inserted here:
findiso=$iso_path components
And from where can I find the full manual for this? I have inspected the following webpage:
https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
And I cannot find out the parameters/arguments used here: `findiso' and `components'.
"findiso" and "components" are unique to Debian's initialization scripts. The ones at https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt are generic ones that the *kernel* uses, but others are used by the OS itself during initialization. They're both passed to /proc/cmdline (because it's the only reliable way of passing boot-time parameters to runtime kernel operations and the initrd/initramfs).
"findiso" is documented here: https://manpages.debian.org/testing/live-boot-doc/live-boot.7.en.html
As for "components", I have no idea what it does. You can extract the ISO's initrd and check the init system in there, though, to find out.
No, this is not the initial grub.cfg used by the iso when running in the efi mode which is the de-facto nowsdays. The first grub.cfg used by the iso is:
/EFI/debian/grub.cfg
This file will then source all of the other grub.cfg, including the one in /boot/grub/grub.cfg, which is the last grub.cfg in the chain.
All that does is call other cfgs and do insmods. Follow the "source" directives and you will find that, yes, the one I mentioned is the menu config (the one you actually want, because you want to create *menu entries*) that is used by the Debian ISO.
You *definitely* will not be able to use the "linking"/parent configs because they refer to paths inside the Debian ISO, not your USB drive.
Ok, again I promote the dd-based method here. If use the dd-based method, than just do the following: # changing the ($root)/EFI/debian/grub.cfg as follows to make it more robust: search --label --set=root 'Debian 10.1.0 amd64 1' set prefix=($root)/boot/grub source $prefix/x86_64-efi/grub.cfg Repack the iso with above changed file and then dd it to usb's arbitrary partition, and do the following: grub> set root=(root-of-dd-iso-on-usb-partition) grub> set prefix=($root)/boot/grub grub> chainloader /EFI/boot/grubx64.efi grub> boot This will let all of the grub.cfg's invoked in order and obtain a complete same effect with the one done by burning-on-dvd. But, this method is not so convenient due change and repack the iso.
-- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
brent s. <bts@square-r00t.net> 于2019年11月6日周三 下午12:33写道：
On 11/5/19 10:50 PM, Hongyi Zhao via arch-general wrote:
Are you using the appropriate kernel cmdline args in the menu entry? They're different from Arch's grub loopback menu entry.
This is just what I stucked on. I failed to figure out the correct cmdline args used for linux and initrd.
Useless. This is for Debian *live* instead of Debian *install* iso, the image I use for install Debian is:
http://mirrors.ustc.edu.cn/debian-cd/10.1.0/amd64/iso-dvd/debian-10.1.0-amd6...
The live CD contains the installer. They're functionally the same, more or less, and are created by the same tool/use the same init.
The only difference from that article is:
bootoptions="findiso=$iso_path boot=live components quiet splash"
would instead match the boot entry of the installer ISO. e.g. these are directly from the install ISO's grub menu ([iso]/boot/grub/grub.cfg):
menuentry --hotkey=g 'Graphical install' { set background_color=black linux /install.amd/vmlinuz vga=788 --- quiet initrd /install.amd/gtk/initrd.gz } menuentry --hotkey=i 'Install' { set background_color=black linux /install.amd/vmlinuz vga=788 --- quiet initrd /install.amd/initrd.gz } (...)
SO you can either:
1.) Use the following:
set iso_path=path/to/debian-10.1.0-amd64-DVD-1.iso loopback loop "$iso_path"
menuentry --hotkey=g 'Graphical install' { set background_color=black linux (loop)/install.amd/vmlinux vga=788 findiso=$iso_path components --- quiet initrd (loop)/install.amd/gtk/initrd.gz } menuentry --hotkey=i 'Install' { set background_color=black linux (loop)/install.amd/vmlinuz vga=788 findiso=$iso_path components --- quiet initrd /install.amd/initrd.gz }
or even, 2.) Use the ISO's grub file directly:
set iso_path=path/to/debian-10.1.0-amd64-DVD-1.iso loopback loop "$iso_path"
menuentry 'Debian' { configfile (loop)/boot/grub/grub.cfg
I still not so clear why the chainloader method cannot be used for loopback device, ie, chainloader (loop)/EFI/boot/grubx64.efi I have tried the above but failed.
}
But the latter is unlikely to work because again, that config is expecting to be running grub itself so the paths are probably not going to be correct.
I recommend instead using a generic name for the ISOs (e.g. "debian.iso") so you don't need to edit/regenerate the grub.cfg for the USB device every time you update the ISO.
-- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
brent s. <bts@square-r00t.net> 于2019年11月6日周三 下午12:33写道：
On 11/5/19 10:50 PM, Hongyi Zhao via arch-general wrote:
Are you using the appropriate kernel cmdline args in the menu entry? They're different from Arch's grub loopback menu entry.
This is just what I stucked on. I failed to figure out the correct cmdline args used for linux and initrd.
Useless. This is for Debian *live* instead of Debian *install* iso, the image I use for install Debian is:
http://mirrors.ustc.edu.cn/debian-cd/10.1.0/amd64/iso-dvd/debian-10.1.0-amd6...
The live CD contains the installer. They're functionally the same, more or less, and are created by the same tool/use the same init.
The only difference from that article is:
bootoptions="findiso=$iso_path boot=live components quiet splash"
would instead match the boot entry of the installer ISO. e.g. these are directly from the install ISO's grub menu ([iso]/boot/grub/grub.cfg):
menuentry --hotkey=g 'Graphical install' { set background_color=black linux /install.amd/vmlinuz vga=788 --- quiet initrd /install.amd/gtk/initrd.gz } menuentry --hotkey=i 'Install' { set background_color=black linux /install.amd/vmlinuz vga=788 --- quiet initrd /install.amd/initrd.gz } (...)
SO you can either:
1.) Use the following:
set iso_path=path/to/debian-10.1.0-amd64-DVD-1.iso loopback loop "$iso_path"
menuentry --hotkey=g 'Graphical install' { set background_color=black linux (loop)/install.amd/vmlinux vga=788 findiso=$iso_path components --- quiet
I tried with this settings, but still failed with the following error: No Common CD-ROM drive was detected. So, it seems these options are only for live images -- ie, which uses squshfs to store the os image.
initrd (loop)/install.amd/gtk/initrd.gz } menuentry --hotkey=i 'Install' { set background_color=black linux (loop)/install.amd/vmlinuz vga=788 findiso=$iso_path components --- quiet initrd /install.amd/initrd.gz }
or even, 2.) Use the ISO's grub file directly:
set iso_path=path/to/debian-10.1.0-amd64-DVD-1.iso loopback loop "$iso_path"
menuentry 'Debian' { configfile (loop)/boot/grub/grub.cfg }
But the latter is unlikely to work because again, that config is expecting to be running grub itself so the paths are probably not going to be correct.
I recommend instead using a generic name for the ISOs (e.g. "debian.iso") so you don't need to edit/regenerate the grub.cfg for the USB device every time you update the ISO.
-- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
brent s. <bts@square-r00t.net> 于2019年11月6日周三 上午10:42写道：
On 11/5/19 9:11 PM, Hongyi Zhao via arch-general wrote:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 The ISO contains multiple partitions, so probably not.
Why when using the whole usb disk, the problem will disappear?
As both Eli and I have both explained, because if you use the whole disk you're writing a partition table as *the partition table for the device*. If you try to write to a partition, you end up with nested partition tables. The .iso file is a *disk image*, not a *partition image*.
Why are you trying to do this, precisely?
I want to use a usb disk for installation of multiple distros, say, Debian, Ubuntu, Arch, and so on. In this case, I must not using the whole usb disk for only one iso, and on the other hand, using whole usb disk for only one iso, is wasting of the usb's space, considering that we cannot use it for doing other things. Furthermore, I noticed that the dd-based method is more robust than using the iso directly with grub's loopback module.
In what way?
See the following partition method and settings on my usb stick: werner@debian-01:~$ sudo sfdisk -l /dev/sdc Disk /dev/sdc: 114.6 GiB, 123010547712 bytes, 240254976 sectors Disk model: Ultra USB 3.0 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BB18A52C-1382-4003-B6CF-CE137E913145 Device Start End Sectors Size Type /dev/sdc1 2048 6143 4096 2M BIOS boot /dev/sdc2 6144 210943 204800 100M EFI System /dev/sdc3 210944 164050943 163840000 78.1G Linux filesystem /dev/sdc4 188954624 191002623 2048000 1000M Linux filesystem /dev/sdc5 191002624 199194623 8192000 3.9G Linux filesystem /dev/sdc6 199194624 213530623 14336000 6.9G Linux filesystem /dev/sdc7 213530624 215578623 2048000 1000M Linux filesystem /dev/sdc8 215578624 218650623 3072000 1.5G Linux filesystem /dev/sdc9 218650624 223361023 4710400 2.3G Linux filesystem /dev/sdc10 223361024 234010623 10649600 5.1G Microsoft basic data Some explains: sdc1: bios_grub for grub booting with gpt sdc2: EFI diretory sdc3: boot diretory sdc4- : dd-based iso images
I do not agree with this. It's far easier to update the ISO, it's far easier to add new distributions to the bootloader (and both updating and adding new entries can even be done by regular users without granting disk reformatting permissions), etc. with grub loopback.
To say the least, for the Debian iso, the dd-based method can do the trick while the loopback method will fail to detect the cd-rom during the installation progress.
Are you using the appropriate kernel cmdline args in the menu entry? They're different from Arch's grub loopback menu entry.
https://wiki.debian.org/DebianLive/MultibootISO
Alternatively, you can use grub to boot an ISO *file* as a loopback device. Some people do this to create multiboot USBs.
As I said above, this method is not so robust as the dd-based method. In detail, the most robust method for using the usb disk to installation a unix/linux OS, should be the dd-based method which using the whole usb disk. But this method has the shortcoming that it will occupy the whole usb disk with only a small iso image and prohibit us for using the usb disk to do other things at the same time.
This seems highly subjective. What makes using DD superior to a loopback? It occupies the same exact disk space as if you dd'd to a partition except requires no modifications to the host disk.
Now, if you *really* want to save space, you'd extract the squashed filesystems/initrds/kernels from each ISO you want to add and create grub entries that boot those directly, but that only affords you a couple extra megabytes per distribution. However, *that is not what grub loopback is*. Grub boots an iso file *directly*, with no modifications required. I guarantee it's far more maintainable and robust than any use of dd.
-- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
-- Hongsheng Zhao <hongyi.zhao@gmail.com> Institute of Semiconductors, Chinese Academy of Sciences GnuPG DSA: 0xD108493
On 11/5/19 8:35 PM, Hongyi Zhao via arch-general wrote:
Hi,
I try to use a specific partition of usb to install archlinux, the following is the step:
Suppose the /dev/sdc is my usb:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2
Then I reboot my computer with the grub standalone bootloader and from within the command line of grub, I do the following:
Suppose the (hd2,2) is the partition which corresponding to the /dev/sdc2, then I run the following commands:
grub> set root=hd2,2 grub> chainloader /EFI/boot/bootx64.efi grub> boot
But, the above step failed to boot, with the error similar to this in my ming:
Failed to find the loader.efi
OTOH, if I dd'ed the arch iso onto the whole usb disk like the following:
$ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc
Then, it will be successfully booted into the installation menu of archlinux. So I want to know whether is is possible for me to use a specific partition of usb instead of the whole usb disk for installation archlinux?
Regards
The biggest issue is this doesn't work because the ISO file *already has* partitions/a partition table on it (which is what lets you DD directly onto a block device rather than requiring partitioning of the target device first): [bts@cylon tmp]$ sudo kpartx -l archlinux-2019.11.01-x86_64.iso Warning: Disk has a valid GPT signature but invalid PMBR. Assuming this disk is *not* a GPT disk anymore. Use gpt kernel option to override. Use GNU Parted to correct disk. loop0p1 : 0 1300480 /dev/loop0 0 loop0p2 : 0 131072 /dev/loop0 164 [bts@cylon tmp]$ sfdisk -l archlinux-2019.11.01-x86_64.iso Disk archlinux-2019.11.01-x86_64.iso: 635 MiB, 665845760 bytes, 1300480 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x65cc13ea Device Boot Start End Sectors Size Id Type archlinux-2019.11.01-x86_64.iso1 * 0 1300479 1300480 635M 0 Empty archlinux-2019.11.01-x86_64.iso2 164 131235 131072 64M ef EFI (FAT-12/16/32) [bts@cylon tmp]$ parted --script archlinux-2019.11.01-x86_64.iso -- print Model: (file) Disk /tmp/archlinux-2019.11.01-x86_64.iso: 666MB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 2 84.0kB 67.2MB 67.1MB primary fat16 esp -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
participants (4)
-
brent s.
-
Chris Billington
-
Eli Schwartz
-
Hongyi Zhao