Re: Install Debian 12.5 on QNAP TS-210
On 24.04.2024 19:49, David Hörnlund wrote: Hi debian-user, I have an old QNAP TS-210 that would continue to be useful for me. If it is still possible to use it with the latest Debian Stable. There is a webpage at https://www.cyrius.com/debian/kirkwood/qnap/ts-219/ That have instruktions on how to install Debian 10 on this device. Can I install Debian 10 on the device today still or is that version not available anymore? Are the .Deb packades still on the mirrors? If the files are available will it install or is it blocked somehow? If I follow the steps on the webpage and do what the author suggests: My recommendation is for the third option; Arnaud Mouiche has created a script that re-configures the partition layout. Arnaud Mouiche's method has been used by many users with success. Will Debian 12 have the necessary packades and cpu architecture support to allow Debian 12 to boot and run. But also receive updates and new software configured for the QNAP TS-210? According to the author Debian dropped the support for this device when support ended for Debian 10. The Marvel ARM SoC IC is still supported by kernel [1], so the only reason support was ended at Debian 10 is indeed because of limited space on the flash device. I don't see why it shouldn't work, if information on Arnaud Mouiche's Github page [2] is correct. If I had this device I'd definitely gave it a try. But you have to be careful, since the whole process requires re-flashing custom firmware, you might end up with bricked device. Another option is to simply continue to use QNAP internal OS. [1] https://www.kernel.org/doc/html/v6.1/arm/marvell.html#kirkwood-family [2] https://github.com/amouiche/qnap_mtd_resize_for_bullseye -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Re: install Kernel and GRUB in chroot.
On 05/02/2024 17:40, Dmitry wrote: > It would not work with secure boot Yes. But secure boot is usually turned off. It is a standard advice during Linux installation. That advice may be standard for distributions that do not provide signed shim and grub. Likely it is applicable for Arch and derivatives. Debian supports installation with enabled secure boot. At first I suspected that you enrolled your own MOK and maybe even wiped out Microsoft keys. Perhaps you may get encrypted /boot in Debian similar to what you have in Manjaro, but certainly it is not default configuration.
Re: install Kernel and GRUB in chroot.
On Mon, 2024-02-05 at 17:40 +0700, Dmitry wrote: > > But secure boot is usually turned off. It is a standard advice during > Linux > installation. > Will probably be increasingly common though, I've got a Microsoft Surface Laptop that works fine with Debian, but if you switch off secure boot, it displays some big red scary warning screen before the bootloader. /ralph
Re: install Kernel and GRUB in chroot.
> It would not work with secure boot Yes. But secure boot is usually turned off. It is a standard advice during Linux installation.
Re: install Kernel and GRUB in chroot.
sudo -i Thank you! I am unsure what UUID you mean. At Manjaro: grubx64.efi is at the sdb1 - EFI vfat /dev/sdb1 grub.cfg is at the sdb2 - crypto_LUKS /dev/sdb2 grubx64.efi contains data UUID=""a8...b7" of /dev/sdb2 which is TYPE="crypto_LUKS". `blkid` output: /dev/sdb2: UUID="a8...b7" TYPE="crypto_LUKS" PARTUUID="8...5" `strings /boot/efi/EFI/Manjaro/grub64x.efi` output: cryptomount -u a8...b7 (cryptouuid/a8...b7)/boot/grub I have a Manjaro installed, and what to migrate to Debian. That involves exploration of Booting order. In the Manjaro GRUB installation mounting point for ESP (sdb1) is: /boot/efi And the grub.cfg is /boot/grub/grub.cfg The grub.cfg located at the crypto partition sdb2. Manjaro has different GRUB installation scheme from Debian.
Re: install Kernel and GRUB in chroot.
On 03/02/2024 22:32, Dmitry wrote: 2. sudo bash sudo -i 3. cd /boot/efi/EFI/Mangaro 4. strings grubx64.efi 5. And at the output of strings there is UUID and /boot/grub. I am unsure what UUID you mean. Summary: GRUB installation not only involves configuration of text files, but also it involves generating data in binary grubx64.efi. It would not work with secure boot md5sum /boot/efi/EFI/debian/grubx64.efi /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed 62ff1ee5b75b4565f609043c4b1da759 /boot/efi/EFI/debian/grubx64.efi 62ff1ee5b75b4565f609043c4b1da759 /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed
Re: install Kernel and GRUB in chroot.
Tim Woodall composed on 2024-02-03 21:25 (UTC): > Max Nikulin wrote: >> It seems secure boot is disabled in your case, so I am wondering why you do >> not boot xen.efi directly. > Because the NVRAM is extremely tempremental. Not in my experience. I recognized long ago that WRT non-removable media, only one bootloader per machine is required, and pretty well stuck to having only one active, or at all, no matter how many FOSS operating systems or media I have installed. The Grubs I have used are not picky about whose kernel or initrd they are called to load. With only one bootloader installed, retouching NVRAM isn't often required, and there needn't be much in it to scramble. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: install Kernel and GRUB in chroot.
On Sat, 3 Feb 2024, Max Nikulin wrote: It seems secure boot is disabled in your case, so I am wondering why you do not boot xen.efi directly. Because the NVRAM is extremely tempremental. Most updates fail, or worse, corrupt it to the point it's hard to get anything to boot. Additionally, there was a bug in an older version of xen that caused a kernel oops if wifi networking was started. So I wanted to start vanilla debian and I don't dare touch the NVRAM again (or the bios) until I absolutely have to. I don't remember for certain now but I might be booting using bootx86.efi (which is a copy of grubx64.efi) It's an old laptop but it still works well for me.
Re: install Kernel and GRUB in chroot.
Main question is resolved. GRUB knows how to reach grub.cfg because grubx64.efi binary has the UUID and path to grub configurations. 1. sudo blkid; 2. sudo bash 3. cd /boot/efi/EFI/Mangaro 4. strings grubx64.efi 5. And at the output of strings there is UUID and /boot/grub. Summary: GRUB installation not only involves configuration of text files, but also it involves generating data in binary grubx64.efi.
Re: install Kernel and GRUB in chroot.
On 03/02/2024 02:15, Tim Woodall wrote: $ cat /boot/efi/EFI/XEN/xen.cfg [...] I'd be interested if there's a way to tell grubx64.efi to look for a particular partition UUID. An example of such grub.cfg from EFI/debian has been posted already in this thread https://lists.debian.org/msgid-search/20240201200846.0bb82...@dorfdsl.de Frankly speaking, I am unsure concerning your configuration. Perhaps the following may make it more clear efibootmgr -v find /boot/efi | sort It seems secure boot is disabled in your case, so I am wondering why you do not boot xen.efi directly.
Re: install Kernel and GRUB in chroot.
On 03/02/2024 02:51, Thomas Schmitt wrote: Max Nikulin wrote: Just copy files from LiveCD (it should have EFI/Boot/bootx64.efi) to the ESP partition on the USB stick. The /EFI/boot directory of a bootable Debian ISO usually does not contain the full GRUB equipment for EFI. Important parts of an amd64 Live ISO are in /boot/grub. Certainly. And grubx64.efi in EFI/Boot of a live media behaves a bit differently from one in EFI/debian of a regular install since in the former case it relies on boot/grub residing on the same partition. My point was to copy *files* to the pre-partitioned drive, not a whole image to the whole block device. I had a hope that the topic starter is aware of the recommended way to create a bootable USB stick using dd (or cp, etc.). I usually copy files to existing single FAT partition on USB drives having msdos partition table (as they are shipped). It requires additional actions to setup syslinux for the sake of legacy boot, but it leaves enough space to put some additional files while the boot drive is prepared or during live session (requires remounting as rw). UEFI boot relies on files and their specific layouts, not on specific block addresses.
Re: install Kernel and GRUB in chroot.
On 02/02/24 at 15:12, Dmitry wrote: Going to read carefully. https://www.debian.org/releases/buster/amd64/ch04s03.en.html Interesting that Buster has more documentation than current release. Nope, maybe you gave a quick read, the release notes of the current release ¹ are exhaustive. If you need to go deeper, a link ² to the wiki it's published in that page. Kind regards, ¹ https://www.debian.org/releases/bookworm/amd64/ch04s03.en.html ² https://wiki.debian.org/DebianInstaller/CreateUSBMedia -- Franco Martelli
Re: install Kernel and GRUB in chroot.
Hi, Dmitry wrote: > Yep. `dd` copy partitions table. Amazing. Not so amazing after you realize that a partition table is just data on the storage medium and not some special property of the storage device. dd copies data. If these data contain a partition table and get copied to the right place on the storage medium, the partition table will be recognized by EFI and Linux. > applies no 'intelligence' to the operation. This describes it very well. Sometimes dumb is good. Sometimes not. Initially you stated in https://lists.debian.org/debian-user/2024/02/msg8.html >...> I need to prepare that system for booting. >...> 1. Install Kernel. >...> 2. Install GRUB and Configure. >...> 3. Add changes to UEFI to start booting. dd-ing a bootable Debian ISO will not do what you describe. Assumed the ISO is prepared for booting from USB stick, you will get a bootable Live or an installer system. At least ISOs for i386, amd64, and arm64 should be prepared for that. If it is not ready for booting from USB stick, it will be just a storage with a mountable filesystem and Debian files in it. Max Nikulin wrote: > > Just copy files from LiveCD (it should have EFI/Boot/bootx64.efi) > > to the ESP partition on the USB stick. The /EFI/boot directory of a bootable Debian ISO usually does not contain the full GRUB equipment for EFI. Important parts of an amd64 Live ISO are in /boot/grub. The programs in /EFI/boot are specialized on convincing Secure Boot and on finding the ISO filesystem with /boot/grub in it. (Actually those are copies of the EFI boot partition files. The boot partition is a FAT filesystem image file inside the ISO named /boot/grub/efi.img .) Tim Woodall wrote: > > I'm not exactly sure what you're doing. I join this statement. :)) Do you want a normal changeable Debian system installation or do you want a Live system with its immutable core and maybe some partition where you can store files ? (Just curiosity of mine. Possibly i could not help much with chroot questions anyway.) Have a nice day :) Thomas
Re: install Kernel and GRUB in chroot.
On Thu, 1 Feb 2024, Marco Moock wrote:
Am 01.02.2024 um 19:20:01 Uhr schrieb Tim Woodall:
$ cat /boot/efi/EFI/XEN/xen.cfg
[global]
default=debian
[debian]
options=console=vga smt=true
kernel=vmlinuz root=/dev/mapper/vg--dirac-root ro quiet
ramdisk=initrd.img
menuentry "Xen EFI NVME" {
insmod part_gpt
insmod search_fs_uuid
insmod chain
#set root=(hd1,gpt1)
search --no-floppy --fs-uuid --set=root C057-BC13
chainloader (hd1,gpt1)/EFI/XEN/xen.efi
}
Then this file tells the boot loader about the /boot or / partition.
Is that the Xen virtualization software?
The NVRAM is configured to boot:
/boot/efi/EFI/debian/grubx64.efi
That then hunts for grub.cfg. I believe it finds the first grub.cfg -
which has caused me issues in the past where I've had a legacy partition
on the disk that I'd forgotten about but the efi application sees. I'd
be interested if there's a way to tell grubx64.efi to look for a
particular partition UUID.
That menuentry above then tells efi to chainload the xen.efi
application. This is all in efi land.
That then reads xen.cfg and boots the kernel and initrd defined in that
file.
Re: install Kernel and GRUB in chroot.
On Sat, Feb 03, 2024 at 01:17:05AM +0700, Dmitry wrote: > > Just copy files from LiveCD (it should have EFI/Boot/bootx64.efi) to the > ESP partition on the USB stick. > > As I understand right now `dd` command applied to a device will copy all > information including partitions table. Thus: Actually, cp (or even, horrors ;-) cat do the same. One advantage of dd is... > dd if=debian-xx.iso of=/dev/sdb bs=4M status=progress; sync ...this "status=progress". The other is "oflag=sync": for bigger sticks (and if you have tons of RAM) this last "sync" could take a long while, without giving you feedback of what's happening. And the third one (which it shares with cp but not with cat) is that sudo won't work in "sudo cat foo.img > /dev/bar" (unless you already are root, but that'd be cheating ;-) Cheers -- t signature.asc Description: PGP signature
Re: install Kernel and GRUB in chroot.
> Just copy files from LiveCD (it should have EFI/Boot/bootx64.efi) to the ESP partition on the USB stick. Yep. `dd` copy partitions table. Amazing. ``` dd will simply recreate the old partition scheme, as it is a bitwise copy & applies no 'intelligence' to the operation. ``` https://askubuntu.com/a/847533
Re: install Kernel and GRUB in chroot.
> Just copy files from LiveCD (it should have EFI/Boot/bootx64.efi) to the ESP partition on the USB stick. As I understand right now `dd` command applied to a device will copy all information including partitions table. Thus: dd if=debian-xx.iso of=/dev/sdb bs=4M status=progress; sync Would just create a copy of device, with FileSystem and PartitionsTable.
Re: install Kernel and GRUB in chroot.
On Fri 02 Feb 2024 at 21:12:30 (+0700), Dmitry wrote: > Going to read carefully. > > https://www.debian.org/releases/buster/amd64/ch04s03.en.html > > Interesting that Buster has more documentation than current release. It appears the balance has now been spun off into a wiki page, at https://wiki.debian.org/DebianInstaller/CreateUSBMedia Cheers, David.
Re: install Kernel and GRUB in chroot.
On 02/02/2024 21:06, Dmitry wrote: Need additional research what to do with a FlashStick with several partitions to make a LiveCD from it. Just copy files from LiveCD (it should have EFI/Boot/bootx64.efi) to the ESP partition on the USB stick.
Re: install Kernel and GRUB in chroot.
Going to read carefully. https://www.debian.org/releases/buster/amd64/ch04s03.en.html Interesting that Buster has more documentation than current release.
Re: install Kernel and GRUB in chroot.
> Do you want to install the OS on it? Eventually no, I do not want OS on the Flash Stick. The Flash Stick is only a testing place. I want OS at the SSD. Now I am wondering how to prepare the Flash Stick to write LiveImage on it. Because I already created a GPT table on that Flash and use debootstrap. Looks like need to create a new parition and copy LiveImage there. Need additional research what to do with a FlashStick with several partitions to make a LiveCD from it. > Do you want an encrypted system? No. I do not need this abstraction layer now.
Re: install Kernel and GRUB in chroot.
Am 02.02.2024 schrieb Dmitry : > I want OS at the SSD. Then the ESP should be on that SSD too.
Re: install Kernel and GRUB in chroot.
Max Nikulin schrieb: On a *removable* drive EFI/Boot/bootx64.efi (that is actually /usr/lib/shim/shimx64.efi.signed that loads grubx64.efi) may allow to boot without modification of boot entries in NVRAM. Yes, UEFI can (and must be able) to boot from a device without a boot entry in the UEFI. Otherwise you wouldn't be able to install an OS. You can boot such a device by simply selecting the device in the UEFI boot manager. Often it shows the model number of the device. Likely it is implementation-dependent whether a drive with GPT partition table is considered as a removable. For regular (internal) drives UEFI requires GPT. MBR should also work.
Re: install Kernel and GRUB in chroot.
On 02/02/2024 01:46, Dmitry wrote: 3. Now I want to boot using that Flash. 1. ESP is a partition that stores GRUB Binary. /boot/EFI/Name/grub64.eif On a *removable* drive EFI/Boot/bootx64.efi (that is actually /usr/lib/shim/shimx64.efi.signed that loads grubx64.efi) may allow to boot without modification of boot entries in NVRAM. Likely it is implementation-dependent whether a drive with GPT partition table is considered as a removable. For regular (internal) drives UEFI requires GPT. I do not suggest you to use msdos partition table that might be suitable for live media, not for installation with multiple partitions including Linux native file systems. 3. At the system partition there is a /boot/grub/grub.cfg There are 2 grub.cfg: for ESP and for /boot
Re: install Kernel and GRUB in chroot.
Am 01.02.2024 um 19:20:01 Uhr schrieb Tim Woodall:
> $ cat /boot/efi/EFI/XEN/xen.cfg
> [global]
> default=debian
>
> [debian]
> options=console=vga smt=true
> kernel=vmlinuz root=/dev/mapper/vg--dirac-root ro quiet
> ramdisk=initrd.img
>
>
> menuentry "Xen EFI NVME" {
> insmod part_gpt
> insmod search_fs_uuid
> insmod chain
> #set root=(hd1,gpt1)
> search --no-floppy --fs-uuid --set=root C057-BC13
> chainloader (hd1,gpt1)/EFI/XEN/xen.efi
> }
Then this file tells the boot loader about the /boot or / partition.
Is that the Xen virtualization software?
--
Gruß
Marco
Spam und Werbung bitte an ichschickerekl...@cartoonies.org
Re: install Kernel and GRUB in chroot.
On Thu, 1 Feb 2024, Marco Moock wrote:
Am 02.02.2024 um 01:46:06 Uhr schrieb Dmitry:
2. ==>BAM<== some how that binary knows the system partition.
That information is on the EFI partition, where the GRUB bootloader
binary also resides.
root@ryz:/boot/efi/EFI# cat /boot/efi/EFI/debian/grub.cfg
search.fs_uuid 5b8b669d-xyz root hd0,gpt2 #boot partition
set prefix=($root)'/grub'
configfile $prefix/grub.cfg
root@ryz:/boot/efi/EFI#
If that information is loaded, the kernel can be loaded from the boot
partition.
Are you sure that file does anything? I don't have one
drwxr-xr-x 2 root root 4096 Dec 31 2017 .
drwxr-xr-x 6 root root 4096 Dec 25 2019 ..
-rwxr-xr-x 1 root root 163840 Sep 11 2022 grubx64.efi
This finds my boot partition and then chainloads the XEN efi binary
which does have some config.
/boot/efi/EFI/XEN:
total 38204
drwxr-xr-x 2 root root 4096 May 5 2023 .
drwxr-xr-x 6 root root 4096 Dec 25 2019 ..
-rwxr-xr-x 1 root root 31132473 Aug 12 08:34 initrd.img
-rwxr-xr-x 1 root root 5283136 Aug 12 08:34 vmlinuz
-rwxr-xr-x 1 root root 138 May 5 2023 xen.cfg
-rwxr-xr-x 1 root root 2687456 Jun 20 2021 xen.efi
$ cat /boot/efi/EFI/XEN/xen.cfg
[global]
default=debian
[debian]
options=console=vga smt=true
kernel=vmlinuz root=/dev/mapper/vg--dirac-root ro quiet
ramdisk=initrd.img
menuentry "Xen EFI NVME" {
insmod part_gpt
insmod search_fs_uuid
insmod chain
#set root=(hd1,gpt1)
search --no-floppy --fs-uuid --set=root C057-BC13
chainloader (hd1,gpt1)/EFI/XEN/xen.efi
}
Re: install Kernel and GRUB in chroot.
On Fri, 2 Feb 2024, Dmitry wrote: Hi Tim. The community is so kind. So. I'm not exactly sure what you're doing. Understand how GRUB works, to boot myself. 1. Trying to install Debian on the Flash. 2. Use it by the Debootstrap. 3. Now I want to boot using that Flash. Looks like a caught the thread. 1. ESP is a partition that stores GRUB Binary. /boot/EFI/Name/grub64.eif 2. ==>BAM<== some how that binary knows the system partition. because grub64.efi understands the disk layout and looks for it. You can build your own I'm not giving any guarantees - look at the date on this file: $ ls -al test-uefi -rw-r--r-- 1 tim tim 341 Dec 31 2018 test-uefi $ cat test-uefi grub-mkimage -o bootx64.efi -p /EFI/BOOT -O x86_64-efi \ fat iso9660 part_gpt part_msdos \ normal boot echo linux configfile loopback chain \ efifwsetup efi_gop efi_uga \ ls search search_label search_fs_uuid search_fs_file \ gfxterm gfxterm_background gfxterm_menu test all_video loadenv \ exfat ext2 lvm mdraid09 mdraid1x diskfilter but that probably builds (or once worked) a .efi application that will successfully boot a system by searching for grub.cfg. I don't remember the details... I also have this - take with a pinch of salt - I wrote this learning about this system as you are trying to now... $ ls -al uefi-notes -rw-r--r-- 1 tim tim 2375 Dec 1 2018 uefi-notes 1 FDISK g - create a new empty GPT partition table p - create a primary partition +128M (size) t - change type 1 - EFI system p - create primary partition fill rest of disk vgcreate vg-uefi-boot /dev/sdb2 lvcreate -L 128M -n boot vg-uefi-boot lvcreate -l 100%FREE -n root vg-uefi-boot mke2fs -j /dev/mapper/vg--uefi--boot-boot mke2fs -j /dev/mapper/vg--uefi--boot-root mkdosfs /dev/sdb1 mount /dev/vg-uefi-boot/root /mnt/image/ debootstrap --variant=minbase stretch /mnt/image ftp://einstein/debian/ mount -o bind /proc /mnt/image/proc mount -o bind /dev /mnt/image/dev mount -o bind /sys /mnt/image/sys chroot /mnt/image /etc/kernel-img.conf apt-get update apt-get -y upgrade apt-get -y install sysvinit-core apt-get -y install openssh-server apt-get -y install ifupdown apt-get -y install grub-efi-amd64 apt-get -y install mdadm apt-get -y install lvm2 apt-get -y install linux-image-amd64 grub-install mkdir /boot/efi/EFI/BOOT cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi update-grub (update root password) umount /boot/efi umount /boot EOF umount /mnt/image/proc umount /mnt/image/dev umount /mnt/image/sys umount /mnt/image/ vgchange -aln vg-uefi-boot (Installed firmware-realtek) mount /dev/vg-uefi-boot/root /mnt/image/ mount -o bind /proc /mnt/image/proc mount -o bind /dev /mnt/image/dev mount -o bind /sys /mnt/image/sys chroot /mnt/image mount -a umount -a exit umount /mnt/image/proc umount /mnt/image/dev umount /mnt/image/sys umount /mnt/image/ vgchange -aln vg-uefi-boot
Re: install Kernel and GRUB in chroot.
Am 02.02.2024 um 01:46:06 Uhr schrieb Dmitry: > 2. ==>BAM<== some how that binary knows the system partition. That information is on the EFI partition, where the GRUB bootloader binary also resides. root@ryz:/boot/efi/EFI# cat /boot/efi/EFI/debian/grub.cfg search.fs_uuid 5b8b669d-xyz root hd0,gpt2 #boot partition set prefix=($root)'/grub' configfile $prefix/grub.cfg root@ryz:/boot/efi/EFI# If that information is loaded, the kernel can be loaded from the boot partition. -- Gruß Marco Spam und Werbung bitte an ichschickerekl...@cartoonies.org
Re: install Kernel and GRUB in chroot.
Hi Tim. The community is so kind. So. > I'm not exactly sure what you're doing. Understand how GRUB works, to boot myself. 1. Trying to install Debian on the Flash. 2. Use it by the Debootstrap. 3. Now I want to boot using that Flash. Looks like a caught the thread. 1. ESP is a partition that stores GRUB Binary. /boot/EFI/Name/grub64.eif 2. ==>BAM<== some how that binary knows the system partition. 3. At the system partition there is a /boot/grub/grub.cfg 4. And at that /boot/grub/grub.cfg is UUID and etc. to start Booting. But the question is on the step 2. /boot/EFI/Name/grub64.efi knows where to start /boot/grub/grub.cfg that resides at the absolutely different partition. Interesting. But the question already asked. Now it possible to find the answer. Thank you!
Re: install Kernel and GRUB in chroot.
Am 02.02.2024 um 00:09:56 Uhr schrieb Dmitry: > I made experiments with a FlashDrive, and create GPT there, > if I want to use standard Debian Image how I should partition that > flash drive (MBR, GPT)? Do you want to install the OS on it? For the partition table, I recommend GPT. Do you want an encrypted system? > > Do you need a special configuration here or is the default just > > fine? > > Need just working one. But I am confusing about how GRUB would get a > plenty of things related to filesystem, kernel location and so on. That is being done be the installer. If you don't need special configuration, use the install process. It does everything for you. -- Gruß Marco Spam und Werbung bitte an ichschickerekl...@cartoonies.org
Re: install Kernel and GRUB in chroot.
Huge thanks. Your message starts the understanding. And as well give a plenty of texts to read. > EFI/debian/grub.cfg on the EFI System Partition contains filesystem UUID where grub files reside. All parts are simple But when compounding them together become messy. In the Manjaro: /boot/EFI/Majaro/grub64x.efi - binary to start by UEFI. /boot/grub/grub.cfg - shell (?) script with configurations. /boot/vimlinuz.* - the kernel. And if call a `lsblk`. Only a /boot/efi with a binary is a separate partiton. Things become more clear.
Re: install Kernel and GRUB in chroot.
On Thu, 1 Feb 2024, Dmitry wrote: Greetings! After: 1. Creating GPT table and GPT partition with fdisk. 2. Copy data with a debootstrap. 3. Chroot into newly creating system. I need to prepare that system for booting. 1. Install Kernel. 2. Install GRUB and Configure. 3. Add changes to UEFI to start booting. And at the point two (Install GRUB) I a little bit confused. 1. Need to create ESP, and put GRUB there. 2. Need to configure GRUB to select appropriate kernel and ramdisk. I'm not exactly sure what you're doing. But the "trick" to doing most of this in a chroot is to bind mount /dev, /proc, /sys and /run into the chroot. Then things like installing the kernel, building the initrd etc (usually) just work. "Add changes to UEFI to start booting" depends on the actual hardware that will boot. If you're preparing images on one system to boot on another then that bit you'll have to solve by booting the hardware. I'd probably pick a live distro but it's theoretically[1] possible to generate your own bootx64.efi that will then boot your system. Once it's booted you can then use the normal tools to replace it with a more easily maintained debian solution. [1] Not just theoretical, I've actually done it once long ago.
Re: install Kernel and GRUB in chroot.
> Why don't you use the normal setup? Spend a lot of time on research, it would be nice to finish. I made experiments with a FlashDrive, and create GPT there, if I want to use standard Debian Image how I should partition that flash drive (MBR, GPT)? > Do you need a special configuration here or is the default just fine? Need just working one. But I am confusing about how GRUB would get a plenty of things related to filesystem, kernel location and so on. > If you create a separate boot partition (do you really need it?), it must be mounted at /boot. Here where the mess starts. How GRUB and Kernel would get information about all this mounting points during the Boot.
Re: install Kernel and GRUB in chroot.
On 01/02/2024 22:54, Marco Moock wrote: Am 01.02.2024 schrieb Dmitry: Use gdisk for that. You can create an EFI partition there. Choose Type EFI (EF00), 100MB. Format it with FAT32. 550MiB is recommended in "Preparing your ESP" http://www.rodsbooks.com/linux-uefi/#installing see also https://www.rodsbooks.com/gdisk/advice.html#esp_sizing https://fedoraproject.org/wiki/Changes/BiggerESP 2. Need to configure GRUB to select appropriate kernel and ramdisk. Do you need a special configuration here or is the default just fine? EFI/debian/grub.cfg on the EFI System Partition contains filesystem UUID where grub files reside. After installing grub check that NVRAM has an appropriate entry efibootmgr -v How GRUB would understand where to be install and where is the kernel? It loads files from filesystem on the specified partition. Unlike for BIOS device blocks are not involved.
Re: install Kernel and GRUB in chroot.
Am 01.02.2024 schrieb Dmitry : Why don't you use the normal setup? It does many tasks for you. > After: > 1. Creating GPT table and GPT partition with fdisk. Use gdisk for that. You can create an EFI partition there. Choose Type EFI (EF00), 100MB. Format it with FAT32. > And at the point two (Install GRUB) I a little bit confused. > > 1. Need to create ESP Do that before the install with gdisk. > and put GRUB there. That is done automatically if it is mounted at /boot/efi. > 2. Need to configure GRUB to select appropriate kernel and ramdisk. Do you need a special configuration here or is the default just fine? > How to create a ESP partition and mount it to /boot? That must be mounted to /boot/efi. If you create a separate boot partition (do you really need it?), it must be mounted at /boot. > How GRUB would understand where to be install and where is the kernel? It chooses by the path. grub-install is the command, no device as parameter.
Re: Install report debain bookworm
On 06/08/2023 22:48, m_josenh...@web.de wrote: Hi, I have today installed debian bookworm. I have a HP Officejet Pro 6380 printer connected via usb and wlan (over the router). In the past I had used KDE Neon. Before I updated KDE Neon to the version with is Ubuntu 04.22. based. I could enter the USB stick in the USB port of the printer and access it via the filemanger kde dolphin without plugging it directly into the computer. After I upgraded kde neon to the version based on Ubuntu 04.22. the USB stick inserted in the printer did no longer appear in dolphin. Today I installed debain bookworm (with KDE) and I have the same problem. Thus I would like to report a bug (regression). Against wich package shall I report this bug? Br, Michael Josenhans Hi Michael, there is no regression as in bug, but rather a changed default functionality in KDE Neon you used. Furthermore, you cannot report a regression because something worked in older KDE Neon before 22.04 and it's not working in Debian Bookworm. I suspect your printer have Samba filesharing on USB storage, and various distros handle this or not. Samba is meant to work as a Microsoft Windows filesharing protocol, so it's not exactly welcomed as force-install in ALL Debian installations. You may need to install support for it yourself. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: install missing unicode fonts
Huzzah! Thanks for the help, Darac! -m On Thu, Nov 17, 2022 at 2:58 PM Darac Marjal wrote: > > On 17/11/2022 19:32, Matt Zagrabelny wrote: > > Greetings, > > > > I've done some searching but came up empty with the correct way to > > install missing unicode fonts. > > > > For example, in my terminal I type "exa -l --icons" and I see: > > > > (that is a rectangle with the codepoint: F158) > > > > I don't see what F158 is supposed to represent. > > This is probably a NerdFont https://www.nerdfonts.com > > > > > > How do I find the package that installs this glyph/font/icon/whatever? > > > > If there is more than one package that provides it, how do I find out > > which one I should pick? > > > > Thanks for any help! > > > > -m >
Re: install missing unicode fonts
On 17/11/2022 19:32, Matt Zagrabelny wrote: Greetings, I've done some searching but came up empty with the correct way to install missing unicode fonts. For example, in my terminal I type "exa -l --icons" and I see: (that is a rectangle with the codepoint: F158) I don't see what F158 is supposed to represent. This is probably a NerdFont https://www.nerdfonts.com How do I find the package that installs this glyph/font/icon/whatever? If there is more than one package that provides it, how do I find out which one I should pick? Thanks for any help! -m OpenPGP_signature Description: OpenPGP digital signature
Re: install sur tablette
bonjour Mon expérience sur le tactile reste l'utilisation d'une Debian stable sur un PC hybride tactile (Lenovo Yoga 300) C'est une distribution installée depuis un autre PC sur un disque externe qui m'a servi à le booter, donc sans spécificités et outils tactiles. Lightdm m'a proposé une navigation au doigt très proche de ce qui se fait sur une tablette. Pas poussé l'expérience très loin (pas d'essai de clavier virtuel par exemple) car le clavier et la souris sont restés à portée, mais ça le fait. Erwann Appui long équivaudrait à Clic Droit? (Je n'utilise d'écran tactile qu'avec des smartphones Android.) Pour moi le tactile et le système clavier+souris ont chacun leurs spécificités et je pense qu'il n'est pas forcément opportun (quand on peut faire autrement, ce n'est pas forcément le cas) de chercher à utiliser une interface tactile comme on utiliserait une interface de saisie clavier+souris (un peu comme vouloir conserver le même mode de fonctionnement en GUI qu'on applique en CLI) Je connais donc mal la problématique tactile sous Linux mais de ma fenêtre j'ai l'impression qu'encore aujourd'hui, à part peut-être Plasma Mobile (et en plus vieux et moins sophistiqué Matchbox ou Sugar), Gnome, dans son fonctionnement principal c'est-à-dire ni "Classic" ni "Flashback", est l'environnement à privilégier car pensé pour du tactile, probablement autant au niveau de l'intefface générale du DE que de la majorité de ses applis. Et donc choisir (lorsque possible) des applis prévues pour le tactile Sous Android, je me suis rendu compte (ouais, je suis une bille, m'a fallu un moment pour m'en apercevoir) qu'un appui long du doigt sur une zone faisait apparaître un menu contextuel. Il y a quelques astuces ici: https://cours-informatique-gratuit.fr/cours/gestuelle-tactile-android/ amitiés, -- Erwann
Re: install sur tablette
bonjour Mon expérience sur le tactile reste l'utilisation d'une Debian stable sur un PC hybride tactile (Lenovo Yoga 300) C'est une distribution installée depuis un autre PC sur un disque externe qui m'a servi à le booter, donc sans spécificités et outils tactiles. Lightdm m'a proposé une navigation au doigt très proche de ce qui se fait sur une tablette. Pas poussé l'expérience très loin (pas d'essai de clavier virtuel par exemple) car le clavier et la souris sont restés à portée, mais ça le fait. Erwann Appui long équivaudrait à Clic Droit? (Je n'utilise d'écran tactile qu'avec des smartphones Android.) Pour moi le tactile et le système clavier+souris ont chacun leurs spécificités et je pense qu'il n'est pas forcément opportun (quand on peut faire autrement, ce n'est pas forcément le cas) de chercher à utiliser une interface tactile comme on utiliserait une interface de saisie clavier+souris (un peu comme vouloir conserver le même mode de fonctionnement en GUI qu'on applique en CLI) Je connais donc mal la problématique tactile sous Linux mais de ma fenêtre j'ai l'impression qu'encore aujourd'hui, à part peut-être Plasma Mobile (et en plus vieux et moins sophistiqué Matchbox ou Sugar), Gnome, dans son fonctionnement principal c'est-à-dire ni "Classic" ni "Flashback", est l'environnement à privilégier car pensé pour du tactile, probablement autant au niveau de l'intefface générale du DE que de la majorité de ses applis. Et donc choisir (lorsque possible) des applis prévues pour le tactile Sous Android, je me suis rendu compte (ouais, je suis une bille, m'a fallu un moment pour m'en apercevoir) qu'un appui long du doigt sur une zone faisait apparaître un menu contextuel. Il y a quelques astuces ici: https://cours-informatique-gratuit.fr/cours/gestuelle-tactile-android/ amitiés, -- Erwann
Re: install sur tablette
Appui long équivaudrait à Clic Droit? (Je n'utilise d'écran tactile qu'avec des smartphones Android.) Pour moi le tactile et le système clavier+souris ont chacun leurs spécificités et je pense qu'il n'est pas forcément opportun (quand on peut faire autrement, ce n'est pas forcément le cas) de chercher à utiliser une interface tactile comme on utiliserait une interface de saisie clavier+souris (un peu comme vouloir conserver le même mode de fonctionnement en GUI qu'on applique en CLI) Je connais donc mal la problématique tactile sous Linux mais de ma fenêtre j'ai l'impression qu'encore aujourd'hui, à part peut-être Plasma Mobile (et en plus vieux et moins sophistiqué Matchbox ou Sugar), Gnome, dans son fonctionnement principal c'est-à-dire ni "Classic" ni "Flashback", est l'environnement à privilégier car pensé pour du tactile, probablement autant au niveau de l'intefface générale du DE que de la majorité de ses applis. Et donc choisir (lorsque possible) des applis prévues pour le tactile Sous Android, je me suis rendu compte (ouais, je suis une bille, m'a fallu un moment pour m'en apercevoir) qu'un appui long du doigt sur une zone faisait apparaître un menu contextuel. Il y a quelques astuces ici: https://cours-informatique-gratuit.fr/cours/gestuelle-tactile-android/
Re: install sur tablette
On Wednesday 20 April 2022 13:36:48 hamster wrote: > Un copain me demande de lui installer linux sur une tablette. Pour vous > faire une idée du bidule, le mode d'emploi est la : > https://www.modes-d-emploi.com/manuals/795629/panasonic-toughbook-cf-d1.html?original=1 > C'est la première fois que j'installe sur un truc qui fonctionne > uniquement avec écran tactile. Je suis un peu déboussolé. Y'a pas de > souris, pas de clavier, juste un stylet qui clique quand on appuie et > qui est dépourvu de boutons. Je peux bien sur rajouter clavier et souris > externe en USB mais le but c'est d'utiliser le bidule en exterieur sur > un chantier, donc debout en se déplacant et sans se trimballer un > clavier et une souris. > Pour le clavier j'ai mis onboard, c'est pas pratique mais ca marche. > Pour la souris c'est très facile de cliquer, il suffit d'appuyer sur > l'écran avec le stylet ou meme avec le doigt, par contre je ne sais pas > faire un clic droit, ni un clic roulette, ni meme faire tourner la > roulette. J'ai essayé d'installer mousetweaks mais il refuse de marcher > en me disant qu'il a besoin d'etre sous X11. J'ai trouvé un rapport de > bug mentionnant que mousetweaks n'est plus supporté et devrait etre > supprimé. Mais je n'ai pas trouvé un autre paquet qui permette > d'utiliser un stylet comme une souris. > Si quelqu'un a des bons tuyaux je suis preneur. Bonne initiative. J'avais installé Debian sur un portable à écran tactile de bonne facture, mais il y a bien longtemps. Autant le tactile fonctionnait bien avec Windows-7 et modérément avec Linux. Je l'ai finalement donné à mon fils (qui préfèrait Windows, sniff et maintenant Mac). Sans doute que Linux a fait des progrès sur le plan du tactile ? Bonne journée, A. Valmer
Re: Install BIOVIA_2021.DS2021client
On 28.03.2022 23:33, Stephen P. Molnar wrote: Has anyone managed the installation of the BIOVIA_2021.DS2021client? Thanks in advance -- Stephen P. Molnar, Ph.D. www.molecular-modeling.net 614.312.7528 (c) Skype: smolnar1 Out of pure curiosity, I've managed to run this proprietary application¹ on Debian 11, but to make it happen I had to manually unpack and "install" it, and also implement a few hacks. Installer scripts don't work and were poorly tested, also this software depends on outdated "libpng15.so.15" dynamic library which is not in Debian repos anymore. So it is possible to run it, but there is no guarantee how this ugly mess of a software will work after manual "installation" and I suggest you to ask for updated version from the developers. It makes sense, at least because they ask money for a license, even though AFAICS it could be used as "free" viewer/editor. There are also community forums² exist for this application, so you probably better to ask for assistance there. ¹ https://imgur.com/a/zBoDwRO ² https://www.3ds.com/products-services/biovia/communities/ -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Re: Install BIOVIA_2021.DS2021client
On Mon 28 Mar 2022 at 14:33:36 -0400, Stephen P. Molnar wrote: > Has anyone managed the installation of the BIOVIA_2021.DS2021client? Have you considured your audience? Are we exoected to know what you are talkig about? How long did it take you to compose and send such an uninformative question? A minute? An hour? We are not a dumping ground for random questions about software that is not in Debian. Or is it? If it is, tell us about it. -- Brian.
Re: Install older versions of Debian with WSL
On 12/7/2021 5:15 PM, Andrew M.A. Cater wrote: On Tue, Dec 07, 2021 at 03:54:37PM +0100, Max Nadig wrote: Hi, I was trying to install Debian 10 via WSL on windows. The problem is, I automatically get v11 Bullseye. Is there some way to specify the version or load a custom Debian version with WSL? I already posted this question into the WSL Git repo. So far I couldn't find a solution for this. https://github.com/microsoft/WSL/issues/7805 Are there maybe legacy builds of the Debian microsoft store app available? This would probably solve my problem. Thank you for the help, best, Max Why do you want Debian 10 specifically? You could try the IRC channel #debian-wsl on OFTC / see if you can find the maintainer. In general terms, as soon as a release is put out, it's uploaded by rhaist to Microsoft - you want the latest stable to be the one used, If you realy need Buster, using VirtualBox or Qemu on Windows might fit the bill. -- John Doe
Re: Install older versions of Debian with WSL
On Tue, Dec 07, 2021 at 03:54:37PM +0100, Max Nadig wrote: > Hi, > > I was trying to install Debian 10 via WSL on windows. The problem is, I > automatically get v11 Bullseye. > Is there some way to specify the version or load a custom Debian version with > WSL? > > I already posted this question into the WSL Git repo. So far I couldn't find > a solution for this. > https://github.com/microsoft/WSL/issues/7805 > > Are there maybe legacy builds of the Debian microsoft store app available? > This would probably solve my problem. > > Thank you for the help, best, > Max Why do you want Debian 10 specifically? You could try the IRC channel #debian-wsl on OFTC / see if you can find the maintainer. In general terms, as soon as a release is put out, it's uploaded by rhaist to Microsoft - you want the latest stable to be the one used, Hope this helps, Andy C
Re: Install debian on USB-stick
Hi, https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.1.0-live+nonfree/amd64/iso-hybrid/debian-live-11.1.0-amd64-standard+nonfree.iso # cp debian-live-11.1.0-amd64-standard+nonfree.iso /dev/sdb # sync for other live https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.1.0-live+nonfree/amd64/iso-hybrid/ for minimal usbstick https://ftp.sh.cvut.cz/slax/Slax-9.x/slax-64bit-9.11.0.iso Regards. On Tue, Nov 9, 2021 at 9:48 AM Sim Sim wrote: > Hi. > > Is possible to install debian-11.1.0-i386-netinst.iso on 16Gb > USB2.0-stick? A minimal environment, of course. And productivity do not > need, just curiosity. > > Thanks. >
Re: Install debian on USB-stick
Sim Sim wrote: > Is possible to install debian-11.1.0-i386-netinst.iso on 16Gb USB2.0-stick? > A minimal environment, of course. And productivity do not need, just > curiosity. You can: - write that ISO to the stick and use it as an installer OR - boot that ISO and select a stick like that as the target disk but not both at once. 16GB is enough room for a fair number of things; I have a desktop PC here with lots of installed software where everytning which is not /home fits in 16GB. It will be fairly slow. A USB3 stick, if available, should be faster, and a USB3-connected SSD quite usable in the short term. -dsr-
Re: install avogadro with qt4
lina wrote: > I am interested in the old avogadro, instead of the current avogadro2 in > bullseye. > > The link is here > https://sourceforge.net/projects/avogadro/files/latest/download > > However, it needs qt4 support, which is the standard way to proceed with > the qt4, which is not supported in the current stable version. Mine system > is "stable" version. One possibility is to create a Debian 10 (oldstable) virtual machine, which can run the older qt4 and avogadro. -dsr-
Re: Install Debian netinstall to HP Elitebook 840 G8 problem
On Vi, 03 sep 21, 08:09:25, Patrick Bartek wrote: > On Fri, 3 Sep 2021 09:46:24 +0200 (CEST) > Richard Forst wrote: > > > I purchased a new laptop HP Elitebook 840 G8, and am trying to > > install Debian to it. However I encounter a problem. > > > > I change the bios setting, but when booting from usb. What was shown > > on the screen is simply a grub env command line like > > When in bios, did you disable Secureboot, Fastboot, and/or enable > Legacy option? The Debian Installer works for me on EFI with SecureBoot enabled. If you encounter any issues with it the Debian Installer Team will likely want to know about it (`reportbug installation-report` would be a good start). Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Install Debian 10 amd64 onto USB flash drive with and for Macintosh
On Jo, 02 sep 21, 22:29:34, David Christensen wrote: > > The contents of the SSD ESP filesystem are not ideal and I still do not > understand how the MacBook Pro firmware finds and/or chooses between boot > loaders. From my limited understanding of EFI the stick should have its own ESP with grub on it, preferably installed in the "removable path", so that it's always considered for booting. This should all be doable from the installer, possibly in expert mode. Hope this helps, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Install Debian 10 amd64 onto USB flash drive with and for Macintosh
On Thu 02 Sep 2021 at 22:29:34 (-0700), David Christensen wrote: > On 9/2/21 5:37 PM, David Wright wrote: > > On Wed 01 Sep 2021 at 16:00:13 (-0700), David Christensen wrote: > > > > [three long posts] > > > > That was very useful. I've condensed it into a file (attached) for > > my own use. The footnotes are notes, guesses and queries. > > > > My main question is — there are three identical listings taken at > > different times; all say: > > > > > # mount | grep '.dev.sd' > > > /dev/sdb3 on / type ext4 (rw,relatime,errors=remount-ro) > > > /dev/sdb1 on /boot/efi type vfat > > > (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) > > > > and yet two are labelled as wrong, and the third as correct. > > Thank you for your sharp eyes. Just a consequence of rewriting it for my own use, which meant crosschecking everything. > Without repeating those many hours of unpleasant work to confirm or > deny the console sessions and/or the intermediate conclusions, at this > point it does appear that I misread the output from the first two runs > of the following command in my post of 9/1/21 4:00 PM: > > # mount | grep '.dev.sd' > > As always, I will have to be careful when making decisions based upon > a single letter. Yes, I try to make it possible to use collateral information as a check. For example, years ago I would make all my partitions have slightly different sizes, because sizes were typically reported (and LABELs, PARTLABELs, UUIDs etc weren't). > RTFM mount(8), it talks about feeding UUID's into mount as > command-line arguments; but I do not see a way to have mount output > UUID's (?). I think you have to use a command like lsblk -l --fs or lsblk -l -o NAME,PARTUUID,PARTLABEL to get whatever you might want. If you only have busybox, then I think you're stuck with looking through the output from ls -lR /dev/disk for what you want. > (I never did figure out how to do a Secure Erase of the SSD.) I guess one can sacrifice a write-cycle and just zero the whole thing. > The contents of the SSD ESP filesystem are not ideal and I still do > not understand how the MacBook Pro firmware finds and/or chooses > between boot loaders. I read things like this: "With the introduction of System Integrity Protection in OS X 10.11 (El Capitan), Apple has locked down some of the things you can do with the nvram command. "Specifically, you can no longer set any variables that belong to the Efi GUID, like BootOrder. …"¹ but as I said, they don't mean a lot to me. ¹ https://wikileaks.org/ciav7p1/cms/page_26968084.html Cheers, David.
Re: Install Debian netinstall to HP Elitebook 840 G8 problem
On Fri, 3 Sep 2021 09:46:24 +0200 (CEST) Richard Forst wrote: > I purchased a new laptop HP Elitebook 840 G8, and am trying to > install Debian to it. However I encounter a problem. > > I change the bios setting, but when booting from usb. What was shown > on the screen is simply a grub env command line like When in bios, did you disable Secureboot, Fastboot, and/or enable Legacy option? B
Re: Install Debian netinstall to HP Elitebook 840 G8 problem
Ok I am kind of getting what goes wrong. First configure boot options to usb in bios setting as usual. Then do rebooting. After the screen displays HP logo, pressing esc button, which will again enter the bios seting or that kind of screen but it will ask (the screen will display) with several options, such as continuous boot ... boot options bios setup ... Then this time, pressing continuous boot or something similar (sorry can't remember the name, but it's at the first option). Now it enters to normal boot process where lovely debian installer asks me to install or use gui blah blah It also possible my iso did not burn correctly. I did rebrun iso to usb using etcher, which seemingly do validation step. Anyway, hopes this trivial info may be of help to someone who also runs into some annoying issues (not debian side) similar like mine. Thanks Sep 3, 2021, 15:46 by sterbl...@tutanota.com: > I purchased a new laptop HP Elitebook 840 G8, and am trying to install Debian > to it. However I encounter a problem. > > I change the bios setting, but when booting from usb. What was shown on the > screen is simply a grub env command line like > > grub> > > instead of a traditional debian install screen which may describe whether to > install with GUI or standard mode (non gui). I've repeated installing from > netinstall iso many times, but I had never run into such situation. So > actually I am stocked. I don't know that's because of UEFI or because the iso > burn to usb stick problem (but I check the usb I can see setup.exe, and those > bootable files as usual w/t a problem). > > The netinstall iso is downloaded from [1]. Is it expected now to install > debian from grub? Or maybe because the iso I download is broken? > > I am scratching my head. So I appreciate any comments or suggestions. Thanks! > > [1]. > > https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.0.0+nonfree/amd64/iso-cd/firmware-11.0.0-amd64-netinst.iso >
Re: Install Debian 10 amd64 onto USB flash drive with and for Macintosh
On 9/2/21 5:37 PM, David Wright wrote: On Wed 01 Sep 2021 at 16:00:13 (-0700), David Christensen wrote: [three long posts] That was very useful. I've condensed it into a file (attached) for my own use. The footnotes are notes, guesses and queries. I tried to file a bug report against the debian-installer complaining about the "Install" option not allowing me to choose where to put GRUB, thereby breaking macOS; but I don't see it yet on bugs.debian.org. STFW there are some resources for installing Debian onto a Macintosh internal SSD, but nothing recent for installing Debian onto a Macintosh external drive -- USB, SD card, or Thunderbolt. My main question is — there are three identical listings taken at different times; all say: # mount | grep '.dev.sd' /dev/sdb3 on / type ext4 (rw,relatime,errors=remount-ro) /dev/sdb1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) and yet two are labelled as wrong, and the third as correct. Thank you for your sharp eyes. Without repeating those many hours of unpleasant work to confirm or deny the console sessions and/or the intermediate conclusions, at this point it does appear that I misread the output from the first two runs of the following command in my post of 9/1/21 4:00 PM: # mount | grep '.dev.sd' As always, I will have to be careful when making decisions based upon a single letter. RTFM mount(8), it talks about feeding UUID's into mount as command-line arguments; but I do not see a way to have mount output UUID's (?). I found the device letters a bit confusing when you're running the rescue system. AFAICT, sda is always the SSD. So I was perplexed by "Rescue operations -> Execute shell in /dev/sda3" because your SSD only appeared to have two partitions in the OP. The Debian Installer sessions were manually transcribed, and could easily contain typographical errors. What seems to be missing from the account is any consideration of the so-called NVRAM variables, about which I know nothing. My Debian posts did not include my prior ordeals making a bootable macOS installation USB flash drive, logging out of Apple services, erasing the SSD, resetting NVRAM, installing macOS Big Sur, etc., per the following Apple URL's and lots more STFW: https://support.apple.com/en-us/HT201372 https://support.apple.com/en-us/HT201065 https://support.apple.com/en-us/HT208496 (I never did figure out how to do a Secure Erase of the SSD.) I'm still working through how hiding the EFI/debian tree makes the option-less booting suddenly work, but then, I don't know how closely the Option key corresponds to pressing F12 on, say, a Dell PC, which is how you set the device boot order. (I haven't touched a Mac since the last century when they were in a little AiO box.) The contents of the SSD ESP filesystem are not ideal and I still do not understand how the MacBook Pro firmware finds and/or chooses between boot loaders. David
Re: Install Debian 10 amd64 onto USB flash drive with and for Macintosh
On Wed 01 Sep 2021 at 16:00:13 (-0700), David Christensen wrote: [three long posts] That was very useful. I've condensed it into a file (attached) for my own use. The footnotes are notes, guesses and queries. My main question is — there are three identical listings taken at different times; all say: > # mount | grep '.dev.sd' > /dev/sdb3 on / type ext4 (rw,relatime,errors=remount-ro) > /dev/sdb1 on /boot/efi type vfat > (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) and yet two are labelled as wrong, and the third as correct. I found the device letters a bit confusing when you're running the rescue system. AFAICT, sda is always the SSD. So I was perplexed by "Rescue operations -> Execute shell in /dev/sda3" because your SSD only appeared to have two partitions in the OP. What seems to be missing from the account is any consideration of the so-called NVRAM variables, about which I know nothing. I'm still working through how hiding the EFI/debian tree makes the option-less booting suddenly work, but then, I don't know how closely the Option key corresponds to pressing F12 on, say, a Dell PC, which is how you set the device boot order. (I haven't touched a Mac since the last century when they were in a little AiO box.) Cheers, David. Post 1 (31 Aug 2021 15:31:43 -0700) Option boot with d-i inserted: Select an EFI Boot disk (unclear whether SSD vs USB, or USB's bootx64.efi vs grubx64.efi) Install buster onto newly inserted USB → "buster-mac" Debian tree for ESP (silently) onto SSD's ESP¹ Boot with USB inserted (twice): SSD's ESP debian tree points to USB buster-mac runs Boot without USB inserted: SSD's ESP Debian tree points to USB Grub> Option boot without USB inserted: Sees SSD MacBook firmware starts macOS Command-R boot: MacBook firmware stuff Boot with USB inserted: SSD's ESP Debian tree points to USB buster-mac runs again fdisk shows Mac OS on sdX2, buster-mac on sdX3 SSD's ESP is mounted at /boot/efi SSD's ESP contains APPLE and debian Post 2 (31 Aug 2021 17:39:37 -0700) Option boot with USB inserted: Still sees only SSD Boot with USB inserted (perhaps continuing from Option boot): buster-mac runs Listing of d-i's ESP with bootx64.efi² and grubx64.efi USB's ESP is empty Repeat listing of SSD's ESP Ruminations on copying files³ Post 3 (1 Sep 2021 16:00:13 -0700) Boot Rescue with d-i inserted: Insert USB Select USB's / as root filesystem Execute a shell in sda3⁴ Edit /etc/fstab to mount USB's ESP, not SSD's Mount USB's ESP Install Grub, choosing USB's ESP Boot with d-i and USB inserted: Something⁵ displays a Grub menu buster-mac selected and runs Boot with USB inserted: buster-mac selected and runs Reports "Mount device for /boot/efi is wrong⁶ -- still using internal SSD, not USB flash drive." Boot Rescue with d-i inserted: Insert USB Select USB's / as root filesystem Install Grub, forcing "Removable media path"⁷ Boot with d-i and USB inserted: Something⁵ displays a Grub menu buster-mac selected and runs Boot with USB inserted: buster-mac selected and runs Reports "Wrong⁶ -- internal SSD ESP is mounted at /boot/efi." Option boot with USB inserted: Sees SSD and EFI Boot⁸ EFI Boot selection starts buster-mac Reports success after the same listing as the two "failures" Boot with or without USB inserted: macOS runs, buster-mac never runs Option boot with USB inserted: Sees SSD and EFI Boot⁸ EFI Boot selection starts buster-mac Mount SSD's ESP Move the SSD's ESP debian tree, leaving the APPLE one Boot with USB inserted: buster-mac runs (no Option/selection needed now) Listing USB's ESP, identical to a standard Debian installation's Listing of fstab mentions sdd in the comments, rather than sdc⁹ ¹ Not the desired result, of course ² I think bootx64.efi might be the secure boot shim? ³ Copying EFI files might not be enough: what about NVRAM variables? ⁴ Does sda3 exist (on the SSD)? ⁵ Presumably USB ESP could do this, and perhaps SSD ESP as well ⁶ Not sure why: buster-mac has sdb3 on / and sdb1 on /boot/efi Both these are on sdb which is the USB There are three identical lists from mount | grep '.dev.sd' ⁷ Is this these three files? /boot/efi/EFI/BOOT/* ⁸ How different is this selection screen from the very first one? ⁹ Was sdc the firmware stick during the original installation?
Re: Install Debian 10 amd64 onto USB flash drive with and for Macintosh
On 9/1/21 1:15 AM, didier gaumet wrote: Hello, Hello. :-) Le mardi 31 août 2021 à 15:31 -0700, David Christensen a écrit : [...] I would like to install Debian 10 onto a USB flash drive as a self-contained, bootable, full, live installation that I use with this and other Intel-based Macintosh computers. - Booting the installation media with the rescue option will probably offer the possibility to reinstall grub with the desired option(s) Debian GNU/Linux 10.10.0 Debian GNU/Linux UEFI Installer menu -> Advanced options... -> Rescue mode Language -> C Continent or region -> North America Country, territory or area -> United States Keymap to use -> American English Load missing firmward from removable media? -> Yes Load missing firmware from removable media? -> No Wireless network -> wifi.tracy.holgerdanske.com Wireless network type for w1p3s0 -> WPA/WPA2 PSK WPA/WPA2 passphrase for wireless device w1p3s0 -> Hostname -> dpchrist-mbp Domain name -> tracy.holgerdanske.com Select your time zone -> Pacific Device to use as a root file system -> /dev/sdb3 The installed system appears to use a separate /boot/efi partition. It is normally a good idea to mount it as it will allow operations such as reinstalling the boot loader. However, if the file system on /boot/efi is corrupt then you may want o avoid mounting it. Mount separate /boot/efi partition? -> No Rescue operations -> Execute shell in /dev/sda3 Executing a shell -> Continue # blkid /dev/sdb1 /dev/sdb1: UUID-"D19A-5B1E" TYPE="vfat" PARTLABEL="buster-mac-esp" PARTUUID="447e5600-211c-4abd-ba38-c03969160b28" # vi /etc/fstab UUID=D19A-5B1E /boot/efi vfat umask=0077 0 1 # mount /boot/efi # exit Rescue operations -> Reinstall GRUB boot loader Device for boot loader installation -> /dev/sdb1 Rescue operations -> Reboot the system GNU GRUB version 2.02+dfsg1-20+deb10u4 -> Debian GNU/Linux -> Shutdown Boot debian-mac and login as root via SSH: 2021-09-01 15:03:56 root@buster-mac ~ # mount | grep '.dev.sd' /dev/sdb3 on / type ext4 (rw,relatime,errors=remount-ro) /dev/sdb1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) Mount device for /boot/efi is wrong -- still using internal SSD, not USB flash drive. Troubleshoot: 2021-09-01 15:05:09 root@buster-mac ~ # blkid /dev/sda1 /dev/sdb1 /dev/sda1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="67E3-17ED" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="78155464-748d-48f6-938c-a1341b1ae49a" /dev/sdb1: UUID="D19A-5B1E" TYPE="vfat" PARTLABEL="buster-mac-esp" PARTUUID="447e5600-211c-4abd-ba38-c03969160b28" 2021-09-01 15:05:34 root@buster-mac ~ # grep efi /etc/fstab # /boot/efi was on /dev/sda1 during installation #UUID=67E3-17ED /boot/efi vfatumask=0077 0 1 UUID=D19A-5B1E /boot/efi vfatumask=0077 0 1 Shutdown. Remove buster-mac USB flash drive. Boot debian-10.10.0-amd64-xfce-CD-1 USB flash drive. Follow above steps POINT_A through POINT_B, above, then continue: Device to use as a root file system -> /dev/sdd3 Mount separate /boot/efi partition? -> No Rescue operations -> Force GRUB installation to the EFI removable media path Force GRUB installation to the EFI removable media path? -> Yes Rescue operations-> Reboot system GNU GRUB version 2.02+dfsg1-20+deb10u4 -> Debian GNU/Linux -> Shutdown Boot debian-mac and login as root via SSH: 2021-09-01 15:22:28 root@buster-mac ~ # mount | grep '.dev.sd' /dev/sdb3 on / type ext4 (rw,relatime,errors=remount-ro) /dev/sdb1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) Wrong -- internal SSD ESP is mounted at /boot/efi. Shutdown Debian USB flash drive instance. Power up. Press and hold Option. Disk window now shows internal SSD and "EFI Boot" disk. Select "EFI Boot". Debian instance boots. Login as root via SSH: 2021-09-01 15:26:26 root@buster-mac ~ # mount | grep '.dev.sd' /dev/sdb3 on / type ext4 (rw,relatime,errors=remount-ro) /dev/sdb1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) Correct -- USB flash drive ESP is mounted at /boot/efi. Shutdown, remove buster-mac USB flash drive, and power up -- macOS boots. So, now macOS boots by default if the debian-mac USB flash drive is not inserted, I can boot the debian-mac USB flash drive using the flash drive ESP if I use Option, but the internal SSD ESP will be used if I insert the debian-mac USB flash drive and boot without Option. Boot debian-mac USB flash drive via Option. Mount the SSD ESP. Move aside the "debian" tree: 2021-09-01 15:34:50 root@buster-mac ~ # mount /dev/sda1 /mnt 2021-09-01 15:34:57 root@buster-mac ~ # mount | grep sda /dev/sda1 on /mnt type vfat
Re: Install Debian 10 amd64 onto USB flash drive with and for Macintosh
Hello, Le mardi 31 août 2021 à 15:31 -0700, David Christensen a écrit : [...] > I would like to install Debian 10 onto a USB flash drive as a > self-contained, bootable, full, live installation that I use with > this > and other Intel-based Macintosh computers. You should even be able to use it on any x86-64 PC if you install most firmwares [...] > If I now power up the machine with the buster-mac USB flash drive > installed, Debian starts. > > > If I now power up the machine without the buster-mac USB flash drive > installed, I see: > > GNU GRUB version 2.02+dfsg1-20+deb10u4 > > Minimal BASH-like line editing is supported. For the first word, > TAB > lists possible command completions. Anywhere else TAB lists > possible > device or file completions. > > grub> [...] I do not know where Grub has been installed but it has probably not been installed with the right option(s) - If I recall correctly, an expert install will ask you where to install grub and if it is a removable media - Booting the installation media with the rescue option will probably offer the possibility to reinstall grub with the desired option(s) - And you could simply boot your newly created Debian USB stick and reinstall Grub at the right place (specify the USB stick) with the right option(s). see grub-install manpage, options --removable and if not sufficient -- force-extra-removable
Re: Install Debian 10 amd64 onto USB flash drive with and for Macintosh
On 1/9/21 10:39, David Christensen wrote: If I now power up the machine with the buster-mac USB flash drive installed and hold the Option key, I see the MacBook firmware disk window showing the internal SSD only; the target USB flash drive with the Debian instance is not shown. David I'ts been at least a decade since I did this, but I recall aomething called rEFInd I had to install to help the process. There is also a boot option to hold another key to specify which alternate storeage device you wanted to boot. c was CD - the only device I used. Maybe u will get you to your USB. My other suggestion: is there a boot flag on the USB somewhere, perhaps the efi partition? -- All the best Keith Bainbridge keith.bainbridge.3...@gmail.com 0447 667 468
Re: Install Debian 10 amd64 onto USB flash drive with and for Macintosh
On 8/31/21 3:53 PM, Dan Ritter wrote: David Christensen wrote: debian-user: I have an Apple MacBook Pro (Retina, 15-inch, Mid 2015) with an Intel Core i7-4770HQ processor, 16 GB memory, and 256 GB SSD: If I now power up the machine with the buster-mac USB flash drive installed, Debian starts. If I now power up the machine without the buster-mac USB flash drive installed and hold the Option key, I see the MacBook firmware disk window showing the internal SSD. Selecting the internal SSD starts macOS. If I now power up the machine without the buster-mac USB flash drive installed and hold the Command-R keys, I see the MacBook firmware POST screen, then the MacBook firmware utilities window. Selecting Disk Utility and View -> Show All Devices, I see: I am pretty sure you didn't want to install GRUB at all -- the Mac's own EFI booter should work on your USB stick; it's invoked by holding down option at boot time. Thank you for the reply. :-) If I now power up the machine with the buster-mac USB flash drive installed and hold the Option key, I see the MacBook firmware disk window showing the internal SSD only; the target USB flash drive with the Debian instance is not shown. Perhaps the debian-10.10.0-amd64-xfce-CD-1 Debian Installer USB flash drive holds a clue, as the MacBook firmware Option key disk window displays two "EFI Boot" disks: 2021-08-31 16:56:36 root@buster-mac ~ # fdisk -l /dev/sdd Disk /dev/sdd: 3.6 GiB, 3887595520 bytes, 7592960 sectors Disk model: USB Flash Drive 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: 0x08fe9327 Device Boot Start End Sectors Size Id Type /dev/sdd1 *0 1425407 1425408 696M 0 Empty /dev/sdd27272 121994928 2.4M ef EFI (FAT-12/16/32) 2021-08-31 16:57:10 root@buster-mac ~ # mount -o ro /dev/sdd2 /mnt 2021-08-31 16:58:30 root@buster-mac ~ # tree /mnt /mnt `-- efi |-- boot | |-- bootx64.efi | `-- grubx64.efi `-- debian `-- grub.cfg 3 directories, 3 files 2021-08-31 17:01:22 root@buster-mac ~ # file /mnt/efi/boot/bootx64.efi /mnt/efi/boot/bootx64.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows 2021-08-31 17:01:35 root@buster-mac ~ # file /mnt/efi/boot/grubx64.efi /mnt/efi/boot/grubx64.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows 2021-08-31 17:01:46 root@buster-mac ~ # file /mnt/efi/debian/grub.cfg /mnt/efi/debian/grub.cfg: ASCII text 2021-08-31 17:01:59 root@buster-mac ~ # cat /mnt/efi/debian/grub.cfg search --file --set=root /.disk/info set prefix=($root)/boot/grub source $prefix/x86_64-efi/grub.cfg My guess is that efi/boot/bootx64.efi and efi/boot/grubx64.efi correspond to the two "EFI Boot" disks displayed by the MacBook firmware Option key disk window (?). I also noted that the ESP partition on the target USB flash drive is empty: 2021-08-31 17:02:02 root@buster-mac ~ # umount /mnt 2021-08-31 17:06:43 root@buster-mac ~ # mount -o ro /dev/sdb1 /mnt 2021-08-31 17:07:08 root@buster-mac ~ # ls -alF /mnt total 8 drwxr-xr-x 2 root root 4096 Dec 31 1969 ./ drwxr-xr-x 19 root root 4096 Aug 31 00:09 ../ I expect it needs the equivalent of boot/bootx64.efi, boot/grubx64.efi, and/or debian/grub.conf as found on the Debian Installer USB flash drive, but I very much doubt that simply copying those files from the Debian Installer USB flash drive to the target USB flash drive would work, given the "hybrid ISO" layout, overlapping partitions, etc., of the Debian Installer USB stick. Here is the ESP partition of the MacBook SSD again for comparison: 2021-08-31 17:33:40 root@buster-mac ~ # tree /boot/efi /boot/efi |-- BOOTLOG `-- EFI |-- APPLE | |-- CACHES | | `-- CAFEBEEF | `-- FIRMWARE | `-- MBP114.fd `-- debian |-- BOOTX64.CSV |-- fbx64.efi |-- grub.cfg |-- grubx64.efi |-- mmx64.efi `-- shimx64.efi 6 directories, 8 files Maybe if I copied the EFI/debian tree to the target USB flash drive ESP partition, reworked /etc/fstab, and/or reworked whatever other system configuration files are involved (?), the target USB flash device would be self-booting (?). Booting the debian-10.10.0-amd64-xfce-CD-1 Debian Installer USB flash drive, I see -> Advanced options... -> Expert install Maybe if I do an expert install, I will be given the opportunity to install GRUB and related onto the target USB flash drive (?). Alternatively: -> Advanced options... -> Rescue mode May if I knew enough, I could enter the right commands in a rescue shell and fix the target USB flash drive (?). I'll wait and see if anyone else has more information. David
Re: Install Debian 10 amd64 onto USB flash drive with and for Macintosh
David Christensen wrote: > debian-user: > > I have an Apple MacBook Pro (Retina, 15-inch, Mid 2015) with an Intel Core > i7-4770HQ processor, 16 GB memory, and 256 GB SSD: > > > If I now power up the machine with the buster-mac USB flash drive installed, > Debian starts. > > > > If I now power up the machine without the buster-mac USB flash drive > installed and hold the Option key, I see the MacBook firmware disk window > showing the internal SSD. Selecting the internal SSD starts macOS. > > > If I now power up the machine without the buster-mac USB flash drive > installed and hold the Command-R keys, I see the MacBook firmware POST > screen, then the MacBook firmware utilities window. Selecting Disk Utility > and View -> Show All Devices, I see: I am pretty sure you didn't want to install GRUB at all -- the Mac's own EFI booter should work on your USB stick; it's invoked by holding down option at boot time. -dsr-
Re: Can't boot following re-install to LVM on LUKS [was: can't login via gdm]
On Mon, Aug 16, 2021 at 03:46:51PM +0100, Morgan Read wrote: > On 11/08/2021 11:30 pm, David Christensen wrote: > > On 8/11/21 6:45 AM, Morgan Read wrote: > >> After having overcome a fairly fundamental bug with calamares as > >> described here: > >> https://github.com/calamares/calamares/issues/1564#issuecomment-846321060 > >> And, (unnecessarily as it turned out) re-installed my system, I find > >> I'm unable to boot. ... > ... Morgan, Hi Andy, Thanks for coming back to me:- Possibly just don't use calamares. Use the standard Debian installer (d-i for short). Either the standard or expert installs offer you "ordinary" LVM or encrypted LVM with LUKS, made even more straightforward if you can choose Actually, it was calamares that worked better than d-i - after failing with Debian's calamares live install I followed the instructions for d-i here: https://www.blakehartshorn.com/installing-debian-on-existing-encrypted-lvm/ Blake Hartshorn seems to do a pretty good job of describing the problem and solution. However, it wasn't a solution for me because the install failed repeatedly over the course of a couple of days (I was using 10.10 cf. BH using 10.4) - it wasn't until after I'd invested in a new flash drive and continued with the same fails that I tried the PureOS live install, which worked. You can read a full discussion of my woes here: https://github.com/calamares/calamares/issues/1564#issuecomment-898246354 Essentially, d-i couldn't get passed either the base system dpkg install (most usually base-passwd) or the following software install. The dpkg warnings were thrown on "parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg' : missing description field" with errors on the stateoverride file. I would have filed bug reports but then Debian went to 11 and I figured there'd be a new disk spun so it was all history anyway and I had a working machine with PureOS. Also: the standard size for swap is now 1G and for a dedicated /tmp partition of 2G. That's interesting - so nothing for hibernation on swap? I gave 8G to allow for hibernation, but would happily give it away if I could? Many thanks. -- Morgan Read UNITED KINGDOM Em: Confused about DRM? Get all the info you need at: OpenPGP_signature Description: OpenPGP digital signature
Re: Can't boot following re-install to LVM on LUKS [was: can't login via gdm]
On Mon, Aug 16, 2021 at 03:46:51PM +0100, Morgan Read wrote: > On 11/08/2021 11:30 pm, David Christensen wrote: > > On 8/11/21 6:45 AM, Morgan Read wrote: > >> After having overcome a fairly fundamental bug with calamares as > >> described here: > >> https://github.com/calamares/calamares/issues/1564#issuecomment-846321060 > >> And, (unnecessarily as it turned out) re-installed my system, I find > >> I'm unable to boot. ... > ... Morgan, Possibly just don't use calamares. Use the standard Debian installer (d-i for short). Either the standard or expert installs offer you "ordinary" LVM or encrypted LVM with LUKS, made even more straightforward if you can choose guided partitioning. Do be aware, however, that if you choose multi-filesystem, then you might have to check that the appropriate partition sizes are correct for you. In testing, we often have to swap the mount point labels around. Also: the standard size for swap is now 1G and for a dedicated /tmp partition of 2G. All the very best, as ever, Andy Cater > > When a system image is damaged or doubtful, I restore the last raw > > binary image onto a blank device, check out the configuration files, and > > restore local data. The computer is back in operation in a predictable > > amount of time with a high level of confidence that everything is correct. > > Thanks David - I do have my home directories all comfortably backed-up > to a raid device on my local server - I stopped taking stuff off-site a > year or so ago. However, it's still a right royal pita when both the > live CD and full install DVD are broken, see commentary from here: > https://github.com/calamares/calamares/issues/1564#issuecomment-898246354 > > I do find it puzzling that there's not straight forward way of doing > LVM-on-LUKS. > > Regards, > -- > Morgan Read >
Re: Can't boot following re-install to LVM on LUKS [was: can't login via gdm]
On 11/08/2021 11:30 pm, David Christensen wrote: > On 8/11/21 6:45 AM, Morgan Read wrote: >> After having overcome a fairly fundamental bug with calamares as >> described here: >> https://github.com/calamares/calamares/issues/1564#issuecomment-846321060 >> And, (unnecessarily as it turned out) re-installed my system, I find >> I'm unable to boot. ... ... > When a system image is damaged or doubtful, I restore the last raw > binary image onto a blank device, check out the configuration files, and > restore local data. The computer is back in operation in a predictable > amount of time with a high level of confidence that everything is correct. Thanks David - I do have my home directories all comfortably backed-up to a raid device on my local server - I stopped taking stuff off-site a year or so ago. However, it's still a right royal pita when both the live CD and full install DVD are broken, see commentary from here: https://github.com/calamares/calamares/issues/1564#issuecomment-898246354 I do find it puzzling that there's not straight forward way of doing LVM-on-LUKS. Regards, -- Morgan Read OpenPGP_signature Description: OpenPGP digital signature
Re: Can't boot following re-install to LVM on LUKS [was: can't login via gdm]
On 8/11/21 6:45 AM, Morgan Read wrote: Hi List, Since my cry for (fairly minor) help here: https://lists.debian.org/debian-user/2021/08/msg00461.html I think I've dug myself into a bit of a deep hole. After having overcome a fairly fundamental bug with calamares as described here: https://github.com/calamares/calamares/issues/1564#issuecomment-846321060 And, (unnecessarily as it turned out) re-installed my system, I find I'm unable to boot. ... "Find the needle in the haystack" does not work for me: 1. It takes an unpredictable amount of time. 2. Meanwhile, operations are stopped. 3. Only one needle? Really? 4. How do I validate that the haystack is "correct"? I keep my operating system images small enough to fit onto a single "16 GB" device (USB flash drive, SD card, SSD, HDD, etc.) using BIOS, MBR, and no hardware or software RAID (lowest common denominator). I take raw binary images of my operating system devices periodically and as needed. I keep my operating system configuration files in a version control system. I keep the vast majority of my data on RAID in a file server. I snapshot, replicate, back up, archive, etc., everything and rotate backup media on-, near-, and off-site. I have redundant and spare hardware. When a system image is damaged or doubtful, I restore the last raw binary image onto a blank device, check out the configuration files, and restore local data. The computer is back in operation in a predictable amount of time with a high level of confidence that everything is correct. David
Can't boot following re-install to LVM on LUKS [was: can't login via gdm]
Hi List, Since my cry for (fairly minor) help here: https://lists.debian.org/debian-user/2021/08/msg00461.html I think I've dug myself into a bit of a deep hole. After having overcome a fairly fundamental bug with calamares as described here: https://github.com/calamares/calamares/issues/1564#issuecomment-846321060 And, (unnecessarily as it turned out) re-installed my system, I find I'm unable to boot. Instead of getting a password prompt for my luks lvm partition, I get dropped to the shell with the following error: cryptsetup: ERROR: luks-[some UUID]: cryptsetup failed, bad password or options? /bin/cat: /crypto_keyfile.bin: No such file or directory Nothing to read on input In (initramfs) /cryptroot/crypttab There is luks-[some UUID] UUID=[some UUID] /crypto_keyfile.bin luks,keyscript=/bin/cat I can manually mount my my luks volume so: cryptsetup open /dev/sda3 --type luks [some UUID] Enter passphrase for /dev/sda3: To here: /dev/mapper/[some UUID] But, from there the LVM LVs don't get mounted and if I exit to boot then I get dropped back to the shell. And, lvm2 doesn't seem to be in initramfs. I can reboot to the live install usb image and when I do: sudo cryptsetup open /dev/sda3 --type luks [some UUID] Enter passphrase for /dev/sda3: >From the terminal, then the lvm on luks volumes pop up as expected immediately decrypted, named under /dev/mapped/[some VG-LV-name], /dev/[some VG]/[some LV], enumerated at /dev/dm-xyz etc and mounted under /media/user/[partition label] So, may be calamares has more than one bug with LVM on LUKS? Or, as the above bug only refers to LVM and not LUKS, perhaps I've done (or not done) something silly during the install with calamares and LUKS (though, it does seem a pretty pedestrian walk through of the install process). I guess, there's something not referenced in the initramfs? Any pointers to a way back from Armageddon would be great :) Thanks. -- Morgan Read E mst...@read.org.nz (GM)
Re: install par copie et ssh
> Bizarement l'option est dans la page de manuel d'apt-get mais pas celle > d'apt... dans man apt(8) Exactement comme apt lui-même, cette page de manuel vise à être une interface pour l'utilisateur et ainsi elle ne mentionne que les commandes et les options les plus courantes, en partie pour ne pas répéter les informations à de multiples emplacements et en partie pour ne pas noyer le lecteur par une surabondance d'options et de détails. ... install, reinstall, remove, purge (apt-get(8)) il est fait mention de apt-get(8). c'est probablement une façon de dire que si tu veut les détails, c'est là que ça se passe. cordialement, marc
Re : install par copie et ssh
Le 19/09/2020 14:10:35, Eric Laly a écrit : > Bonjour, > ou un paramètre sur la ligne de commande apt... > par exemple: > 'apt install mercurial tortoisehg tortoisehg-nautilus -y' > Bizarement l'option est dans la page de manuel d'apt-get mais pas > celle d'apt... Peut-être parce qu’apt n’est pas encore stabilisé. nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Re: install par copie et ssh
Bonjour, ou un paramètre sur la ligne de commande apt... par exemple: 'apt install mercurial tortoisehg tortoisehg-nautilus -y' Bizarement l'option est dans la page de manuel d'apt-get mais pas celle d'apt... Éric. Le 18/09/2020 à 16:46, Dominique Dumont a écrit : On Thursday, 17 September 2020 15:53:49 CEST Pierre Malard wrote: Je n’ai pas encore trouver le moyen de forcer le YES. Tu peux essayer la commande "yes". par exemple: yes | apt install stuff HTH
Re: install par copie et ssh
On Thursday, 17 September 2020 15:53:49 CEST Pierre Malard wrote: > Je n’ai pas encore trouver le moyen de forcer le YES. Tu peux essayer la commande "yes". par exemple: yes | apt install stuff HTH
Re: install par copie et ssh
Super, J’avais lu le man trop vite ! Merci > Le 17 sept. 2020 à 12:52, Frédéric MASSOT a > écrit : > > Le 17/09/2020 à 12:26, hamster a écrit : >> Salut. >> >> Comme d'autres, j'aime bien installer debian en copiant un système >> existant plutot qu'en refesant tout le processus d'install. C'est plus >> rapide et utilise >> moins le reseau. >> >> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a >> identifier l'ordi quand on s'y connecte en ssh. Si on installe par >> copie, on se retrouve donc avec plusieurs ordis qui ont les memes clef >> d'identification. Je cherche donc a renouveller ces clef après copie, >> mais tant dans google que dans les man, je me perds. >> >> Si quelqu'un a une piste a me donner, je suis preneur. > > Tu supprimes ou tu renommes (par précaution) les anciennes clés, puis tu > créés de nouvelles avec : > > sudo ssh-keygen -A > > > > -- > == > | FRÉDÉRIC MASSOT | > | http://www.juliana-multimedia.com | > | mailto:frede...@juliana-multimedia.com | > | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | > ===Debian=GNU/Linux=== > -- Pierre Malard «Quand un Français dit du mal de lui, ne le croyez pas, Il se vante !» Édouard Pailleron |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <-- signature.asc Description: Message signed with OpenPGP
Re: install par copie et ssh
Bonjour,
Il te suffit de régénérer ces clés du serveur avec un « ssh-keygen » une
fois la copie effectuée sur chaque type de clé. Par exemple en exécutant
ceci :
# for i in $(ls -1d /etc/ssh/ssh_host_*_key) ; do ssh-keygen -t "$(echo
${i/\/etc\/ssh\/ssh_host_} | cut -d_ -f1)" -N '' -f "${i}" -C
"root@$(hostname)"; done
Tu répond « y » à chaque fois qu’il te demande si tu veux l’écraser.
Je n’ai pas encore trouver le moyen de forcer le YES.
A+
> Le 17 sept. 2020 à 12:26, hamster a écrit :
>
> Salut.
>
> Comme d'autres, j'aime bien installer debian en copiant un système
> existant plutot qu'en refesant tout le processus d'install. C'est plus
> rapide et utilise
> moins le reseau.
>
> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
> identifier l'ordi quand on s'y connecte en ssh. Si on installe par
> copie, on se retrouve donc avec plusieurs ordis qui ont les memes clef
> d'identification. Je cherche donc a renouveller ces clef après copie,
> mais tant dans google que dans les man, je me perds.
>
> Si quelqu'un a une piste a me donner, je suis preneur.
>
--
Pierre Malard
« L'utopie, c'est la vérité de demain »
Victor Hugo (1802-1885)
|\ _,,,---,,_
/,`.-'`'-. ;-;;,_
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) πr
perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\
( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_):
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
signature.asc
Description: Message signed with OpenPGP
Re: install par copie et ssh
Le 17/09/2020 à 12:52, Frédéric MASSOT a écrit : > Le 17/09/2020 à 12:26, hamster a écrit : >> Salut. >> >> Comme d'autres, j'aime bien installer debian en copiant un système >> existant plutot qu'en refesant tout le processus d'install. C'est plus >> rapide et utilise >> moins le reseau. >> >> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a >> identifier l'ordi quand on s'y connecte en ssh. Si on installe par >> copie, on se retrouve donc avec plusieurs ordis qui ont les memes clef >> d'identification. Je cherche donc a renouveller ces clef après copie, >> mais tant dans google que dans les man, je me perds. >> >> Si quelqu'un a une piste a me donner, je suis preneur. > Tu supprimes ou tu renommes (par précaution) les anciennes clés, puis tu > créés de nouvelles avec : > > sudo ssh-keygen -A Super, ca marche nickel, merci.
Re: install par copie et ssh
Le 17/09/2020 à 12:26, hamster a écrit : > Salut. > > Comme d'autres, j'aime bien installer debian en copiant un système > existant plutot qu'en refesant tout le processus d'install. C'est plus > rapide et utilise > moins le reseau. > > Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a > identifier l'ordi quand on s'y connecte en ssh. Si on installe par > copie, on se retrouve donc avec plusieurs ordis qui ont les memes clef > d'identification. Je cherche donc a renouveller ces clef après copie, > mais tant dans google que dans les man, je me perds. > > Si quelqu'un a une piste a me donner, je suis preneur. Tu supprimes ou tu renommes (par précaution) les anciennes clés, puis tu créés de nouvelles avec : sudo ssh-keygen -A -- == | FRÉDÉRIC MASSOT | | http://www.juliana-multimedia.com | | mailto:frede...@juliana-multimedia.com | | +33.(0)2.97.54.77.94 +33.(0)6.67.19.95.69 | ===Debian=GNU/Linux===
Re: install par copie et ssh
salut, Je cherche donc a renouveller ces clef après copie, > mais tant dans google que dans les man, je me perds. je n'ai regardé ni le man, ni google pour te répondre mais apt source openssh-server vim openssh-8.3p1/debian/openssh-server.postinst regarde la fonction create_keys et tu devrais pouvoir adapter à ton problème. cordialement, marc
Re: install par copie et ssh
Bonjour, Tu peux la recréée facilement avec une ligne de commande: ssh-keygen -t rsa. Le jeu. 17 sept. 2020 12:41, hamster a écrit : > Le 17/09/2020 à 12:31, Bernard Schoenacker a écrit : > > > > - Mail original - > >> De: "hamster" > >> À: debian-user-french@lists.debian.org > >> Envoyé: Jeudi 17 Septembre 2020 12:26:23 > >> Objet: install par copie et ssh > >> > >> Salut. > >> > >> Comme d'autres, j'aime bien installer debian en copiant un système > >> existant plutot qu'en refesant tout le processus d'install. C'est > >> plus > >> rapide et utilise > >> moins le reseau. > >> > >> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a > >> identifier l'ordi quand on s'y connecte en ssh. Si on installe par > >> copie, on se retrouve donc avec plusieurs ordis qui ont les memes > >> clef > >> d'identification. Je cherche donc a renouveller ces clef après copie, > >> mais tant dans google que dans les man, je me perds. > >> > >> Si quelqu'un a une piste a me donner, je suis preneur. > >> > > > > bonjour, > > > > je conseille de passer par debootstrap et ensuite > > de remonter le système > > Merci bien mais je ne comprend rien a ce que tu me dit. > >
Re: install par copie et ssh
Le 17/09/2020 à 12:31, Bernard Schoenacker a écrit : > > - Mail original - >> De: "hamster" >> À: debian-user-french@lists.debian.org >> Envoyé: Jeudi 17 Septembre 2020 12:26:23 >> Objet: install par copie et ssh >> >> Salut. >> >> Comme d'autres, j'aime bien installer debian en copiant un système >> existant plutot qu'en refesant tout le processus d'install. C'est >> plus >> rapide et utilise >> moins le reseau. >> >> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a >> identifier l'ordi quand on s'y connecte en ssh. Si on installe par >> copie, on se retrouve donc avec plusieurs ordis qui ont les memes >> clef >> d'identification. Je cherche donc a renouveller ces clef après copie, >> mais tant dans google que dans les man, je me perds. >> >> Si quelqu'un a une piste a me donner, je suis preneur. >> > > bonjour, > > je conseille de passer par debootstrap et ensuite > de remonter le système Merci bien mais je ne comprend rien a ce que tu me dit.
Re: install par copie et ssh
- Mail original - > De: "hamster" > À: debian-user-french@lists.debian.org > Envoyé: Jeudi 17 Septembre 2020 12:26:23 > Objet: install par copie et ssh > > Salut. > > Comme d'autres, j'aime bien installer debian en copiant un système > existant plutot qu'en refesant tout le processus d'install. C'est > plus > rapide et utilise > moins le reseau. > > Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a > identifier l'ordi quand on s'y connecte en ssh. Si on installe par > copie, on se retrouve donc avec plusieurs ordis qui ont les memes > clef > d'identification. Je cherche donc a renouveller ces clef après copie, > mais tant dans google que dans les man, je me perds. > > Si quelqu'un a une piste a me donner, je suis preneur. > bonjour, je conseille de passer par debootstrap et ensuite de remonter le système attention aux cartes réseau et à leurs "adresses" merci @+ bernard
Re: install man pages
Ah, it DOES work, I got fooled by the footer when comparing, but maybe it is the OpenBSD _man_ that adds that because it ain't in the man page. -- underground experts united http://user.it.uu.se/~embe8573 https://dataswamp.org/~incal
Re: install Debian en machine virtuelle sans virtualbox
Bonjour Le 07/05/2020 à 11:03, Bernard Schoenacker a écrit : bonjour, je n'arrive pas à finaliser une install debian dans un volume virtualisé la base du tutoriel : https://ybad.name/ah/doku.php/7-vm/debian https://doc.huc.fr.eu.org/fr/sys/openbsd/vm-debian-buster/ j'ai utilisé cette instruction : /install.amd/vmlinuz vga=off initrd=/install.amd/initrd.gz --- quiet console=ttyS0,115200n8 ; la séquence démarre mais à un moment donné je n'ai plus rien et c'est le crash durant l'install avec l'ordi qui attends la prochaine séquence comment arriver à finaliser la chose ? Demander sur une liste openbsd ?
Re: Install OpenSMTPD from source or use the Debian packages?
On Wed, Feb 12, 2020 at 14:29 Greg Wooledge wrote: > On Wed, Feb 12, 2020 at 02:26:26PM -0600, Tom Browder wrote: > > Tixy, thanks. I did check the latest Deb 10 version but not the change > log. > > I was fooled by the Debian version number which looks like the BSD number > > which I guess never changes. > > https://www.debian.org/security/faq#version > Greg, thanks for the link. I am very grateful for all the helpful replies. And I am very glad to have learned some new things, including more reinforcement for my having chosen Debian as my go-to distro since Debian 4: a gift that keeps on giving! Debian users are a nice (and talented) bunch of people. Cheers! -Tom
Re: Install OpenSMTPD from source or use the Debian packages?
On Wed, Feb 12, 2020 at 02:26:26PM -0600, Tom Browder wrote: > Tixy, thanks. I did check the latest Deb 10 version but not the change log. > I was fooled by the Debian version number which looks like the BSD number > which I guess never changes. https://www.debian.org/security/faq#version
Re: Install OpenSMTPD from source or use the Debian packages?
On Wed, Feb 12, 2020 at 12:13 Tixy wrote: > On Wed, 2020-02-12 at 11:53 -0600, Tom Browder wrote: > > I started looking in to use of OpenSMPTD for a mail server and have > > installed it from Debian packages. > > > > In the process of reading a blog article by the current developer I > > discovered the upstream is now at version 6.6.2p1+ after some serious > > security issues were discovered by SSL Labs (Qualys). Note that > > Debian > > 10 is only at version 6.0.3p1! > > Are the security issues you are worried about not already fixed in > Debian's package? To check, you can look at the changelog for the > security update released two weeks ago... > > https://metadata.ftp-master.debian.org/changelogs//main/o/opensmtpd/opensmtpd_6.0.3p1-5+deb10u3_changelog Tixy, thanks. I did check the latest Deb 10 version but not the change log. I was fooled by the Debian version number which looks like the BSD number which I guess never changes. The change log does show the 6.6 and the vulnerability mentioned which Debian fixed. That is a good lesson for me for the future. -Tom
Re: Install OpenSMTPD from source or use the Debian packages?
Hi. On Wed, Feb 12, 2020 at 11:53:09AM -0600, Tom Browder wrote: > In the process of reading a blog article by the current developer I > discovered the upstream is now at version 6.6.2p1+ after some serious > security issues were discovered by SSL Labs (Qualys). Note that Debian > 10 is only at version 6.0.3p1! It's a common mistake to look at the beginning of the version of Debian package, disregarding the rest. Debian package is actually 6.0.3p1-5+deb10u3, and that deb10u3 part contains the patches that fixed CVE-2020-7247 you're referring to. > I would like to install from source but I wonder if that is such a > smart move, No, it does not. Specifically, if you're aiming at version 6.6.2p1 - install opensmtpd from the backports. > especially when we now use systemd and the source is set > up with the traditional GNU automake system and I don't see any > provision for systemd. I don't grok systemd very well and usually > rely on others for the proper setup. And that's why the lazy among us use Debian packages - because packages tend to fix such problems. > I have asked for help on the OpenSMTPD mailing list, But you'll likely to get OpenBSD-specific answer. Reco
Re: Install OpenSMTPD from source or use the Debian packages?
Tom Browder writes: > I started looking in to use of OpenSMPTD for a mail server and have > installed it from Debian packages. > > In the process of reading a blog article by the current developer I > discovered the upstream is now at version 6.6.2p1+ after some serious > security issues were discovered by SSL Labs (Qualys). Note that Debian > 10 is only at version 6.0.3p1! See the source at: > > https://github.com/OpenSMTPD/OpenSMTPD > > I would like to install from source but I wonder if that is such a > smart move, especially when we now use systemd and the source is set > up with the traditional GNU automake system and I don't see any > provision for systemd. I don't grok systemd very well and usually > rely on others for the proper setup. > > I have asked for help on the OpenSMTPD mailing list, but I suggested > my first effort would be to use the systemd setup used by the Debian > installation (with appropriate renaming). I haven't received an answer > yet. > > Opinions? > I'd suggest installing it from buster-backports. It looks like they have the version you need: https://packages.debian.org/buster-backports/mail/opensmtpd If you don't already have backports enabled, you can read about doing so here: https://backports.debian.org/Instructions/ > Thanks. > > -Tom -- Mike Oliver
Re: Install OpenSMTPD from source or use the Debian packages?
Quoting Tom Browder (2020-02-12 18:53:09) > I started looking in to use of OpenSMPTD for a mail server and have > installed it from Debian packages. > > In the process of reading a blog article by the current developer I > discovered the upstream is now at version 6.6.2p1+ after some serious > security issues were discovered by SSL Labs (Qualys). Note that Debian > 10 is only at version 6.0.3p1! See the source at: > > https://github.com/OpenSMTPD/OpenSMTPD > > I would like to install from source but I wonder if that is such a > smart move, especially when we now use systemd and the source is set > up with the traditional GNU automake system and I don't see any > provision for systemd. I don't grok systemd very well and usually > rely on others for the proper setup. > > I have asked for help on the OpenSMTPD mailing list, but I suggested > my first effort would be to use the systemd setup used by the Debian > installation (with appropriate renaming). I haven't received an answer > yet. Please beware that Debian backports bugfixes for stable releases, so it is not enough to look at version numbers to know if a package is vulnerable or not, you need to also inspect which patches has been applied. That said, feel free to try do a better job than Debian. If you like such work, then please do consider joining Debian so that others can benefit from the refinements that you make for yourself - that's why most if not all of us Debian developers do what we do: maintain and distribute our refinements as a coherent whole :-) Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Install OpenSMTPD from source or use the Debian packages?
On qua, 12 fev 2020, Tom Browder wrote: I started looking in to use of OpenSMPTD for a mail server and have installed it from Debian packages. In the process of reading a blog article by the current developer I discovered the upstream is now at version 6.6.2p1+ after some serious security issues were discovered by SSL Labs (Qualys). Note that Debian 10 is only at version 6.0.3p1! See the source at: https://github.com/OpenSMTPD/OpenSMTPD I would like to install from source but I wonder if that is such a smart move, especially when we now use systemd and the source is set up with the traditional GNU automake system and I don't see any provision for systemd. I don't grok systemd very well and usually rely on others for the proper setup. I have asked for help on the OpenSMTPD mailing list, but I suggested my first effort would be to use the systemd setup used by the Debian installation (with appropriate renaming). I haven't received an answer yet. buster-backports has 6.6.2p1: https://packages.debian.org/search?keywords=opensmtpd But note that while Debian stable rarely gets new versions, security fixes are backported onto the stable versions, so 6.0.3p1 might be "old", but probably has the security bugs fixed. You can see the status in https://security-tracker.debian.org/tracker/source-package/opensmtpd . -- Eduardo M KALINOWSKI edua...@kalinowski.com.br
Re: Install OpenSMTPD from source or use the Debian packages?
On Wed, 2020-02-12 at 11:53 -0600, Tom Browder wrote: > I started looking in to use of OpenSMPTD for a mail server and have > installed it from Debian packages. > > In the process of reading a blog article by the current developer I > discovered the upstream is now at version 6.6.2p1+ after some serious > security issues were discovered by SSL Labs (Qualys). Note that > Debian > 10 is only at version 6.0.3p1! Are the security issues you are worried about not already fixed in Debian's package? To check, you can look at the changelog for the security update released two weeks ago... https://metadata.ftp-master.debian.org/changelogs//main/o/opensmtpd/opensmtpd_6.0.3p1-5+deb10u3_changelog If you really want a newer version, buster-backports contains 6.6.2p1 but note that backports don't get official security support. -- Tixy
Re: Install OpenSMTPD from source or use the Debian packages?
On Wed, Feb 12, 2020 at 11:53:09AM -0600, Tom Browder wrote: > https://github.com/OpenSMTPD/OpenSMTPD > > I would like to install from source but I wonder if that is such a > smart move, especially when we now use systemd and the source is set > up with the traditional GNU automake system and I don't see any > provision for systemd. I don't grok systemd very well and usually > rely on others for the proper setup. > > I have asked for help on the OpenSMTPD mailing list, but I suggested > my first effort would be to use the systemd setup used by the Debian > installation (with appropriate renaming). I haven't received an answer > yet. Well, you have two main issues. First, you'll want to make sure *other* packages know that you have a mail-transport-agent installed. The Debian answer to this is a package called "equivs" which lets you build dummy packages that tell the package manager that you have various things, so it doesn't freak out. I believe equivs even comes with a sample control file that builds a package that "provides:" mail-transport-agent. Mine's named mta-local. Second, you'll need a way to start up your service after building and installing it. I don't know OpenSMTPD, and I don't know what its Debian systemd unit file looks like. If you intend to build and install the upstream version in a way that looks just like the Debian package does, then you might consider copying the Debian systemd unit file, changing its ExecStart= line(s) to point to your daemon, and dropping it in /etc/systemd/system/. On the other hand, if the Debian package does a lot of crazy crap that you do not intend to duplicate, you might find it easier to write a systemd unit file from scratch.
Re: Install buster, mouse lag
On Thu, 12 Dec 2019 20:34:11 + guy MARQUIS wrote: > Linux, > > I am sad, I didn't get a response to my mouse lag question. Yes after > 24 hours I get a blue ribbon for impatience. > > I read one forum that sounded similar to the bug I am getting, but it > related to an AMD/GPU hybrid. And suggested setting the processor > definition to ordinary instead of hybrid. Sounded way beyond my skill > level. > > In theory, my older hardware; 2011, was the same as that which the > package I am trying to install was written on and for. Which is what > makes it frustrating. A filesharing app like zfs/glusterfs has been > put aside for sparkle apps for 4k laptops and Google. > > > If I take 30 hours to set up my server with the laggy mouse and > keyboard double typing is it going to be crappy for it's intended > purpose of sharing files too? Since Linux is kernal console based and > the GUI is alien. Will the GUI problems affect the function. Since I > have taken a few weeks off work to set up this server and can't > really justify more time for a bug that may not be addressed for 3 > months. If you have issues with all the input hw I totally wouldnt suggest on proceeding with any further installation of software. You can check for the hw issues on the dmesg output (the kernel has really good messages that are easy to search online) and syslog files (as another answer suggests). For all I know you might have failing hardware that you want to detect earlier rather than later. Most likely though you ll be missing firmware/drivers. Regards, -- Nektarios Katakis
Re: Install buster, mouse lag
On 13.12.2019 1:34, guy MARQUIS wrote: > Linux, > > I am sad, I didn't get a response to my mouse lag question. Yes after > 24 hours I get a blue ribbon for impatience. > > I read one forum that sounded similar to the bug I am getting, but it > related to an AMD/GPU hybrid. And suggested setting the processor > definition to ordinary instead of hybrid. Sounded way beyond my skill > level. > > In theory, my older hardware; 2011, was the same as that which the > package I am trying to install was written on and for. Which is what > makes it frustrating. A filesharing app like zfs/glusterfs has been > put aside for sparkle apps for 4k laptops and Google. > > > If I take 30 hours to set up my server with the laggy mouse and > keyboard double typing is it going to be crappy for it's intended > purpose of sharing files too? Since Linux is kernal console based and > the GUI is alien. Will the GUI problems affect the function. Since I > have taken a few weeks off work to set up this server and can't really > justify more time for a bug that may not be addressed for 3 months. > > Thanks, > Bob You did get a reply from David. Are you subscribed to this list? Check your email and Spam folder. I vaguely remember my mouse doing similar stuff, that looked like unreliable USB connection, requiring me to click its buttons to make mouse cursor move again. The problem was gone after I plugged this mouse into a different USB port. If I switch it to previous USB port, it will exhibit same problems. And when I plug an USB thumb drive into same possibly problematic port it works without problems. If switching usb ports doesn't fix the problem for you, can you tell us more information about your mouse\keyboard and setup (is it wired connection, using usb-hub or kvm switch)? Is there something useful in the logs (/var/log/syslog)? It's has to be something with your setup, because others don't have same problems. -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
Re: Install prob
On 2019-12-11 13:51, guy MARQUIS wrote: Just got a new server. Installed Debian 9.9 on it and it ran fine, but it wouldn't install zfs or glusterfs. I heard Debian 10.2 had samba, glusterfs, and zfs pre-installed. so I got a copy. Now my mouse is buggy, moves painfully slow or jumps across screen, keyboard often doesn't detect keystrokes or uses double making the password problematic. Graphical install, turned printserver off. All rest oem. Have been using Linux 3 days. :) Any help would be appreciated. X8dtl-6f (non-uefi) motherboard Xeon 5670 (2 of them) 49 gig Samsung ram 12x hgst 10tb hdd 2x Samsung 120gb SSD Cse 933t-r760b backplane Debian 10.2 amd64 Thanks, Bob I use btrfs on Debian. I evaluated FUSE ZFS and kernel ZFS on Debian in the past -- they worked, but I switched to FreeBSD on my SOHO server specifically for ZFS and haven't looked back. David
Re: Install fest debian linux - Recife/Brazil - UPE/POLI - Oct, 05, 19
Olá Ruben, Sou Paulo, de Curitiba. Fico feliz em ver a movimentação da comunidade de Recife para organizar o Install Fest. Existe alguma página específica sobre o Install Fest no dia 4? Se tiver, me envie por gentileza o link para que eu possa publicar no https://micronews.debian.org/ Vocẽ tambén pode enviar a sua mensagem de divulgação para a lista: debian-br-even...@alioth-lists.debian.net Abraços, On 20/09/2019 22:16, Beco wrote: > Dear Debian users, > > It is with great satisfaction that I'm bringing you this news. > > We (UPE/POLI, Recife, BR) are holding a *Linux Install Fest / Debian*, > next Oct, 05, 19. > > Please, if you are from Debian marketing department, or know the proper > channels, help us to share this news officially. > > If you are responsible for the news, you may contact me directly for > more information. > > Thank you. > > Prof. Dr. Ruben Carlo Benante - organizer. > > PS. Attention: if you want to attend, be aware that there are limited > spots available. > > Event link: > > http://csec.poli.br/eventos/semana-universitaria/ > > > PPS. *Moderators* of other lists, please approve this one-time message > from a sender that is not subscribed, or if otherwise, please be kind to > forward this email yourself. Thank you very much for your support. > > > -- Forwarded message --------- > From: *Prof. Dr. Ruben Carlo Benante * > Date: Fri, 20 Sep 2019 at 22:06 > Subject: Re: Install fest debian linux > To: all debian linux users > > > Boa noite senhores e senhoras, > > É com muita alegria e satisfação que informo sobre a pré-inscrição do > evento na SU que iremos realizar (*): > > *Linux Install Fest / Debian!* > > Será durante o evento da SEMANA UNIVERSITÁRIA, no último dia, > > Data: sábado, 05/Out/19. > Local: LIP7 > Horário: das 9h as 17h > > Tragam seus notebooks e dêem o seu grito de liberdade! > > Com estimas! > Prof. Ruben > > PS. Vagas limitadas! > > PPS. (*) Ainda aguardo o aval da Extensão para confirmar o evento, local > e hora, mas deixo este email como "teaser" e é quase certo que o > dia/horário será mantido. Volto a confirmar com vocês todos na > segunda-feira. Por favor, espalhem a notícia aos quatro ventos. > > > > -- > Prof. Dr. Ruben Carlo Benante > UPE - Universidade de Pernambuco > ECOMP - Eng. da Computação > DCA - Eng. de Controle e Automação (Mecatrônica) > Rua Benfica, 455 - Madalena > CEP 50720-001 - Recife - PE > PABX: +55 (81) 3184-7555 > FAX: +55 (81) 3184-7501 > DCA: +55 (81) 3184-7570 > > "As I grow older, I pay less attention to what men say. I just watch > what they do." (Carnegie) > > > -- > Dr Beco > A.I. researcher > > "I know you think you understand what you thought I said but I'm not > sure you realize that what you heard is not what I meant" -- Alan Greenspan > > GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex=0x5A107A425102382A > Creation date: pgp.mit.edu <http://pgp.mit.edu> ID as of 2014-11-09 -- Paulo Henrique de Lima Santana (phls) Curitiba - Brasil Debian Developer Diretor do Instituto para Conservação de Tecnologias Livres Site: http://www.phls.com.br GNU/Linux user: 228719 GPG ID: 0443C450 signature.asc Description: OpenPGP digital signature
Re: Install fest debian linux - Recife/Brazil - UPE/POLI - Oct, 05, 19
Olá Ruben, Sou Paulo, de Curitiba. Fico feliz em ver a movimentação da comunidade de Recife para organizar o Install Fest. Existe alguma página específica sobre o Install Fest no dia 4? Se tiver, me envie por gentileza o link para que eu possa publicar no https://micronews.debian.org/ Vocẽ tambén pode enviar a sua mensagem de divulgação para a lista: debian-br-even...@alioth-lists.debian.net Abraços, On 20/09/2019 22:16, Beco wrote: > Dear Debian users, > > It is with great satisfaction that I'm bringing you this news. > > We (UPE/POLI, Recife, BR) are holding a *Linux Install Fest / Debian*, > next Oct, 05, 19. > > Please, if you are from Debian marketing department, or know the proper > channels, help us to share this news officially. > > If you are responsible for the news, you may contact me directly for > more information. > > Thank you. > > Prof. Dr. Ruben Carlo Benante - organizer. > > PS. Attention: if you want to attend, be aware that there are limited > spots available. > > Event link: > > http://csec.poli.br/eventos/semana-universitaria/ > > > PPS. *Moderators* of other lists, please approve this one-time message > from a sender that is not subscribed, or if otherwise, please be kind to > forward this email yourself. Thank you very much for your support. > > > -- Forwarded message --------- > From: *Prof. Dr. Ruben Carlo Benante * > Date: Fri, 20 Sep 2019 at 22:06 > Subject: Re: Install fest debian linux > To: all debian linux users > > > Boa noite senhores e senhoras, > > É com muita alegria e satisfação que informo sobre a pré-inscrição do > evento na SU que iremos realizar (*): > > *Linux Install Fest / Debian!* > > Será durante o evento da SEMANA UNIVERSITÁRIA, no último dia, > > Data: sábado, 05/Out/19. > Local: LIP7 > Horário: das 9h as 17h > > Tragam seus notebooks e dêem o seu grito de liberdade! > > Com estimas! > Prof. Ruben > > PS. Vagas limitadas! > > PPS. (*) Ainda aguardo o aval da Extensão para confirmar o evento, local > e hora, mas deixo este email como "teaser" e é quase certo que o > dia/horário será mantido. Volto a confirmar com vocês todos na > segunda-feira. Por favor, espalhem a notícia aos quatro ventos. > > > > -- > Prof. Dr. Ruben Carlo Benante > UPE - Universidade de Pernambuco > ECOMP - Eng. da Computação > DCA - Eng. de Controle e Automação (Mecatrônica) > Rua Benfica, 455 - Madalena > CEP 50720-001 - Recife - PE > PABX: +55 (81) 3184-7555 > FAX: +55 (81) 3184-7501 > DCA: +55 (81) 3184-7570 > > "As I grow older, I pay less attention to what men say. I just watch > what they do." (Carnegie) > > > -- > Dr Beco > A.I. researcher > > "I know you think you understand what you thought I said but I'm not > sure you realize that what you heard is not what I meant" -- Alan Greenspan > > GPG Key: https://pgp.mit.edu/pks/lookup?op=vindex=0x5A107A425102382A > Creation date: pgp.mit.edu <http://pgp.mit.edu> ID as of 2014-11-09 -- Paulo Henrique de Lima Santana (phls) Curitiba - Brasil Debian Developer Diretor do Instituto para Conservação de Tecnologias Livres Site: http://www.phls.com.br GNU/Linux user: 228719 GPG ID: 0443C450 signature.asc Description: OpenPGP digital signature
Re: Install buster sur lvm chiffré complètement foirée
Le 10/09/19 à 16:52, Pascal Hambourg a écrit : > > J'avais bien cru avoir trouvé en voyant qu'il manquait le /etc/crypttab, > > mais > > l'ajouter ne change rien. > > Tu as regénéré l'initramfs ensuite ? Sinon ça ne sert à rien. Je suppose que c'était bien ça qui manquait, je sais plus trop si je l'avais fait avant / après, en tout cas j'ai fini par récupérer l'ancien et le nouveau /etc sur une autre machine pour pouvoir avoir une comparaison plus confortable (pas moyen de lancer un sshd depuis le chroot du rescue, mais le client ssh permet d'envoyer du contenu), et après avoir tout vérifié j'ai refait en rescue un grub-install & dpkg-reconfigure linux-image… (qui fait l'update-initramfs & update-grub) et ça boot. Reste à tout réinstaller (avec la liste des paquets faite avant ça va assez vite) et reconfigurer (ça c'est plus long), et régler mon pb de wifi sur l'autre machine. Merci pour ton aide. -- Daniel Un artiste qui plaît à tout le monde, ça deplaît à certains. Paradoxal, non ? Philippe Geluck, Le chat
Re: Install buster sur lvm chiffré complètement foirée
Le 10/09/2019 à 16:33, Daniel Caillibaud a écrit : Il n'y a pas de partition /boot non chiffrée ? Risqué, car impossible de démarrer au moindre problème. Même avec une partition non chiffrée ça démarre pas ;-) Mais si, ça démarre. Jusqu'à l'initramfs. Evidemment il n'y a pas de raison que ça aille plus loin puisque le problème ne vient pas de la lecture de /boot par GRUB mais du montage de la racine par l'initramfs. Ouais, une : comme tu n'as pas créé de volume chiffré avec l'installateur, il n'a pas inclus ce qu'il faut (paquets cryptsetup-initramfs et cryptsetup-run, fichier /etc/crypttab) pour pouvoir démarrer avec une racine chiffrée. Démarre avec l'installateur en mode rescue, lance un shell sur la racine et vérifie tout ça. Après une réinstall avec un /boot séparé non chiffré ça bootait toujours pas, j'avais bien le menu grub mais ensuite il me demandait pas de passphrase (et évidemment trouvait pas ses volumes lvm). C'est bien la preuve que l'initramfs est incomplet. J'avais bien cru avoir trouvé en voyant qu'il manquait le /etc/crypttab, mais l'ajouter ne change rien. Tu as regénéré l'initramfs ensuite ? Sinon ça ne sert à rien. Et cette fois j'avais choisi l'option "tout mettre dans l'initramfs" (plutôt que "seulement ce qui est nécessaire pour cette machine"). Je ne pense pas que ça change quelque chose à ton problème. Par contre l'initramfs réduit (MODULES=dep dans /etc/initramfs-tools/) est un piège à con qui risque d'empêcher le démarrage en cas de changement quelconque de la configuration matérielle. En général on n'est pas à quelques Mo près. J'ai vérifié, il a bien les paquets cryptsetup-initramfs et cryptsetup-run installés (avec cryptsetup-bin, les 3 étants des dépendances de "cryptsetup"), mais ça veut toujours pas… Et /etc/crypttab est présent et contient ce qu'il faut pour ouvrir le volume chiffré ? Tu as vérifié que l'initramfs contient bien les boot scripts de cryptsetup ? Au cas où, tu as ajouté, l'option "initramfs" pour forcer l'ouverture du volume dans l'initramfs (et regénéré l'initramfs ensuite) ?
Re: Install buster sur lvm chiffré complètement foirée
Le 10/09/19 à 14:29, Pascal Hambourg a écrit : > > - pas trouvé comment préciser à l'installeur que j'ai un clavier bépo > > Peut-être en lançant l'installateur en mode expert ? C'est ce que j'avais fait, y'a que clavier "français" sans pouvoir préciser les variantes (ou pas trouvé où). > Effectivement la réutilisation d'un volume chiffré existant est une > grosse lacune de l'installateur. Il peut activer les ensembles RAID et > volumes logiques LVM existants mais pas les volumes chiffrés... Ça m'a paru tellement bizarre que j'ai cherché un moment et cru que j'étais vraiment bigleux… > >faut commencer l'install, aller jusqu'au partitonnement manuel, sortir de > >l'installeur (ouvrir une autre console) pour déchiffrer le PV > > manuellement (cryptsetup > > open --type luks /dev/sdxN monVolumeChiffré && vgchange -ay) puis retourner > > dans > > l'installeur, gestion lvm, détruire le lv root existant et le recréer > > (sinon impossible de > > l'utiliser, il me le propose pas dans les choix) et l'utiliser comme /, ouf > > ! > > - c'était pas fini, grub install plante plus loin sans dire pourquoi > > => reboot sur la clé en rescue, chroot dans le lv root de buster > > fraichement installé puis > > grub-install me dit qu'il veut dans /etc/default/grub la ligne > > GRUB_ENABLE_CRYPTODISK=y > > Il n'y a pas de partition /boot non chiffrée ? Risqué, car impossible de > démarrer au moindre problème. Même avec une partition non chiffrée ça démarre pas ;-) > > Je l'ajoute, grub-intstall ok mais au reboot > > - clavier qwerty pour saisir la passphrase, fallait deviner > > Normal dans GRUB. Configurer le clavier dans GRUB semble compliqué, je > n'ai jamais essayé. Encore un autre inconvénient du /boot chiffré. En fait dans le menu grub on peut, par ex https://bepo.fr/wiki/Console_GNU/Linux#Grub_2, mais là effectivement avec un /boot chiffré il demande la passphrase avant d'afficher le menu grub et y'a probablement pas de moyen d'inclure une locale de clavier dans le loader. > > - après pass ok, j'ai bien le menu grub mais il trouve pas le lv root > >et m'affiche l'erreur en boucle... > > > > J'ai bien tenté d'éditer l'entrée grub pour préciser du /dev/vg/lv plutôt > > que > > le /dev/mapper--vg-lv mais ça change rien... > > Pas une bonne idée de toute façon, c'est avec la forme > root=/dev/mapper/vg-lv que l'initramfs identifie que la racine est un > volume logique LVM. > > > Une idée ? > > Ouais, une : comme tu n'as pas créé de volume chiffré avec > l'installateur, il n'a pas inclus ce qu'il faut (paquets > cryptsetup-initramfs et cryptsetup-run, fichier /etc/crypttab) pour > pouvoir démarrer avec une racine chiffrée. > > Démarre avec l'installateur en mode rescue, lance un shell sur la racine > et vérifie tout ça. Après une réinstall avec un /boot séparé non chiffré ça bootait toujours pas, j'avais bien le menu grub mais ensuite il me demandait pas de passphrase (et évidemment trouvait pas ses volumes lvm). J'avais bien cru avoir trouvé en voyant qu'il manquait le /etc/crypttab, mais l'ajouter ne change rien. Et cette fois j'avais choisi l'option "tout mettre dans l'initramfs" (plutôt que "seulement ce qui est nécessaire pour cette machine"). J'ai vérifié, il a bien les paquets cryptsetup-initramfs et cryptsetup-run installés (avec cryptsetup-bin, les 3 étants des dépendances de "cryptsetup"), mais ça veut toujours pas… J'ai aussi essayé de poursuivre l'installation en ssh (l'installeur le propose en install avancée), pour pouvoir copier/coller des messages d'erreurs et chercher sur le net, mais ça marche pas non plus, too much failures dès la 1re tentative. > > Par ailleurs, j'espère pouvoir récupérer mon 2e disque, mais j'ai pas > > encore trouvé comment > > (il voit un PV mais me dit qu'il n'y a pas de vg dedans), je suis aussi > > preneur de > > conseil. > > C'est un autre VG que celui qui contient la racine chiffrée ? Oui, et lui n'est pas sur un pv chiffré. . Pas compris ce qui s'est passé, pvcheck & vgcheck ne permettent pas de récupérer mon vg, heureusement j'ai retrouvé un backup des metadatas lvm de ce disque et j'ai pu le récupérer avec un vgcfgrestore. Du coup j'ai lancé un nouveau backup, et si j'arrive toujours pas à booter je referai une install en reformatant tout mon disque principal en refaisant tout le chiffrement + partitionnement depuis l'installeur, mais c'est assez énervant d'en arriver là en y ayant passé autant d'heures… Je sais pas pourquoi le dist-upgrade a tout cassé (c'est bien la première fois que ça m'arrive, et mon 1er doit remonter à woody=>sarge), mais je sais que je suis pas près de réutiliser l'installer sur de l'existant (j'aurais dû booter sur un live, monter et préparer mes partitions et passer par deboostrap pour l'install). -- Daniel Ce que les hommes appellent civilisation, c'est l'état actuel des mœurs et ce qu'ils appellent barbarie, ce sont les états antérieurs. Anatole France
Re: Install buster sur lvm chiffré complètement foirée
Le 10/09/2019 à 12:44, Daniel Caillibaud a écrit : - pas trouvé comment préciser à l'installeur que j'ai un clavier bépo Peut-être en lançant l'installateur en mode expert ? - mis des plombes à trouver comment l'installer dans un LV chiffré (sans détruire tout le VG existant), Effectivement la réutilisation d'un volume chiffré existant est une grosse lacune de l'installateur. Il peut activer les ensembles RAID et volumes logiques LVM existants mais pas les volumes chiffrés... faut commencer l'install, aller jusqu'au partitonnement manuel, sortir de l'installeur (ouvrir une autre console) pour déchiffrer le PV manuellement (cryptsetup open --type luks /dev/sdxN monVolumeChiffré && vgchange -ay) puis retourner dans l'installeur, gestion lvm, détruire le lv root existant et le recréer (sinon impossible de l'utiliser, il me le propose pas dans les choix) et l'utiliser comme /, ouf ! - c'était pas fini, grub install plante plus loin sans dire pourquoi => reboot sur la clé en rescue, chroot dans le lv root de buster fraichement installé puis grub-install me dit qu'il veut dans /etc/default/grub la ligne GRUB_ENABLE_CRYPTODISK=y Il n'y a pas de partition /boot non chiffrée ? Risqué, car impossible de démarrer au moindre problème. Je l'ajoute, grub-intstall ok mais au reboot - clavier qwerty pour saisir la passphrase, fallait deviner Normal dans GRUB. Configurer le clavier dans GRUB semble compliqué, je n'ai jamais essayé. Encore un autre inconvénient du /boot chiffré. - après pass ok, j'ai bien le menu grub mais il trouve pas le lv root et m'affiche l'erreur en boucle... J'ai bien tenté d'éditer l'entrée grub pour préciser du /dev/vg/lv plutôt que le /dev/mapper--vg-lv mais ça change rien... Pas une bonne idée de toute façon, c'est avec la forme root=/dev/mapper/vg-lv que l'initramfs identifie que la racine est un volume logique LVM. Une idée ? Ouais, une : comme tu n'as pas créé de volume chiffré avec l'installateur, il n'a pas inclus ce qu'il faut (paquets cryptsetup-initramfs et cryptsetup-run, fichier /etc/crypttab) pour pouvoir démarrer avec une racine chiffrée. Démarre avec l'installateur en mode rescue, lance un shell sur la racine et vérifie tout ça. Par ailleurs, j'espère pouvoir récupérer mon 2e disque, mais j'ai pas encore trouvé comment (il voit un PV mais me dit qu'il n'y a pas de vg dedans), je suis aussi preneur de conseil. C'est un autre VG que celui qui contient la racine chiffrée ?
Re: Install debian armhf on tablet "surface rt"
Hi, hans.ullr...@loop.de wrote: > The "Surface RT" is capable to start of an usb-stick, but it is EFI secured. What exactly do you mean by "EFI secured" ? > However, the debian installer > (on intel hardware) can be started with uefi, too, so why should the same > not work with armhf? I just downloaded https://cdimage.debian.org/debian-cd/current/armhf/iso-cd/debian-10.1.0-armhf-netinst.iso It has an EFI system partition: $ /sbin/fdisk -l debian-10.1.0-armhf-netinst.iso ... Disklabel type: dos ... Device Boot StartEnd Sectors Size Id Type debian-10.1.0-armhf-netinst.iso1 0 948223 948224 463M 83 Linux debian-10.1.0-armhf-netinst.iso2 948224 95027120481M ef EFI (FAT-12 $ expr 948224 '*' 512 485490688 $ mount -o offset=485490688 /dvdbuffer/debian-10.1.0-armhf-netinst.iso /mnt/fat $ find /mnt/fat /mnt/fat /mnt/fat/efi /mnt/fat/efi/boot /mnt/fat/efi/boot/bootarm.efi $ UEFI specs prescribe bootarm.efi as boot file name for "AArch32 architecture". It looks like a GRUB2 EFI boot program. $ strings /mnt/fat/efi/boot/bootarm.efi | less begins by "!This program cannot be run in DOS mode." and has lots of names beginning by "grub". Let's look at an amd64 ISO: $ /sbin/fdisk -l debian-10.0.0-amd64-netinst.iso ... Disklabel type: dos ... Device Boot StartEnd Sectors Size Id Type debian-10.0.0-amd64-netinst.iso1 *0 684031 684032 334M 0 Empty debian-10.0.0-amd64-netinst.iso2 3808 94715664 2.8M ef EFI (FAT-12/ $ expr 3808 '*' 512 1949696 $ mount -o offset=1949696 debian-10.0.0-amd64-netinst.iso /mnt/fat $ find /mnt/fat /mnt/fat /mnt/fat/efi /mnt/fat/efi/boot /mnt/fat/efi/boot/bootx64.efi /mnt/fat/efi/boot/grubx64.efi /mnt/fat/efi/debian /mnt/fat/efi/debian/grub.cfg Afaik /efi/boot/bootx64.efi is the certified Secure Boot starter (shim): $ strings /mnt/fat/efi/boot/bootx64.efi | fgrep Microsoft | wc -w 145 The file grubx64.efi looks like GRUB2. So it could be about disabling Secure Boot. If this cannot be done, then you'd need to convince Debian to beg Microsoft for a signed shim for armhf and to then add armhf to https://wiki.debian.org/SecureBoot#Supported_architectures_and_packages Have a nice day :) Thomas
Re: install avec connexion par airbox 4G
Bonjour. Il m'est arrivé (cela devait être sous Debian 6) de charger un firmware Ethernet non libre pendant l'installation. Je suppose que cela peut aussi fonctionner en wifi. De mémoire, j'avais lancé une première installation qui m'a indiqué le firmware manquant. À partir de cette information, j'ai déterminé le paquet non libre nécessaire et je l'ai mis à la racine d'une clé USB. J'ai relancé une installation et j'ai inséré la clé USB lorsque l'installateur me l'a proposé. Il y a eu quelques tâtonnements, mais cela avait bien marché. Cordialement, Daniel Sauvard Le 21/07/2019 à 16:02, hamster a écrit : > Le 21/07/2019 à 15:47, roger.tar...@free.fr a écrit : >> En USB : je ne crois pas que ça puisse marcher pour l'installation puisqu'il >> n'y a pas encore les ressources installées. > > Merci de l'info. > >> A ma connaissance, on ne peut pas installer Debian avec une connexion wifi. > > J'ai vu dans l'installeur la possibilité de charger le firmware wifi > depuis un support externe, mais j'ai jamais réussi a faire marcher cette > fonction. >
