Re: shame on me (was: Re: No fool like an old fool (debian installation probs))
On Tue 02 May 2023 at 12:10:48 (+0200), DdB wrote:
> I notice, that, even though i did change the name of the sda2 partition,
> the PARTLABEl remained unchanged.
It's rather confusing that gdisk (my preferred partitioner, which
I use outside the installer) refers to the PARTLABEL as the
partition's name rather than label:
Command (? for help): c
Using 1
Enter name: Kirk01
Command (? for help): i
Using 1
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 13005F6E-6289-4AB9-B36E-8689CF983EF5
First sector: 2048 (at 1024.0 KiB)
Last sector: 2930277134 (at 1.4 TiB)
Partition size: 2930275087 sectors (1.4 TiB)
Attribute flags:
Partition name: 'Kirk01'
and the symlinks¹ are:
S:disk/by-partuuid/13005f6e-6289-4ab9-b36e-8689cf983ef5
S:disk/by-path/pci-:00:1d.7-usb-0:5:1.0-scsi-0:0:0:0-part1
S:disk/by-partlabel/Kirk01
S:disk/by-id/wwn-0x5000c5001a769150-part1
S:disk/by-id/ata-ST31500341AS_9VS3AMF3-part1
S:disk/by-uuid/beca0527-b041-4597-a585-9356f32b63a7
I'm too old to type UUIDs except by copy/paste or by completion,
and they make my head spin, so I try to use LABELs and PARTLABELs
wherever possible. It's always been a disappointment that Grub
can't write LABELs automatically in grub.cfg, so I have a little
script that translates the UUIDs into LABELs using the information
in /run/udev/data/b8:* (b259:* for my SSD). I have to rerun it
after kernel and Grub upgrades.
¹ I have a suspicion that the system is tardier about updating
the PARTLABEL symlinks than some of the others, after you
change them with the {f,g,sg}disk program. But it's only a
hunch: where it matters (ie the actual system disk), I reboot.
Cheers,
David.
Re: shame on me (was: Re: No fool like an old fool (debian installation probs))
DdB wrote: ... > I notice, that, even though i did change the name of the sda2 partition, > the PARTLABEl remained unchanged. > This proves my previous post wrong and i am sorry for the confusion, > this may have caused. You were correct all along. > DdB yes, but i also recall you saying something about zeroing a device and if you did that by accident to an entire device and not just a partition (that didn't have the boot/uefi stuff on it) then that would indeed clear any labels. so sometimes without a clear record of what has been done you do find yourself looking at a new device label and it's not fun to correct if all of your scripts and procedure are set up another way. songbird
shame on me (was: Re: No fool like an old fool (debian installation probs))
Am 02.05.2023 um 05:50 schrieb David Wright: > On Tue 02 May 2023 at 02:21:20 (+0200), DdB wrote: >> Am 01.05.2023 um 21:38 schrieb David Wright: >>> And PARTLABELs aren't interfered with even by the installer. >> >> This at least i can contradict for a fact. > > So is this post the rebuttal, or are you posting the evidence elsewhere? > >> VM is functional with known >> and documented partlabels, then the installer handles partitions >> (reformat is permitted) and the UUID's AND the PARTUUIDS were changed, >> which was a huge surprise. I cannot recall, how my impression was formed, as i did more than a dozen trial installations in the last 3 days, not all of which i kept. But a recent verification proves me wrong: from original host: > sudo blkid | grep nvm > /dev/nvme0n1p1: UUID="F497-DC20" TYPE="vfat" PARTLABEL="EFISYS" > PARTUUID="1b3d99f5-b568-4445-8a09-854bb0ed1583" > /dev/nvme0n1p2: UUID="1a4db22f-65e4-476a-b7e3-8f9f91cf0b8b" TYPE="ext4" > PARTLABEL="buster-main" PARTUUID="69941f2a-6d75-4662-b6ae-3e98425ff463" > /dev/nvme0n1p3: UUID="ec317602-8175-46b1-bced-7be335f59a01" TYPE="ext4" > PARTLABEL="SOS" PARTUUID="5f04ff28-c5e4-47c4-b9a5-c4820bb01f6a" > /dev/nvme0n1p4: LABEL="bpool" UUID="9675743913905685606" > UUID_SUB="6515248399914718640" TYPE="zfs_member" PARTLABEL="bpool" > PARTUUID="c391b3ac-4460-4dd6-92e7-3ff8def7b07b" > /dev/nvme0n1p5: LABEL="rpool" UUID="2471356229651970105" > UUID_SUB="13336611508289702781" TYPE="zfs_member" PARTLABEL="rpool" > PARTUUID="de2e5e4e-382c-4c5b-b2fd-60fcc2a71229" > /dev/nvme0n1p6: UUID="dd0919fe-8575-483c-b90a-20c7ff65e43a" TYPE="swap" > PARTLABEL="swap" PARTUUID="da10bfac-a3e4-4847-a53f-7d0547801b91" > /dev/nvme0n1: PTUUID="9c76aed7-574b-48b6-9309-62d74e5303cb" PTTYPE="gpt" from the simulating vm (ancient snapshot): > sudo blkid | grep sda > /dev/sda1: UUID="F497-DC20" TYPE="vfat" PARTLABEL="EFISYS" > PARTUUID="1b3d99f5-b568-4445-8a09-854bb0ed1583" > /dev/sda2: UUID="1a4db22f-65e4-476a-b7e3-8f9f91cf0b8b" TYPE="ext4" > PARTLABEL="buster-main" PARTUUID="69941f2a-6d75-4662-b6ae-3e98425ff463" > /dev/sda3: UUID="b9548515-9271-4d3f-91f0-d06b47375107" TYPE="ext4" > PARTLABEL="SOS" PARTUUID="5f04ff28-c5e4-47c4-b9a5-c4820bb01f6a" > /dev/sda4: PARTLABEL="bpool" PARTUUID="c391b3ac-4460-4dd6-92e7-3ff8def7b07b" > /dev/sda5: PARTLABEL="rpool" PARTUUID="de2e5e4e-382c-4c5b-b2fd-60fcc2a71229" > /dev/sda6: UUID="1fcd07ac-9764-4970-99dd-5d133b95ec67" TYPE="swap" > PARTLABEL="swap" PARTUUID="da10bfac-a3e4-4847-a53f-7d0547801b91" from the current vm (with bullseye in it): > /dev/sda1: UUID="F497-DC20" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFISYS" > PARTUUID="1b3d99f5-b568-4445-8a09-854bb0ed1583" > /dev/sda2: UUID="017cf209-aff6-45ec-a45e-bd293a34c49c" BLOCK_SIZE="4096" > TYPE="ext4" PARTLABEL="buster-main" > PARTUUID="69941f2a-6d75-4662-b6ae-3e98425ff463" > /dev/sda3: UUID="b9548515-9271-4d3f-91f0-d06b47375107" BLOCK_SIZE="4096" > TYPE="ext4" PARTLABEL="SOS" PARTUUID="5f04ff28-c5e4-47c4-b9a5-c4820bb01f6a" > /dev/sda4: PARTLABEL="bpool" PARTUUID="c391b3ac-4460-4dd6-92e7-3ff8def7b07b" > /dev/sda5: PARTLABEL="rpool" PARTUUID="de2e5e4e-382c-4c5b-b2fd-60fcc2a71229" > /dev/sda6: UUID="a2739581-96b5-45e6-91a0-d63695b61770" TYPE="swap" > PARTLABEL="swap" PARTUUID="da10bfac-a3e4-4847-a53f-7d0547801b91" I notice, that, even though i did change the name of the sda2 partition, the PARTLABEl remained unchanged. This proves my previous post wrong and i am sorry for the confusion, this may have caused. You were correct all along. DdB
Re: No fool like an old fool (debian installation probs)
On 5/1/23 17:13, DdB wrote: Am 01.05.2023 um 19:46 schrieb David Christensen: Reading the above plus your previous post "Looking for inspiration/advice/best practices on system upgrade", it seems that you are making things too complicated. I would pick one machine, disable/ disconnect/ uninstall all of the drives except optical, install a zeroed 2.5" SATA SSD, make a decision regarding BIOS/MBR (legacy) vs. UEFI/GPT, run the Setup utility and configure CMOS/NVRAM settings accordingly, boot the Debian installer, pick "Install", partition the SSD manually with a 1 GB ESP (if doing EUFI/GPT), a 1 GB boot partition (ext4), 1 GB or larger swap partition, and a 12 GB root partition (ext4), at the "Choose software" page select "SSH server", select "standard system utilities", and deselect everything else. After reboot, you should have a working Debian instance. I am sorry, i do not really understand, what you want to point to. Your suggestions are coming without even knowing, what my needs and options are, and involve alternatives that look unnecessary in my view. Just to give you an idea: my OS partitions are 20 GB and that seems to be a little too small, i had to delete stuff in order to keep the systems in good shape. I did abandon MBR years ago, and look with some bemusement at the many places, whare that old technology still lingers. Physical un-/plugging at the machines always involves getting external help, due to a handicap. Maybe your feeling is correct and i am in fact complicating things, i don't know. OTOH, i am dealing with 2 dozen disks, server grade HW, DUAL-CPU EPYC, 128 GB ECC RAM, nvme-ssd, aso. My understanding is, that precautions are in order to keep the system(s) up and running and useable for someoone, who is bad at typing. I have installed many debian VM's before, all of them with a desktop, and many of them are in use while i am investigating, how to replace/upgrade the host OS. Do you get the idea? But thanks for voicing your concerns, somthing i am trying to understand and consider. Just keep in mind, that if a problem arises, i might not be able too deal with, i will be cut off from everything, no paper based calendar even exists. So i am careful. DdB It seems like you are trying to solve several issues at the same time: 1. How to install Debian onto a computer. 2. How to upgrade a Debian 10 computer to Debian 11 when that computer supports a multitude of applications, services, and data. Solving #2 is predicated upon solving #1. I wanted to help you solve #1, so that you would be able to solve #2 -- e.g. by providing a destination for you to move applications, services, and data off the Debian 10 computer. As for your needs and options, we can only respond to the information that you provide. If a suggestion looks unnecessary, it is reasonable to ask "why?". What suggestion of mine do you find unnecessary? Choosing the size for a given partition/ volume/ file system has always been a non-trivial problem. My 12 GB root solution works for my use-cases. If a 20 GB root file system has been too small for you, then of course you can substitute a larger number into my suggestion. Another option would be to use LVM and resize as required. Thank you for letting us know that our suggestions should avoid hardware modification. In my previous post, please interpret "disable/ disconnect/ uninstall all of the drives except optical" to mean "use the Setup utility to disable all of the drives except optical". Thank you for letting us know what hardware components you have. For purposes of this thread, it is simplest to address one computer at a time. Please tell us what components it is built from, the role(s) of the computer in question, and what users/ applications/ services/ data it supports. What is "aso"? (Automated System Operations?) Regarding "precautions are in order to keep the system(s) up and running and useable for someoone, who is bad at typing", one definition of "project management" is: a. Identify where you are at. b. Identify where you want to be. c. Make a plan that takes you from (a) to (b). Plan testing prior to execution, continuity of service during plan execution (or known outage windows), validation afterwards, and rollback are desirable features of a project plan, but achieving them for a large and complex project is difficult. An obvious strategy is to decompose the scope of work into smaller projects, each requiring smaller and simpler plans. I suggest that your first priority should be making a disaster plan for "if a problem arises, i might not be able too deal with, i will be cut off from everything". A laptop, a portable USB install of Debian, and good backups come to mind. David
Re: No fool like an old fool (debian installation probs)
On Tue 02 May 2023 at 02:21:20 (+0200), DdB wrote: > Am 01.05.2023 um 21:38 schrieb David Wright: > > And PARTLABELs aren't interfered with even by the installer. > > This at least i can contradict for a fact. So is this post the rebuttal, or are you posting the evidence elsewhere? > VM is functional with known > and documented partlabels, then the installer handles partitions > (reformat is permitted) and the UUID's AND the PARTUUIDS were changed, > which was a huge surprise. OK, just so that it's clear, you have a disk with documented PARTLABELs, and after installing an OS with the d-i, the UUIDs and PARTUUIDs have been altered. You /seem/ to then be saying that /this/ is evidence that the PARTLABELs have been altered. Is that your contradiction? If the PARTUUIDs are altered, it would be interesting to know what you are doing in the partitioner step of the d-i. Your posts have only mentioned reformatting partitions, not repartitioning disks. > Just knowing about this, i can deal with the situation, but i think, > this is based on a false understanding of how a persistent > identification should be dealt with. Cheers, David.
Re: No fool like an old fool (debian installation probs)
Am 01.05.2023 um 21:38 schrieb David Wright: > And PARTLABELs aren't interfered with even by the installer. This at least i can contradict for a fact. VM is functional with known and documented partlabels, then the installer handles partitions (reformat is permitted) and the UUID's AND the PARTUUIDS were changed, which was a huge surprise. Just knowing about this, i can deal with the situation, but i think, this is based on a false understanding of how a persistent identification should be dealt with. my 2 cents DdB
Re: No fool like an old fool (debian installation probs)
Am 01.05.2023 um 19:46 schrieb David Christensen: > Reading the above plus your previous post "Looking for > inspiration/advice/best practices on system upgrade", it seems that you > are making things too complicated. > > > I would pick one machine, disable/ disconnect/ uninstall all of the > drives except optical, install a zeroed 2.5" SATA SSD, make a decision > regarding BIOS/MBR (legacy) vs. UEFI/GPT, run the Setup utility and > configure CMOS/NVRAM settings accordingly, boot the Debian installer, > pick "Install", partition the SSD manually with a 1 GB ESP (if doing > EUFI/GPT), a 1 GB boot partition (ext4), 1 GB or larger swap partition, > and a 12 GB root partition (ext4), at the "Choose software" page select > "SSH server", select "standard system utilities", and deselect > everything else. After reboot, you should have a working Debian instance. I am sorry, i do not really understand, what you want to point to. Your suggestions are coming without even knowing, what my needs and options are, and involve alternatives that look unnecessary in my view. Just to give you an idea: my OS partitions are 20 GB and that seems to be a little too small, i had to delete stuff in order to keep the systems in good shape. I did abandon MBR years ago, and look with some bemusement at the many places, whare that old technology still lingers. Physical un-/plugging at the machines always involves getting external help, due to a handicap. Maybe your feeling is correct and i am in fact complicating things, i don't know. OTOH, i am dealing with 2 dozen disks, server grade HW, DUAL-CPU EPYC, 128 GB ECC RAM, nvme-ssd, aso. My understanding is, that precautions are in order to keep the system(s) up and running and useable for someoone, who is bad at typing. I have installed many debian VM's before, all of them with a desktop, and many of them are in use while i am investigating, how to replace/upgrade the host OS. Do you get the idea? But thanks for voicing your concerns, somthing i am trying to understand and consider. Just keep in mind, that if a problem arises, i might not be able too deal with, i will be cut off from everything, no paper based calendar even exists. So i am careful. DdB
Re: No fool like an old fool (debian installation probs)
Am 01.05.2023 um 10:33 schrieb Michel Verdier:
> Le 1 mai 2023 DdB a écrit :
>
>> Any suggestions/questions/hints from the power-users in here?
>> ... would be wildly appreciated ...
>
> When installing you have to stop on your first problem. The others could
> be created from it. It's longer but easier to cope with. So give us full
> details on your first problem or choice you don't understand.
>
>
Thank you for being this clear.
In the meantime i changed my plan somewhat (as stated earlier, i am now
willing to defer the resolution of the PARTUUID topic till later, in
order to see, if the upgraded GNOME will be able to serve me well, just
as the buster one did). Also, i wanted to be certain, that i will be
able to deal with the zfs upgrade.
Today, i found, that GNOME extensions are causing quite a bit of
trouble. The cause being, that the one extension, i have been using very
extensively ("Quick-Toggler") has been orphaned and is way out of sync
with current gnome-shell. That really hurts, as it had already been a
replacement for another extension, that had been orphaned in jessie
IIRC. - This is already the second time, that i have to find adjustments
in my workflow after an upgrade, due to changing functionality and lack
of compatibility. ... makes me somewhat unhappy, as i have been involved
quite a bit in software rollout processes and we cared very much for
(paying) customer satisfaction. Ofc, this could be different in a
project based on the workforce from volunteers.
But it got even worse:
The site extensions.gnome.org let me know, that it cannot sync
extensions with my gnome-shell, because of a version mismatch. So i read
up a bit to understand, what is going on, and found the most concice
description here: (1)
Funny little detail: Ubuntu is suffering way less, because their
distribution is based on more recent version than debian stable is.
At least i saw some guy posting a video on youtube showing, how he
upgraded gnome-shell to experimental thereby creating a frankendebian,
something, i thought was an absolute no-go!
So i could not resolve the issue (You need to update
gnome-browser-connector to at least version 42.0), because the version
from debian is something like 10.1 or so.
Once again, i am happy to just playing around, not touching the
workhorse, that is still on buster, until i find a safe way forward.
zfs seems to be working fine on bullseye, the dev from the Quick-Toggler
published, that he abandonned the software due to his switch to KDE a
few years back.
Now, i am considering, if i should investigate the other desktops before
making a decision?
(1)
https://bugs.launchpad.net/ubuntu/+source/chrome-gnome-shell/+bug/1983851
Very sad, that the upgrade turns out to be rather difficult for a human
being like me, that is more or less isolated in his basement with no
friends sharing the passion for computing, or debian - for that matter.
So this is my todays report. Confused and undecided, i will head over to
get some rest now.
Ofc, i am curious to learn, how the crowd of "standard users" is dealing
with gnome extensions atm.
Re: No fool like an old fool (debian installation probs)
On Mon 01 May 2023 at 13:08:56 (+0200), DdB wrote: > One explanation of my choice to stick with PARTUUID's: > In my overall stategy of using my computer, i am sometimes copying (dd) > whole partitions into a backup, a secondary partition or a VM, which can > easily lead to difficulties, if the same LABELS were used, which can be > changed, but reside INSIDE the partition itself, whereas PARTUUID's > reside in the GPT, which is not affected on partition copy operations. PARTLABELs also reside in the GPT. > Thus my choice was related to convenience, avoiding some adjustments > after partition copy operations. Only the installer interferes with the > so called "persistent" PARTUUID's, which i regard as being offensive (or > ignorant - for that matter). And PARTLABELs aren't interfered with even by the installer. > I am going to fix that later (on my machine), returning to my preferred > fstab format of using PARTUUID whereever appropriate. Your choice, of course. This post is just FTR. Cheers, David.
Re: No fool like an old fool (debian installation probs)
On 4/30/23 18:11, DdB wrote: Hello list, after receiving so much good advice, i finally made up my mind and began playing through the installation (debian bullseye, current stable) in my simulation-VM in order to learn about the pitfalls to avoid. After more than a dozen tries, i am running out of fuel, because i am continuously running into problems, that i would have preferred to circumvent. At first, i picked a debian (debian-11.6.0-amd64-DVD-1.iso), as the 11.7 release was not yet out), and installed from there, choosing the Expert Install. The main reason was, that i was expecting to be invited into customizing the system picking software to install by hand. But at first, i ran into a multitude of problems with the partitioning tool, even though the system was already properly configured (GPT + EFISYS + OS + Swap + several other partitions booting in UEFI style). For example, when i allow the use of the swap partition, it gets reformatted and another PARTUUID is assigned to it, leading to failures booting other systems from that disk. OTOH Disallowing its use for the time being leads to install failures due to the 4GB of RAM apparently not being enough for that VM. Another problem, similar but distinctly different happens around the OS partition. Whenever i gave it to the installer, it reformatted it while changing the PARTUUID, again leading to failures in the boot process of the other partitions... Until i discovered this workaround: Assign the partition to ext4 and the mountpoint / but not allowing to delete its content (as that would induce the reformatting). Instead, after finishing partitioning, i asked for a shell and from there manually deleted ONLY THE DATA from the partition(s) used. Then installation progressed further. BTW: Apparently, this was the only way to keep the PARTUUID, as deleting the data by overwriting with zeroes lead to the installer overwriting the fs structures making another mke2fs necessary. But the worst of all, was the software selection: Even though i asked for debconf priority low, i got only a few checkboxes to pick from. And choosing GNOME did automatically install software i neither need nor want. But omitting GNOME from the list lead to a system failing to boot with tons of messages stating the absense of all kind of gnome parts. So, just in order to make some progress, i had to willingly and temporarily kill the bootability of other partitions in order to have the install terminate without failures. At that point, i decided to try the netinstall, as it is now available with release 11.7 and i did expect there to be more choices. And when even that one failed to boot without GNOME, i even did check the sha512sum to make sure, i was using the proper one. - I did! Now, i am confused. Many years ago, the expert installer was very difficult to use and did provide very many choices (and liberties to spoil the fun). Now, i dont seem to be able at coming to the stage, where i can seriously test more complicated things (like multi-boot, zfs, and other things) that make up my current host in its buster version. It is quite obvious, that i am lacking SOME kind of understanding, because what i am trying to accomplish should really be quite easy, but i am only experiencing troubles. Oh, as a side note: As a nicety of my setup, i can use bash scripts, that work well from my main OS, or from the simulation VM which can be used to test functionality before it is rolled out to the host. That is why, i am relying/insisting on absolutely identical PARTUUIDs inside that VM. Now, i am really curious as to how to get to a proper system without having to go through the baby-steps beginning with debootstrap, and all the millions of configuration steps, that i did not even bother to list. I am really interested to understand, in which way i am creating all those problems for myself. Could it be related to the fact, that i am accessing the net fom a VPN? - I don't think so. Any suggestions/questions/hints from the power-users in here? ... would be wildly appreciated ... DdB On 5/1/23 04:08, DdB wrote: > Am 01.05.2023 um 10:23 schrieb Michel Verdier: >> To install without gnome I select the task ssh server then after I >> manually select what I want, and a WM if needed. >> >> > Thank you for encouraging me. A good night sleep did help as well. > Following your advice, i retried a fresh install. This time round, i did > permit the reformatting of everything, and just noted a new todo to > resolve that later. But ... > > The install succeeded, an sshd is running ON a machine with GNOME and > all its (un-) pleasant surprises like: firefox, openoffice, and much > more. But i know for sure, that i deselected it and only left Desktop + > ssh server. I guess, that means, that the installer chose gnome as its > preferred desktop. > > Ok, i will go on from here, as i certainly want a DE + GNOME, only the > standard tools, i wouldnt have all of them. > > ==
Re: No fool like an old fool (debian installation probs)
On Mon, May 01, 2023 at 01:08:56PM +0200, DdB wrote: > Am 01.05.2023 um 10:23 schrieb Michel Verdier: > > Le 1 mai 2023 DdB a écrit : > > > >> But omitting GNOME from the list lead to a system failing to boot with > >> tons of messages stating the absense of all kind of gnome parts. > > > > To install without gnome I select the task ssh server then after I > > manually select what I want, and a WM if needed. I believe Michel actually means "I deselect all of the Debian Desktop type stuff, and then select ssh server". > Thank you for encouraging me. A good night sleep did help as well. > Following your advice, i retried a fresh install. This time round, i did > permit the reformatting of everything, and just noted a new todo to > resolve that later. But ... > > The install succeeded, an sshd is running ON a machine with GNOME and > all its (un-) pleasant surprises like: firefox, openoffice, and much > more. But i know for sure, that i deselected it and only left Desktop + > ssh server. I guess, that means, that the installer chose gnome as its > preferred desktop. If you leave "Debian Desktop" selected, the installer chooses a Desktop Environment for you. And guess which one it chooses by default? That's right: GNOME. Assuming you're using a standard installer image, and not one that has a DE in its name. I have no idea why this confusing default auto-selection exists, but it does.
No fool like an old fool (debian installation probs)
Am 01.05.2023 um 10:23 schrieb Michel Verdier: > Le 1 mai 2023 DdB a écrit : > >> But omitting GNOME from the list lead to a system failing to boot with >> tons of messages stating the absense of all kind of gnome parts. > > To install without gnome I select the task ssh server then after I > manually select what I want, and a WM if needed. > > Thank you for encouraging me. A good night sleep did help as well. Following your advice, i retried a fresh install. This time round, i did permit the reformatting of everything, and just noted a new todo to resolve that later. But ... The install succeeded, an sshd is running ON a machine with GNOME and all its (un-) pleasant surprises like: firefox, openoffice, and much more. But i know for sure, that i deselected it and only left Desktop + ssh server. I guess, that means, that the installer chose gnome as its preferred desktop. Ok, i will go on from here, as i certainly want a DE + GNOME, only the standard tools, i wouldnt have all of them. == One explanation of my choice to stick with PARTUUID's: In my overall stategy of using my computer, i am sometimes copying (dd) whole partitions into a backup, a secondary partition or a VM, which can easily lead to difficulties, if the same LABELS were used, which can be changed, but reside INSIDE the partition itself, whereas PARTUUID's reside in the GPT, which is not affected on partition copy operations. Thus my choice was related to convenience, avoiding some adjustments after partition copy operations. Only the installer interferes with the so called "persistent" PARTUUID's, which i regard as being offensive (or ignorant - for that matter). I am going to fix that later (on my machine), returning to my preferred fstab format of using PARTUUID whereever appropriate. Bonne journée DdB
Re: No fool like an old fool (debian installation probs)
Le 1 mai 2023 DdB a écrit : > Any suggestions/questions/hints from the power-users in here? > ... would be wildly appreciated ... When installing you have to stop on your first problem. The others could be created from it. It's longer but easier to cope with. So give us full details on your first problem or choice you don't understand.
Re: No fool like an old fool (debian installation probs)
Le 1 mai 2023 DdB a écrit : > But omitting GNOME from the list lead to a system failing to boot with > tons of messages stating the absense of all kind of gnome parts. To install without gnome I select the task ssh server then after I manually select what I want, and a WM if needed.
Re: No fool like an old fool (debian installation probs)
On Mon 01 May 2023 at 03:11:56 (+0200), DdB wrote: > For example, when i allow the use of the swap partition, it gets > reformatted and another PARTUUID is assigned to it, leading to failures > booting other systems from that disk. The easy way to avoid that problem is to use LABEL rather than (PART)UUID, because any time after the partitioner has run, while it's installing more of the system, you can reset the LABEL back to how you had it. # /target/sbin/swaplabel -L whatever /dev/sdXn You can set the LABEL for the new system at leisure, because the UUID that the installer used will still be working. (I parenthesised (PART)UUID because I thought the installer set and used UUIDs, not PARTUUIDs; but honestly, I might not notice if any PARTUUIDs got reset: I only use LABELs and PARTLABELs myself.) > OTOH Disallowing its use for the > time being leads to install failures due to the 4GB of RAM apparently > not being enough for that VM. I can install bullseye and bookworm-RC1 standard software (no DE) on an i386 laptop with ½GB memory using no swap, so that surprises me. > Another problem, similar but distinctly different happens around the OS > partition. Whenever i gave it to the installer, it reformatted it while > changing the PARTUUID, again leading to failures in the boot process of > the other partitions... Until i discovered this workaround: Assign the > partition to ext4 and the mountpoint / but not allowing to delete its > content (as that would induce the reformatting). Instead, after > finishing partitioning, i asked for a shell and from there manually > deleted ONLY THE DATA from the partition(s) used. Then installation > progressed further. I presume your setupp (with VMs etc) is much more complex that my own, so I can't understand why the booting process of one partition would be affected by not identifying a different system on the same machine… > BTW: Apparently, this was the only way to keep the PARTUUID, as deleting > the data by overwriting with zeroes lead to the installer overwriting > the fs structures making another mke2fs necessary. … and I don't know which data you would be zeroing. > But the worst of all, was the software selection: Even though i asked > for debconf priority low, i got only a few checkboxes to pick from. And > choosing GNOME did automatically install software i neither need nor want. > > But omitting GNOME from the list lead to a system failing to boot with > tons of messages stating the absense of all kind of gnome parts. > > So, just in order to make some progress, i had to willingly and > temporarily kill the bootability of other partitions in order to have > the install terminate without failures. > > At that point, i decided to try the netinstall, as it is now available > with release 11.7 and i did expect there to be more choices. And when > even that one failed to boot without GNOME, i even did check the > sha512sum to make sure, i was using the proper one. - I did! Yes, sorry, I don't use DEs. You might be able to find discussions in the past list archives about what's installed when you select Debian desktop environment without any DE from the list below. > Now, i am confused. Many years ago, the expert installer was very > difficult to use and did provide very many choices (and liberties to > spoil the fun). Now, i dont seem to be able at coming to the stage, > where i can seriously test more complicated things (like multi-boot, > zfs, and other things) that make up my current host in its buster version. That sounds as if you're harking back to the days when part two of installation was running dselect after a reboot. That was tedious. Since etch, it's been very much more straightforward. > It is quite obvious, that i am lacking SOME kind of understanding, > because what i am trying to accomplish should really be quite easy, but > i am only experiencing troubles. I think you might have to explain more about the overall configuration of your systems: I find it difficult to see how these booting processes interact with one another. I have PCs with up to three systems on them (buster/bullseye/bookworm), sharing /home and swap (and obviously ESP), but they depend on each other beyond the fact that each will mount the others' root filesystems (readonly) as a convenience. > Oh, as a side note: As a nicety of my setup, i can use bash scripts, > that work well from my main OS, or from the simulation VM which can be > used to test functionality before it is rolled out to the host. That is > why, i am relying/insisting on absolutely identical PARTUUIDs inside > that VM. (PART)LABELs instead? > Now, i am really curious as to how to get to a proper system without > having to go through the baby-steps beginning with debootstrap, and all > the millions of configuration steps, that i did not even bother to list. > > I am really interested to understand, in which way i am creating all > those problems for myself. Could it be related to the
No fool like an old fool (debian installation probs)
Hello list, after receiving so much good advice, i finally made up my mind and began playing through the installation (debian bullseye, current stable) in my simulation-VM in order to learn about the pitfalls to avoid. After more than a dozen tries, i am running out of fuel, because i am continuously running into problems, that i would have preferred to circumvent. At first, i picked a debian (debian-11.6.0-amd64-DVD-1.iso), as the 11.7 release was not yet out), and installed from there, choosing the Expert Install. The main reason was, that i was expecting to be invited into customizing the system picking software to install by hand. But at first, i ran into a multitude of problems with the partitioning tool, even though the system was already properly configured (GPT + EFISYS + OS + Swap + several other partitions booting in UEFI style). For example, when i allow the use of the swap partition, it gets reformatted and another PARTUUID is assigned to it, leading to failures booting other systems from that disk. OTOH Disallowing its use for the time being leads to install failures due to the 4GB of RAM apparently not being enough for that VM. Another problem, similar but distinctly different happens around the OS partition. Whenever i gave it to the installer, it reformatted it while changing the PARTUUID, again leading to failures in the boot process of the other partitions... Until i discovered this workaround: Assign the partition to ext4 and the mountpoint / but not allowing to delete its content (as that would induce the reformatting). Instead, after finishing partitioning, i asked for a shell and from there manually deleted ONLY THE DATA from the partition(s) used. Then installation progressed further. BTW: Apparently, this was the only way to keep the PARTUUID, as deleting the data by overwriting with zeroes lead to the installer overwriting the fs structures making another mke2fs necessary. But the worst of all, was the software selection: Even though i asked for debconf priority low, i got only a few checkboxes to pick from. And choosing GNOME did automatically install software i neither need nor want. But omitting GNOME from the list lead to a system failing to boot with tons of messages stating the absense of all kind of gnome parts. So, just in order to make some progress, i had to willingly and temporarily kill the bootability of other partitions in order to have the install terminate without failures. At that point, i decided to try the netinstall, as it is now available with release 11.7 and i did expect there to be more choices. And when even that one failed to boot without GNOME, i even did check the sha512sum to make sure, i was using the proper one. - I did! Now, i am confused. Many years ago, the expert installer was very difficult to use and did provide very many choices (and liberties to spoil the fun). Now, i dont seem to be able at coming to the stage, where i can seriously test more complicated things (like multi-boot, zfs, and other things) that make up my current host in its buster version. It is quite obvious, that i am lacking SOME kind of understanding, because what i am trying to accomplish should really be quite easy, but i am only experiencing troubles. Oh, as a side note: As a nicety of my setup, i can use bash scripts, that work well from my main OS, or from the simulation VM which can be used to test functionality before it is rolled out to the host. That is why, i am relying/insisting on absolutely identical PARTUUIDs inside that VM. Now, i am really curious as to how to get to a proper system without having to go through the baby-steps beginning with debootstrap, and all the millions of configuration steps, that i did not even bother to list. I am really interested to understand, in which way i am creating all those problems for myself. Could it be related to the fact, that i am accessing the net fom a VPN? - I don't think so. Any suggestions/questions/hints from the power-users in here? ... would be wildly appreciated ... DdB
Re: Re: (Thread restarted!) Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Hello everyone, I partly solved my problem and I would like to share my solution: Until now, I thought that the EFI removable media path (\EFI\BOOT\BOOTX64.EFI) is really a fallback location, i.e. a location for putting the boot loader that just always works. Therefore I thought that I could forget about EFI variables altogether if I just put the boot loader there. My recipes don't bind-mount /sys/firmware/efi/efivars for that reason. And when trying things out with the emulator, this assumption holds true, i.e. running "qemu-system-x86_64 -accel kvm -bios /usr/share/ovmf/OVMF.fd ..." will create a virtual machine that behaves like I expected. However, my Asus UX31A does things differently and insists on EFI variables being used for the internal drive, i.e. it doesn't look at the fallback location (\EFI\BOOT\BOOTX64.EFI) of the internal drive. That's the solution for the EFI boot interface, use EFI variables. For the BIOS boot interface, I'm still clueless why it doesn't work. However, I'll leave it at that. Thanks to everyone who helped! Kind regards, Valentin Caracalla
Re: (Thread restarted!) Debian installation using debootstrap and grub-install - no entry in ESC boot menu
On Thu 27 Apr 2023 at 10:18:56 (+0700), Max Nikulin wrote: > On 26/04/2023 22:57, Valentin Caracalla wrote: > > the issue with the BIOS boot interface (see my original posting) is still > > unsolved > > I had impression that there was no issue with booting in BIOS (legacy, > compatibility, CSM) mode, of course when it is chosen in firmware/BIOS > setup (requires disabling of secure boot). Well, the OP wrote: "Previously, I've successfully installed Debian using official installation media on this machine (also using BIOS boot interface), so I know that it works in principle. But now I want to do it using command line utilities like debootstrap and grub-install." But: "the problem is that the ESC boot menu doesn't show an entry for (the model name of) /dev/sda, so I can't boot into it." My first question would be whether it makes a difference to use [F2] and enter the BIOS/CMOS, rather than [ESC] to get just the boot list. As you could read in another thread, I have been testing the d-i installing on a BIOS machine, using a spare partition, in order to see how it behaves with and without a BIOS Boot partition. However, blanking the entire internal drive on a machine just for this exercise is pushing things a bit too far, sorry. And I'm not sure that results from one of /my/ machines would be particularly useful either. They are either native BIOS booters, or have a compatibility mode that just works, without requiring anything out of the ordinary configured for a GPT disk in BIOS mode. That might not be true for your Asus UX31A. At this point, my action would be to install in BIOS mode using your two methods, conventional d-i and debootstrap, and run bootinfoscript (from package boot-info-script) on each, to look for differences. I would avoid doing any UEFI booting between these runs. Cheers, David.
Re: (Thread restarted!) Debian installation using debootstrap and grub-install - no entry in ESC boot menu
On 26/04/2023 22:57, Valentin Caracalla wrote: the issue with the BIOS boot interface (see my original posting) is still unsolved I had impression that there was no issue with booting in BIOS (legacy, compatibility, CSM) mode, of course when it is chosen in firmware/BIOS setup (requires disabling of secure boot). Perhaps I confused it with qemu instead of bare metal. I tried using the EFI removable media path (which should bypass any issues with EFI variables) without success. This statement might be too strong. Internal drive is not a removable media. My impression is that you can boot from removable media (live CD), but not from internal drive. - Is booting from that internal drive enabled in firmware setup? - Is shim-signed package installed? Just shim is not enough when secure boot is enabled in firmware. I want to install Debian on my Asus UX31A UEFI implementation may have some peculiarities, likely you will find more pages: https://wiki.osdev.org/Broken_UEFI_implementations https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface#Troubleshooting I want to install it to the internal drive /dev/sda, and I want to do so by executing commands on an installer system, which is a system already installed on the external drive /dev/sdb. Does it mean that you have another linux installed and there is no issue with its booting? Is it debian? For now, I only want to get a GRUB command line, because that appears to be the difficult part. Then you do not need debian installer at all. To debug such issues it is enough to copy files to EFI/debian and to run a couple of efibootmgr commands. By the way, you have not posted "efibootmgr -v" or at least "efibootmgr" output. Running it from an existing install or a live media is OK. For the BIOS boot interface: sudo parted /dev/sda mklabel gpt sudo parted /dev/sda mkpart root 512MiB 100% sudo parted /dev/sda set 1 bios_grub on Perhaps you may create both BIOS Boot and EFI System partitions on the same disk to support both modes. For the EFI boot interface: sudo parted /dev/sda mklabel gpt sudo parted /dev/sda mkpart init 0% 512MiB sudo parted /dev/sda set 1 boot on sudo mkfs.vfat /dev/sda1 I do not remember if the "boot" flag sets proper GUID for ESP. I have heard that there may be issues if fat16 is used instead of fat32 https://www.rodsbooks.com/gdisk/booting.html file --special /dev/sda1 parted /dev/sda print sgdisk -p /dev/sda (Some people may be more familiar with output of sgdisk than parted) sudo mount --bind /sys /mnt/sys sudo mount --bind /proc /mnt/proc sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /run /mnt/run I still do not see /sys/firmware/efi/efivars here. Check /mnt/sys/firmware/efi/efivars Frankly speaking, I am confused by your description. I suspect it is a mix of - What you are going to do in future (having working install, prepare a disk for another machine or install a fresh system for the same computer) - What you are really doing - Recipe which way others may try reproduce (boot from a live media and install to an internal drive) Let's concentrate on UEFI. Unless you faced an Asus-specific issue, it should be possible to use qemu+OVMF.
(Thread restarted!) Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Hello Max, thanks a lot for your input! I do, however, believe that the problem has a different cause. I came to that conclusion, mainly because the issue with the BIOS boot interface (see my original posting) is still unsolved, but also because I tried using the EFI removable media path (which should bypass any issues with EFI variables) without success. Therefore, and to make it easier for new people entering this thread, I restart the thread now by asking my original question again, in a single and well arranged posting. You can forget everything you read in the thread before if you just read this one post: Hello everyone, I want to install Debian on my Asus UX31A using command line utilities like debootstrap and grub-install. I want to install it to the internal drive /dev/sda, and I want to do so by executing commands on an installer system, which is a system already installed on the external drive /dev/sdb. To reproduce the issue, you should use a current stable Debian Live-CD as the installer system. Just write the Live-CD image to the external drive /dev/sdb using dd. For now, I only want to get a GRUB command line, because that appears to be the difficult part. Here are the step-by-step instructions to reproduce the problem: 1.: On the installer system, type "sudo apt install ..." to install any dependencies required by the recipe (see below). 2.: On the installer system, exercise one of the following two recipes: For the BIOS boot interface: sudo parted /dev/sda mklabel gpt sudo parted /dev/sda mkpart init 0% 512MiB sudo parted /dev/sda mkpart root 512MiB 100% sudo parted /dev/sda set 1 bios_grub on sudo mkfs.ext4 /dev/sda2 sudo mount /dev/sda2 /mnt sudo debootstrap stable /mnt sudo mount --bind /sys /mnt/sys sudo mount --bind /proc /mnt/proc sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /run /mnt/run sudo chroot /mnt apt install grub-pc sudo chroot /mnt grub-install /dev/sda sudo umount /mnt/run sudo umount /mnt/dev/pts sudo umount /mnt/dev sudo umount /mnt/proc sudo umount /mnt/sys sudo umount /mnt For the EFI boot interface: sudo parted /dev/sda mklabel gpt sudo parted /dev/sda mkpart init 0% 512MiB sudo parted /dev/sda mkpart root 512MiB 100% sudo parted /dev/sda set 1 boot on sudo mkfs.vfat /dev/sda1 sudo mkfs.ext4 /dev/sda2 sudo mount /dev/sda2 /mnt sudo mkdir /mnt/boot sudo mkdir /mnt/boot/efi sudo mount /dev/sda1 /mnt/boot/efi sudo debootstrap stable /mnt sudo mount --bind /sys /mnt/sys sudo mount --bind /proc /mnt/proc sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /run /mnt/run sudo chroot /mnt apt install grub-efi sudo chroot /mnt grub-install --target=x86_64-efi /dev/sda sudo chroot /mnt grub-install --target=x86_64-efi --removable /dev/sda sudo umount /mnt/runsudo umount /mnt/dev/pts sudo umount /mnt/dev sudo umount /mnt/proc sudo umount /mnt/sys sudo umount /mnt/boot/efi sudo umount /mnt Please check every command's output before entering the next one. 3.: Shut down the installer system and disconnect the external drive /dev/sdb. 4.: Start the computer with the ESC key pressed. This will show a list of boot options (the ESC boot menu). The expected behavior is that the list contains an entry for the installed system. Selecting that entry will give you a GRUB command line. The actual behavior is that there is only the "Enter Setup" entry in the list, which is always there and does not do what we want (boot to GRUB command line). That much for the step-by-step instructions. Notice that the EFI variant of the recipe does set the "boot" and "esp" flags and the partition has the recommended size. Also notice that the EFI recipe will create the following directory structure on /dev/sda1: drwxr-xr-x 3 root root 16384 Jan 1 1970 /mnt/boot/efi drwxr-xr-x 4 root root 8192 Apr 26 09:33 /mnt/boot/efi/EFI drwxr-xr-x 2 root root 8192 Apr 26 09:33 /mnt/boot/efi/EFI/BOOT -rwxr-xr-x 1 root root 108 Apr 26 09:33 /mnt/boot/efi/EFI/BOOT/BOOTX64.CSV -rwxr-xr-x 1 root root 934240 Apr 26 09:33 /mnt/boot/efi/EFI/BOOT/BOOTX64.EFI -rwxr-xr-x 1 root root 84648 Apr 26 09:33 /mnt/boot/efi/EFI/BOOT/fbx64.efi -rwxr-xr-x 1 root root 126 Apr 26 09:33 /mnt/boot/efi/EFI/BOOT/grub.cfg -rwxr-xr-x 1 root root 3827136 Apr 26 09:33 /mnt/boot/efi/EFI/BOOT/grubx64.efi -rwxr-xr-x 1 root root 845480 Apr 26 09:33 /mnt/boot/efi/EFI/BOOT/mmx64.efi drwxr-xr-x 2 root root 8192 Apr 26 09:33 /mnt/boot/efi/EFI/debian -rwxr-xr-x 1 root root 108 Apr 26 09:33 /mnt/boot/efi/EFI/debian/BOOTX64.CSV -rwxr-xr-x 1 root root 84648 Apr 26 09:33 /mnt/boot/efi/EFI/debian/fbx64.efi -rwxr-xr-x 1 root root 126 Apr 26 09:33 /mnt/boot/efi/EFI/debian/grub.cfg -rwxr-xr-x 1 root root 4150720 Apr 26 09:33 /mnt/boot/efi/EFI/debian/grubx64.efi -rwxr-xr-x 1 root root 845480 Apr 26 09:33 /mnt/boot/efi/EFI/debian/mmx64.efi -rwxr-xr-x 1 root root 934240 Apr 26 09:33
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
David Wright (12023-04-25): > Don't knock it! The Human Era is much easier for us to parse than ;-) > the French Republican calendar (pre 2018). I had not realized I had fans devoted to the point of tracking the eras of my mail attribution. ;-)² Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Greg Wooledge (12023-04-25):
> find /mnt/boot/efi -exec ls -dl {} +
zsh
ls -dl /mnt/boot/efi/**/*
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
On Wed 26 Apr 2023 at 09:14:25 (+0700), Max Nikulin wrote: > On 26/04/2023 00:42, Nicolas George wrote: > > Steve McIntyre (12023-04-25): [ … ] > P.S. Nicolas, it seems your mailer has issues with parsing or > formatting timestamps. Don't knock it! The Human Era is much easier for us to parse than the French Republican calendar (pre 2018). Fortunately, we didn't have to deal with decimal time. Cheers, David.
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
On Wed, Apr 26, 2023 at 09:34:11AM +0700, Max Nikulin wrote:
> On 26/04/2023 05:02, Valentin Caracalla wrote:
> >
> > user@host:~$ ls -dl $(find /mnt/boot/efi)
>
> find /mnt/boot/efi -print0 | xargs -0 ls -dl --
>
> should be more resistant to peculiar file names, but it does not matter in
> this case.
find /mnt/boot/efi -exec ls -dl {} +
Also, GNU find has a -ls action, which has a different format, but is
worth a look:
find /mnt/boot/efi -ls
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
On 26/04/2023 05:02, Valentin Caracalla wrote: user@host:~$ ls -dl $(find /mnt/boot/efi) find /mnt/boot/efi -print0 | xargs -0 ls -dl -- should be more resistant to peculiar file names, but it does not matter in this case. ... -rwxr-xr-x 1 root root 126 Apr 25 13:59 /mnt/boot/efi/EFI/debian/grub.cfg -rwxr-xr-x 1 root root 4150720 Apr 25 13:59 /mnt/boot/efi/EFI/debian/grubx64.efi ... Unless firmware is buggy and it requires EFI/BOOT/BOOTX64.EFI removable layout, it should be enough (of course with other files that I removed from the quote). user@host:~$ efibootmgr -v EFI variables are not supported on this system. Either you run it from qemu booted in BIOS mode or you did not mount to chroot (I have never tried to manage EFI variables from chroot) efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime) Likely it is the reason why installer was not able to create a Boot entry and to adjust BootOrder.
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
On 26/04/2023 00:42, Nicolas George wrote: Steve McIntyre (12023-04-25): If you do not intend to install a Microsoft bootloader or anything besides GRUB, 16 megaoctets is plenty enough, probably can work with less. Please STOP giving this advice to people! That was not advice, that was information. Make your own advice with it. Unified Kernel Images are coming (kernel + initramfs e.g. to avoid separate unencrypted /boot), so even 550MiB may become too small partition in a couple of years. P.S. Nicolas, it seems your mailer has issues with parsing or formatting timestamps.
Re: Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Valentin Caracalla (12023-04-26): > EFI variables are not supported on this system. To install GRUB in UEFI, you need to have booted the kernel in UEFI. Try to find a live image that does, and you can reinstall GRUB from there. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Here's the output you requested: user@host:~$ ls -dl $(find /mnt/boot/efi) drwxr-xr-x 3 root root 32768 Jan 1 1970 /mnt/boot/efi drwxr-xr-x 3 root root 32768 Apr 25 13:59 /mnt/boot/efi/EFI drwxr-xr-x 2 root root 32768 Apr 25 13:59 /mnt/boot/efi/EFI/debian -rwxr-xr-x 1 root root 108 Apr 25 13:59 /mnt/boot/efi/EFI/debian/BOOTX64.CSV -rwxr-xr-x 1 root root 84648 Apr 25 13:59 /mnt/boot/efi/EFI/debian/fbx64.efi -rwxr-xr-x 1 root root 126 Apr 25 13:59 /mnt/boot/efi/EFI/debian/grub.cfg -rwxr-xr-x 1 root root 4150720 Apr 25 13:59 /mnt/boot/efi/EFI/debian/grubx64.efi -rwxr-xr-x 1 root root 845480 Apr 25 13:59 /mnt/boot/efi/EFI/debian/mmx64.efi -rwxr-xr-x 1 root root 934240 Apr 25 13:59 /mnt/boot/efi/EFI/debian/shimx64.efiuser@host:~$ efibootmgr -v EFI variables are not supported on this system.
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Steve McIntyre (12023-04-25): > >If you do not intend to install a Microsoft bootloader or anything > >besides GRUB, 16 megaoctets is plenty enough, probably can work with > >less. > Please STOP giving this advice to people! That was not advice, that was information. Make your own advice with it. -- Nicolas George signature.asc Description: PGP signature
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Nicolas George wrote: >Max Nikulin (12023-04-25): >> 0.5GB is usually enough, e.g. 550MiB recommended by >> https://www.rodsbooks.com/gdisk/advice.html#esp_sizing) > >If you do not intend to install a Microsoft bootloader or anything >besides GRUB, 16 megaoctets is plenty enough, probably can work with >less. Please STOP giving this advice to people! Running out of space on the ESP may cause a lot of hassle later. *Right now*, GRUB is small. But things do grow over time. Also, if anybody wants to install an extra OS, or use fwupd to install firmware updates (for example), saving a small amount of disk space here could cause a massive PITA later. -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Max Nikulin (12023-04-25): > 0.5GB is usually enough, e.g. 550MiB recommended by > https://www.rodsbooks.com/gdisk/advice.html#esp_sizing) If you do not intend to install a Microsoft bootloader or anything besides GRUB, 16 megaoctets is plenty enough, probably can work with less. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
On 25/04/2023 21:40, Valentin Caracalla wrote: I checked my partition table using "sudo parted /dev/sda print" Number Start End Size File system Name Flags 1 1049kB 128GB 128GB fat32 init boot, esp 2 128GB 256GB 128GB ext4 root Please, show ls -lA EFI/BOOT ls -lA EFI/debian residing on /dev/sda1 (128GB sounds like unreasonable large ESP partition, 0.5GB is usually enough, e.g. 550MiB recommended by https://www.rodsbooks.com/gdisk/advice.html#esp_sizing) efibootmgr -v See https://wiki.debian.org/UEFI
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
vorubergeh...@tutanota.com wrote: >By the way: > >The disadvantage of using EFI is that it doesn't work in QEMU, i.e. the >following will not show a GRUB command line: > >sudo qemu-system-x86_64 -accel kvm -smp 2 -m 2G /dev/sda > >The same thing works for the BIOS boot interface, however (as in my original >recipe). That's just qemu-system-x86_64 defaulting to using SeaBIOS for firmware. I boot VMs in UEFI mode all the time, using the EDK2 binary builds in the ovmf package. -- Steve McIntyre, Cambridge, UK.st...@einval.com < sladen> I actually stayed in a hotel and arrived to find a post-it note stuck to the mini-bar saying "Paul: This fridge and fittings are the correct way around and do not need altering"
Re: Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Valentin Caracalla (12023-04-25): > The disadvantage of using EFI is that it doesn't work in QEMU, i.e. the > following will not show a GRUB command line: > > sudo qemu-system-x86_64 -accel kvm -smp 2 -m 2G /dev/sda Oh, I must check if the KVM virtual machine booting on UEFI I have been toying with these lasts few weeks really exists then. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
By the way: The disadvantage of using EFI is that it doesn't work in QEMU, i.e. the following will not show a GRUB command line: sudo qemu-system-x86_64 -accel kvm -smp 2 -m 2G /dev/sda The same thing works for the BIOS boot interface, however (as in my original recipe).
Re: Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
I apologize for the formatting in my last post, I don't know what happened. And many thanks for your help! I checked my partition table using "sudo parted /dev/sda print" and it didn't show any flags for partition 1 (the "init" partition). Therefore I manually set the flags using "sudo parted /dev/sda set 1 boot on" and now it shows both flags, "boot" and "esp": Model: ATA ADATA XM11 256GB (scsi) Disk /dev/sda: 256GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 128GB 128GB fat32 init boot, esp 2 128GB 256GB 128GB ext4 root However, after reboot, the ESC boot menu still doesn't show an entry for the installed system.
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Valentin Caracalla writes: > But this doesn't work either. Same problem here. However I can make > such an EFI installation using official installation media on the same > machine and that does work. That recipe (and the whole post) was hard to read but don't you need some flags for the ESP partition, like esp and possibly boot as well? The partition table on one EFI system I have looks like this, I think it's probably what Debian installer created: # parted /dev/nvme0n1 print Model: KINGSTON SA2000M8250G (nvme) Disk /dev/nvme0n1: 250GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start EndSizeFile system NameFlags 1 1049kB 538MB 537MB fat32 boot, esp 2 538MB 249GB 248GB ext4Zippy root 3 249GB 250GB 1024MB linux-swap(v1) Zippy swap swap
Re: Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
> I can't see anything wrong with the script. Did that installation use> GPT > and a BIOS Boot Partition though?The successful installation (with official > installation media) used aBIOS partition table, but I prefer GPT.> I guess I > have to ask, why not just use UEFI?I also tried that and I considered posting > a similar recipe for EFI in thefirst message. But it doesn't work either, so > I thought it is better toask the question with BIOS, because it seemed easier > to me.Here's the recipe for EFI: sudo parted /dev/sda mklabel gpt sudo parted /dev/sda mkpart init 0% 50% sudo parted /dev/sda mkpart root 50% 100% sudo mkfs.vfat /dev/sda1 sudo mkfs.ext4 /dev/sda2 sudo mount /dev/sda2 /mnt sudo mkdir /mnt/boot sudo mkdir /mnt/boot/efi sudo mount /dev/sda1 /mnt/boot/efi sudo debootstrap stable /mnt sudo mount --bind /sys /mnt/sys sudo mount --bind /proc /mnt/proc sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /run /mnt/run sudo chroot /mnt apt install grub-efi sudo chroot /mnt grub-install /dev/sda sudo umount /mnt/run sudo umount /mnt/dev/pts sudo umount /mnt/dev sudo umount /mnt/proc sudo umount /mnt/sys sudo umount /mnt/boot/efi sudo umount /mntBut this doesn't work either. Same problem here. However I can make such anEFI installation using official installation media on the same machine andthat does work.
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
There are a few things I forgot to say: The recipe I posted earlier is executed on a system installed on the external drive /dev/sdb, which I call the installer system. It is also a Debian system, with the recipe's dependencies installed. To reproduce the issue (if you want), I suggest using a Debian Live-CD. After installation and before attempting to boot I unplug the external drive to make sure it doesn't interfere with the boot process. With the external drive unplugged, there should be exactly one entry in the ESC boot menu, but there is none: It only offers me to enter setup, and that is what it does when I boot without pressing ESC. Instead of booting the computer directly, I also tried booting the internal drive in a VM executed on the installer system using the following command: sudo qemu-system-x86_64 -accel kvm -smp 2 -m 2G /dev/sda This will show a GRUB command line as I expected. It just doesn't work on the real system, but in the VM it works (I hate that).
Re: Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Valentin Caracalla writes: > Previously, I've successfully installaed Debian using official > installation media on this machine (also using BIOS boot interface), > so I know that it works in principle. I can't see anything wrong with the script. Did that installation use GPT and a BIOS Boot Partition though? I guess I have to ask, why not just use UEFI?
Debian installation using debootstrap and grub-install - no entry in ESC boot menu
Hello everyone, I'm trying to install Debian on my Asus UX31A using command line utilities like debootstrap and grub-install. However, the installed system is not bootable. The problem is that the internal drive (which I install the system to) doesn't show up in the boot menu (which is what the user sees when pressing ESC during power-on). I created a minimalist recipe demonstrating the issue: sudo parted /dev/sda mklabel gpt sudo parted /dev/sda mkpart init 0% 50% sudo parted /dev/sda mkpart root 50% 100% sudo parted /dev/sda set 1 bios_grub on sudo mkfs.ext4 /dev/sda2 sudo mount /dev/sda2 /mnt sudo debootstrap stable /mnt sudo mount --bind /sys /mnt/sys sudo mount --bind /proc /mnt/proc sudo mount --bind /dev /mnt/dev sudo mount --bind /dev/pts /mnt/dev/pts sudo mount --bind /run /mnt/run sudo chroot /mnt apt install grub-pc sudo chroot /mnt grub-install /dev/sda sudo umount /mnt/run sudo umount /mnt/dev/pts sudo umount /mnt/dev sudo umount /mnt/proc sudo umount /mnt/sys sudo umount /mnt I've intentionally stripped the parts concerning installation of a kernel and creating configuration files like grub.cfg and fstab, these things work already. For now, all I want to see is that the user can get a GRUB command line after power-on. The grub-install command outputs "Installation finished. No error reported." and therefore I expect being able to boot into the GRUB command line. But again, the problem is that the ESC boot menu doesn't show an entry for (the model name of) /dev/sda, so I can't boot into it. Previously, I've successfully installed Debian using official installation media on this machine (also using BIOS boot interface), so I know that it works in principle. But now I want to do it using command line utilities like debootstrap and grub-install. Any help would be very appreciated. Kind regards, Valentin Caracalla
Re: Backing up whole Debian installation from laptop to laptop via ssh?
> For some unknown reason, network configuration (wireless networks > etc.) in NetworkManager includes the MAC address of the local NIC > too, so you may need to fix those up after transfer. This sucks, indeed. I can't understand why they do that (maybe as an option, I could see occasional uses, but as default?). Stefan
Re: Backing up whole Debian installation from laptop to laptop via ssh?
ottavio2006-usenet2...@yahoo.com wrote: >I have an old Thinkpad on its last legs which I cannot shutdown (long >story). Then I have a slightly better Thinkpad with similar hard >drive. Debian is split into three partitions (root. home and swap)/ > >I'll recreate a similar partitioning from a live usb on the newer >laptop, then I'll mount the root partition, connect to the old laptop >via ssh, copy the data on the new drive, reinstall grub and modify >fstab. > >Will this work? Sure, that should work OK. I've done this lots of times. Things to consider: 1. Be careful to back up including file permissions and ownerships etc. 2. Try to copy things from a quiet system (single-user mode or similar) to get a consistent backup copy. 3. There are a *few* things that might need fixup on the new machine. You've already identified grub and fstab. For some unknown reason, network configuration (wireless networks etc.) in NetworkManager includes the MAC address of the local NIC too, so you may need to fix those up after transfer. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Backing up whole Debian installation from laptop to laptop via ssh?
On Mon 14 Nov 2022 at 14:53:34 (+), Ottavio Caruso wrote: > I have an old Thinkpad on its last legs which I cannot shutdown (long > story). Then I have a slightly better Thinkpad with similar hard > drive. Debian is split into three partitions (root. home and swap)/ > > I'll recreate a similar partitioning from a live usb on the newer > laptop, then I'll mount the root partition, connect to the old laptop > via ssh, copy the data on the new drive, reinstall grub and modify > fstab. > > Will this work? You should check that the newer laptop boots the same way (looks like BIOS) and that you're partitioning the same way (probably MBR). Otherwise: UEFI booting would require an ESP (and complicate setting up Grub), GPT partitioning (with BIOS booting) would require a BIOS Boot partition. Cheers, David.
Re: Backing up whole Debian installation from laptop to laptop via ssh?
* On 2022 14 Nov 09:16 -0600, Ottavio Caruso wrote: > I have an old Thinkpad on its last legs which I cannot shutdown (long > story). Then I have a slightly better Thinkpad with similar hard > drive. Debian is split into three partitions (root. home and swap)/ > > I'll recreate a similar partitioning from a live usb on the newer > laptop, then I'll mount the root partition, connect to the old laptop > via ssh, copy the data on the new drive, reinstall grub and modify > fstab. > > Will this work? Yes. I've done this many times and documented it: https://www.n0nb.us/blog/2012/11/ghost-a-partition-contents-with-rsync/ - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Backing up whole Debian installation from laptop to laptop via ssh?
On 11/14/22 06:53, Ottavio Caruso wrote: I have an old Thinkpad on its last legs which I cannot shutdown (long story). Then I have a slightly better Thinkpad with similar hard drive. Debian is split into three partitions (root. home and swap)/ I'll recreate a similar partitioning from a live usb on the newer laptop, then I'll mount the root partition, connect to the old laptop via ssh, copy the data on the new drive, reinstall grub and modify fstab. Will this work? probably, depending on your method. I frequently copy the desired partitions (without modification) with Gparted to a separate physical drive... installing and updating GRUB is the only stumbling block.
Re: Backing up whole Debian installation from laptop to laptop via ssh?
> On 14 Nov 2022, at 15:15, Ottavio Caruso > wrote: > > [..] copy the data on the new drive, reinstall grub and modify > fstab. > > Will this work? Depends on what kind of “copy” you make. You will need to keep ownership, permissions and links intact. And possibly more. I would install and then copy the home drive. Peter > > -- > Ottavio Caruso > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? >
Backing up whole Debian installation from laptop to laptop via ssh?
I have an old Thinkpad on its last legs which I cannot shutdown (long story). Then I have a slightly better Thinkpad with similar hard drive. Debian is split into three partitions (root. home and swap)/ I'll recreate a similar partitioning from a live usb on the newer laptop, then I'll mount the root partition, connect to the old laptop via ssh, copy the data on the new drive, reinstall grub and modify fstab. Will this work? -- Ottavio Caruso A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
Re: Converting a BIOS (CSM) Debian installation into UEFI
On Tue 15 Feb 2022 at 14:20:55 (-0500), Felix Miata wrote: > David Wright composed on 2022-02-15 10:11 (UTC-0600): > > > Is anything else required for B to become a "native EFI" installation? > > > This conversion process will, I think, make the system boot into > > the EFI-ed B by default. If I want to make E boot by default again, > > should I boot E and run update-grub and grub-install?³ > > Or should I do this by running efibootmgr? > > Without changing GRUB_DISTRIBUTOR= in /etc/default/grub, you'll wind up with > only > /boot/efi/EFI/debian. It will be just like MBR booting, where the last updated > Grub overwrites what the previous one put in the MBR. I avoid this by > changing the > default > > GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` > > to e.g. > > GRUB_DISTRIBUTOR="bookworm" That was useful — I hadn't realised the connection between that variable and the directory name in EFI/. It's quite tricky pulling all the threads together: the directory layout in EFI/, all the stuff that's in /sys/firmware/efi/efivars, the efibootmgr's listing, and the contents (and actions) of the EFI menus when you boot into the firmware interface (reached with Esc F9 here, IIRC). > Once you have a unique /boot/efi/EFI/ entry for each installation, you > /should/ be > able to switch which has control either in the BIOS directly, or with > efibootmgr. > Likely update-grub and grub-install would do the same thing, but I've never > given > them the opportunity here. I say /should/ because some UEFI BIOS are finicky > beasts that can't always be trusted to do as expected. > > I avoid the issue of priority usurpation in two ways: > 1-only mount the ESP filesystem to /boot/efi/ on one installation > 2-don't install any bootloader I think I've decided to keep mine simple by: . booting into one primary system from the ESP, . only that primary system has /boot/efi/EFI/ mounted (your 1), . no Grub on the non-primary systems (your 2), . the primary's Grub will choose which system to boot. I'm used to using grubenv for one-time boot selection, even when I'm not at the machine, but am happy to use the EFI menus whenever I need to boot from a stick, etc. > I actually boot from /boot/grub/custom.cfg, by copying /etc/grub.d/40_custom > to > 06_custom. This causes grub-mkconfig to generate a grub.cfg that displays my > custom.cfg entries before its auto-generated entries, minimizing need to > scroll > the menu to find a desired selection. My custom.cfg boots via kernel and > initrd > symlinks (and volume LABEL rather than UUID, same as fstab), so infrequently > has > any need to be updated. Note that my use of singular filenames is inaccurate, > as I > have 5 UEFI systems configured this way, and all have 10 or more Linux > installations. I'll probably go through another iteration of my edgrub script, to reduce even more of the "garbage" in grub.cfg. Thanks for the suggestions. Cheers, David.
Re: Converting a BIOS (CSM) Debian installation into UEFI
David Wright composed on 2022-02-15 10:11 (UTC-0600): > Is anything else required for B to become a "native EFI" installation? > This conversion process will, I think, make the system boot into > the EFI-ed B by default. If I want to make E boot by default again, > should I boot E and run update-grub and grub-install?³ > Or should I do this by running efibootmgr? Without changing GRUB_DISTRIBUTOR= in /etc/default/grub, you'll wind up with only /boot/efi/EFI/debian. It will be just like MBR booting, where the last updated Grub overwrites what the previous one put in the MBR. I avoid this by changing the default GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian` to e.g. GRUB_DISTRIBUTOR="bookworm" Once you have a unique /boot/efi/EFI/ entry for each installation, you /should/ be able to switch which has control either in the BIOS directly, or with efibootmgr. Likely update-grub and grub-install would do the same thing, but I've never given them the opportunity here. I say /should/ because some UEFI BIOS are finicky beasts that can't always be trusted to do as expected. I avoid the issue of priority usurpation in two ways: 1-only mount the ESP filesystem to /boot/efi/ on one installation 2-don't install any bootloader I actually boot from /boot/grub/custom.cfg, by copying /etc/grub.d/40_custom to 06_custom. This causes grub-mkconfig to generate a grub.cfg that displays my custom.cfg entries before its auto-generated entries, minimizing need to scroll the menu to find a desired selection. My custom.cfg boots via kernel and initrd symlinks (and volume LABEL rather than UUID, same as fstab), so infrequently has any need to be updated. Note that my use of singular filenames is inaccurate, as I have 5 UEFI systems configured this way, and all have 10 or more Linux installations. -- 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
Converting a BIOS (CSM) Debian installation into UEFI
With the threads on "Stupid question" and "Throw an hard drive" in d-u at the moment, this seems timely: I have a drive which contains two Debian installations, one of which (B) was installed for BIOS booting, and the other (E) was installed with EFI booting. I would like to convert B into a EFI system too. ¹ Each system has its own Grub installation, and os-prober has inserted entries for both systems into both systems. Consequently this means that I can boot in EFI-mode and run B, and I can boot in BIOS-mode and run E. As far as I can tell, the process for B to EFI should just involve: . boot B in EFI mode . mkdir /boot/efi/ . add it to /etc/fstab . mount the ESP onto it . remove grub-pc, grub-pc-bin . install (with Recommends) grub-efi-amd64, grub-efi-amd64-bin, grub-efi-amd64-signed, shim-signed, shim-signed-common, shim-helpers-amd64-signed, shim-unsigned . run update-grub . run grub-install (which should now modify /boot/efi, not the MBR). Is anything else required for B to become a "native EFI" installation? This conversion process will, I think, make the system boot into the EFI-ed B by default. If I want to make E boot by default again, should I boot E and run update-grub and grub-install?³ Or should I do this by running efibootmgr? -- ¹ More details: B was installed for dual-booting with EFI Windows, by switching into the BIOS (CMS) for booting B. Since then, Windows and almost all its entrails (various recovery, data and reserved partitions) ² have been overwritten with Debian installation E. The disk has all the necessary components: GPT partitioning, with a protective MBR and BIOS boot partition for B's use, and the original ESP for E's (and B's future) use, plus shared /home (encrypted), and a random encrypted swap. ² The ESP still has a "fossil" EFI/Microsoft/Boot/bootmgfw.efi file which merely causes grub-efi (through os-prober) to write a useless (but benign) entry in grub.cfg. ³ With totally BIOS systems, if I wanted a system "A" to be the default system when booted, I could boot A and run update-grub and grub-install. This would preen A's grub.cfg, and make the protective MBR boot to it. Cheers, David.
Re: Throw an hard drive with Debian installation into...
On Tue, Feb 15, 2022 at 12:31:58PM +0200, Anssi Saari wrote: > Thomas Anderson writes: > > > I am curious, what would happen if I threw a fully functionally, > > > > Linux installation (HDD) into an entirely different hardware configuration: > > > > Different Process AMD->Intel? > > > > Ram/mobo I assume doesn't matter? > > > > I half expect it to boot up, and be fully functional. > > I fully expect this to work. It has for me in the past. Of course, with > no knowledge of your systems the answer is actually "it depends." But > even when I ran a custom kernel with just the drivers I needed, all I > needed to do was add the drivers the new system needed beforehand. This > was the bad old days when there were other common SATA interfaces than > AHCI. > > In fact, I have the inner parts for a new desktop waiting as I want to > do more than just clone my old system there. I've come to realize I want > to build the new system in a new case so that I can work on it while > keeping my old system running. > > But still, the first step for me is cloning my boot SSD and putting it > in the new system. I'll have little difference in the old and new > desktop. CPU architecture is still x86-64, video is same NVidia, storage > is same old AHCI SATA + NVMe SSD. So it should boot. Networking is > different and will need a firmware package, maybe a newer kernel from > backports. Wifi and bluetooth are new and likely need same. I can > actually do these things beforehand. > Maybe don't do this. Maybe do a clean install on new drives to start a known system. Then you can copy across stuff from old system to new moving only the data you want. Clean installs mean that the drivers for the new motherboard etc. should "just work" > Probably some other minor interfaces will need tweaking, sensors is a > thing that's usually different on different motherboards for example. > See above. > The second step for me is converting from FAT partition table and BIOS > boot to GPT partition table and UEFI boot. Should be possible but with > Windows 10, Debian and Arch on the drive it's a tiny little bit more > complicated. > Too complicated once you've cloned an MBR - really, don't do this, go UEFI from the start. Maybe don't install Windows 10 as a main OS but as a VM? All the very best, as ever, Andy Cater
Re: Throw an hard drive with Debian installation into...
Thomas Anderson writes: > I am curious, what would happen if I threw a fully functionally, > > Linux installation (HDD) into an entirely different hardware configuration: > > Different Process AMD->Intel? > > Ram/mobo I assume doesn't matter? > > I half expect it to boot up, and be fully functional. I fully expect this to work. It has for me in the past. Of course, with no knowledge of your systems the answer is actually "it depends." But even when I ran a custom kernel with just the drivers I needed, all I needed to do was add the drivers the new system needed beforehand. This was the bad old days when there were other common SATA interfaces than AHCI. In fact, I have the inner parts for a new desktop waiting as I want to do more than just clone my old system there. I've come to realize I want to build the new system in a new case so that I can work on it while keeping my old system running. But still, the first step for me is cloning my boot SSD and putting it in the new system. I'll have little difference in the old and new desktop. CPU architecture is still x86-64, video is same NVidia, storage is same old AHCI SATA + NVMe SSD. So it should boot. Networking is different and will need a firmware package, maybe a newer kernel from backports. Wifi and bluetooth are new and likely need same. I can actually do these things beforehand. Probably some other minor interfaces will need tweaking, sensors is a thing that's usually different on different motherboards for example. The second step for me is converting from FAT partition table and BIOS boot to GPT partition table and UEFI boot. Should be possible but with Windows 10, Debian and Arch on the drive it's a tiny little bit more complicated.
Re: Throw an hard drive with Debian installation into...
Thanks for replies. It all makes sense once I get the answers. =) On 2/15/22 07:29, to...@tuxteam.de wrote: On Tue, Feb 15, 2022 at 01:58:24AM +0100, Thomas Anderson wrote: I am curious, what would happen if I threw a fully functionally, Linux installation (HDD) into an entirely different hardware configuration: It depends :-) It starts with the bootloader: different hardware boots in very different ways. If you have GRUB (the default with Debian), you will need either a "traditional BIOS" or UEFI beneath it. That means MACs, Raspberry Pis and other misc hardware is out. Then, the kernel is built for a specific architecture family. A kernel built for x86_64 won't be happy on ARM. Or RISCV. Or... If your distro has taken those hurdles, you'll still be left with some funny things. Kernel modules for hardware you hadn't in your first motherboard. Network scripts might be set up to look for a specific MAC address which won't "be" in your new machine. Your fstab might be referencing file systems which have moved around (this is one of the cases where label based or UUID based file system referencing clearly "wins"). In the latter cases, chances are good that you'll get enough of your system up to "fix" things. Be prepared to invest some time, and to learn a thing or two :-) Cheers
Re: Throw an hard drive with Debian installation into...
On Tue, Feb 15, 2022 at 01:58:24AM +0100, Thomas Anderson wrote: > I am curious, what would happen if I threw a fully functionally, > > Linux installation (HDD) into an entirely different hardware configuration: It depends :-) It starts with the bootloader: different hardware boots in very different ways. If you have GRUB (the default with Debian), you will need either a "traditional BIOS" or UEFI beneath it. That means MACs, Raspberry Pis and other misc hardware is out. Then, the kernel is built for a specific architecture family. A kernel built for x86_64 won't be happy on ARM. Or RISCV. Or... If your distro has taken those hurdles, you'll still be left with some funny things. Kernel modules for hardware you hadn't in your first motherboard. Network scripts might be set up to look for a specific MAC address which won't "be" in your new machine. Your fstab might be referencing file systems which have moved around (this is one of the cases where label based or UUID based file system referencing clearly "wins"). In the latter cases, chances are good that you'll get enough of your system up to "fix" things. Be prepared to invest some time, and to learn a thing or two :-) Cheers -- t signature.asc Description: PGP signature
Re: Throw an hard drive with Debian installation into...
On 2022-02-14 19:58, Thomas Anderson wrote: > I am curious, what would happen if I threw a fully functionally, > > Linux installation (HDD) into an entirely different hardware configuration: > > Different Process AMD->Intel? > > Ram/mobo I assume doesn't matter? > > I half expect it to boot up, and be fully functional. > > But, I have not tested it. > > I am not mailing the list this question, as a theoretically. I would > actually > > like to upgrade my hardware, as the gains would be Ok (32GB Ram >16GB), > > but would not be drastic, so I wouldn't bother if I had to re-setup all the > > software again. > If you have the required driver inside your kernel or in the initrd then you shouldn't have any problem. As a easy example, you boot using the install DVD/USB stick and a unique kernel is used for both AMD/Intel x64. You may need some configuration of network card and other things if their reference change. That's all... -- Polyna-Maude R.-Summerside -Be smart, Be wise, Support opensource development OpenPGP_signature Description: OpenPGP digital signature
Throw an hard drive with Debian installation into...
I am curious, what would happen if I threw a fully functionally, Linux installation (HDD) into an entirely different hardware configuration: Different Process AMD->Intel? Ram/mobo I assume doesn't matter? I half expect it to boot up, and be fully functional. But, I have not tested it. I am not mailing the list this question, as a theoretically. I would actually like to upgrade my hardware, as the gains would be Ok (32GB Ram >16GB), but would not be drastic, so I wouldn't bother if I had to re-setup all the software again.
Re: Debian installation doesn't see my network
Am Montag, 10. Januar 2022, 16:21:25 CET schrieb Eric S Fraga: Had a similar issue with a notebook from Dell some time ago. The reason was, that the binary firmware did not exist on on the installer cdrom or dvd. The network interface was just too new! This is a problem with debian's policy and installer isos: They are sometimes too old for newer hardware. And also the installer kernel is sometimes too old for modern hardware. My solution would be, to put the latest kernel and all latest firmware and whatever the modern hardware needs, to be recognized, fort installation. After the installation has finished, the installer could deinstall all unneeded staff. Yes, I know, this is not debian style, but would be my style. Don't anger at me. Best Hans > On Saturday, 8 Jan 2022 at 20:07, Andrew M.A. Cater wrote: > > If you can bear it: reinstall, using the unofficial image, including > > non-free firmware. > > I had to do this for a recently purchased Dell laptop with Intel NIC > on-board. Worked just fine this way but wouldn't install without the > non-free firmware as it couldn't find the network.
Re: Debian installation doesn't see my network
On Saturday, 8 Jan 2022 at 20:07, Andrew M.A. Cater wrote: > If you can bear it: reinstall, using the unofficial image, including > non-free firmware. I had to do this for a recently purchased Dell laptop with Intel NIC on-board. Worked just fine this way but wouldn't install without the non-free firmware as it couldn't find the network. -- Eric S Fraga with org 9.5.2 in Emacs 29.0.50 on Debian 11.2
Re: Debian installation doesn't see my network
sciguy composed on 2022-01-08 12:13 (UTC-0500): > It seems the root of my problem is in Microsoft's choice to take over > the EFI in a recent update, thereby supplanting GRUB, which was there > before. GRUB was a technology I understood fairly well; EFI is not. Can > anyone suggest, or point to some resources, for how to install Linux > alongside W10, in a way that the EFI appears to recognize (since it > seemed to almost accidentally with Debian). A UEFI BIOS is _much_ more competent than a legacy BIOS, and plays a larger part of the boot process. With UEFI-only mode selected in the BIOS (CSM disabled), all Windows would have done is change which entry on the ESP filesystem is read when the PC is booted, by changing the BIOS boot priority order. Go into BIOS and you /should/ see a place in the boot category to move a Linux installation to the top of the order, if any Linux installation was sufficiently completed. Alternatively, booted in UEFI mode to Linux, the efibootmgr command can reorder the boot priorities in the BIOS. Grub doesn't participate in the UEFI boot process until after the BIOS loads from an ESP partition a file that an OS has installed there. Windows won't touch a file created by Linux, and Linux won't touch a file created by Windows. -- 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: Debian installation doesn't see my network
On Sat, Jan 08, 2022 at 12:13:41PM -0500, sciguy wrote: > This has happened with what I have tried so far: Debian and Ubuntu. I have > been accustomed to my network card being auto-detected and the internet > being automatically connected with an installation, but I am not getting > internet on installation, so much of the installation has failed. > > This machine was set up as a dual boot, and is running Windows 10 with the > latest updates. It has previously run a version of Ubuntu Studio, but with > this upgrade (first by USB then by DVD), I am not getting a network, and so > the installation remains half-finished. > > Somehow, after changing this over to Debian, where the installation failed > for the same reason, Windows 10 EFI detected the incomplete installation and > now offers "finishing the Debian installation" as a boot option when I > reboot. > > It seems the root of my problem is in Microsoft's choice to take over the > EFI in a recent update, thereby supplanting GRUB, which was there before. > GRUB was a technology I understood fairly well; EFI is not. Can anyone > suggest, or point to some resources, for how to install Linux alongside W10, > in a way that the EFI appears to recognize (since it seemed to almost > accidentally with Debian). > > For the record, the motherboard is an ASUS Maximus VI Hero with an onboard > Intel NIC (Intel Ethernet Connection I217-V). The processor is an Intel Core > I7-4770K (Haswell). > > It needs to go online for at least the video drivers (I have NVIDIA and a > dual monitor), and I am hoping that it is not needing to go online for the > network driver. > > Thanks > > Paul > If you can bear it: reinstall, using the unofficial image, including non-free firmware. https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.2.0+nonfree/amd64/iso-cd/firmware-11.2.0-amd64-netinst.iso or https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.2.0+nonfree/amd64/iso-dvd/firmware-11.2.0-amd64-DVD-1.iso If you can, use an expert install and use text mode. If you need to install non-free drivers, it may be easier to install text mode and then to configure the Nvidia non-free drivers before using tasksel to install a desktop environment. The non-free firmware iso includes drivers for many of the common wifi chipsets but if you can use Ethernet to install with, you may find it easier. If you install the Debian to the backstop location in EFI, it should co-exist with the Microsoft UEFI install that you already have. All the very best, as ever, Andy Cater
Re: Debian installation doesn't see my network
On 1/8/22 19:13, sciguy wrote: > This has happened with what I have tried so far: Debian and Ubuntu. I > have been accustomed to my network card being auto-detected and the > internet being automatically connected with an installation, but I am > not getting internet on installation, so much of the installation has > failed. > > This machine was set up as a dual boot, and is running Windows 10 with > the latest updates. It has previously run a version of Ubuntu Studio, > but with this upgrade (first by USB then by DVD), I am not getting a > network, and so the installation remains half-finished. > > Somehow, after changing this over to Debian, where the installation > failed for the same reason, Windows 10 EFI detected the incomplete > installation and now offers "finishing the Debian installation" as a > boot option when I reboot. > > It seems the root of my problem is in Microsoft's choice to take over > the EFI in a recent update, thereby supplanting GRUB, which was there > before. GRUB was a technology I understood fairly well; EFI is not. Can > anyone suggest, or point to some resources, for how to install Linux > alongside W10, in a way that the EFI appears to recognize (since it > seemed to almost accidentally with Debian). > > For the record, the motherboard is an ASUS Maximus VI Hero with an > onboard Intel NIC (Intel Ethernet Connection I217-V). The processor is > an Intel Core I7-4770K (Haswell). > > It needs to go online for at least the video drivers (I have NVIDIA and > a dual monitor), and I am hoping that it is not needing to go online for > the network driver. > Hi sciguy, I'm not sure that UEFI/BIOS mode is the reason for not connecting to Internet but check in which mode Debian installer recognize the system during initial screen menu. Here are two screenshots BIOS mode - https://ibb.co/Q8yvyYz EFI mode - https://ibb.co/pKfpcQp if you want EFI mode try to disable compatibility mode in UEFI. If you want BIOS mode then enable compatibility mode in UEFI. Kind regards Georgi
Debian installation doesn't see my network
This has happened with what I have tried so far: Debian and Ubuntu. I have been accustomed to my network card being auto-detected and the internet being automatically connected with an installation, but I am not getting internet on installation, so much of the installation has failed. This machine was set up as a dual boot, and is running Windows 10 with the latest updates. It has previously run a version of Ubuntu Studio, but with this upgrade (first by USB then by DVD), I am not getting a network, and so the installation remains half-finished. Somehow, after changing this over to Debian, where the installation failed for the same reason, Windows 10 EFI detected the incomplete installation and now offers "finishing the Debian installation" as a boot option when I reboot. It seems the root of my problem is in Microsoft's choice to take over the EFI in a recent update, thereby supplanting GRUB, which was there before. GRUB was a technology I understood fairly well; EFI is not. Can anyone suggest, or point to some resources, for how to install Linux alongside W10, in a way that the EFI appears to recognize (since it seemed to almost accidentally with Debian). For the record, the motherboard is an ASUS Maximus VI Hero with an onboard Intel NIC (Intel Ethernet Connection I217-V). The processor is an Intel Core I7-4770K (Haswell). It needs to go online for at least the video drivers (I have NVIDIA and a dual monitor), and I am hoping that it is not needing to go online for the network driver. Thanks Paul
Re: New debian installation disk partition
On 10/12/21 21:47, Andrei POPESCU wrote: On Ma, 12 oct 21, 00:02:50, David Christensen wrote: On 10/11/21 23:58, Andrei POPESCU wrote: On Lu, 11 oct 21, 13:56:28, David Christensen wrote: On 10/11/21 13:39, Andrei POPESCU wrote: ZFS has native encryption now, any particular reason to prefer using a LUKS container instead? I use LUKS because ZFS native encryption was not available OOTB the last time I looked on Debian. What version of d-i has ZFS native encryption? I wasn't aware of any kind of support for ZFS in d-i. If d-i does not have native support for ZFS encryption, then when I break my computer I will be unable to use the d-i media to access my disk(s). The Debian Installer doesn't have support for ZFS at all, so it's use to rescue for root-on-ZFS systems is limited, at best, regardless of the encryption. AFAIK d-i as of version 10 does not support ZFS in any way, so I do not use ZFS on Debian. David
Re: New debian installation disk partition
On Ma, 12 oct 21, 00:02:50, David Christensen wrote: > On 10/11/21 23:58, Andrei POPESCU wrote: > > On Lu, 11 oct 21, 13:56:28, David Christensen wrote: > > > On 10/11/21 13:39, Andrei POPESCU wrote: > > > > > ZFS has native encryption now, any particular reason to prefer using a > > > > LUKS container instead? > > > > > > I use LUKS because ZFS native encryption was not available OOTB the last > > > time I looked on Debian. What version of d-i has ZFS native encryption? > > > > I wasn't aware of any kind of support for ZFS in d-i. > > If d-i does not have native support for ZFS encryption, then when I break my > computer I will be unable to use the d-i media to access my disk(s). The Debian Installer doesn't have support for ZFS at all, so it's use to rescue for root-on-ZFS systems is limited, at best, regardless of the encryption. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: New debian installation disk partition
On Mon, 11 Oct 2021 14:03:50 -0700 David Christensen wrote: > On 10/11/21 13:13, Joe wrote: > > On Mon, 11 Oct 2021 12:29:48 -0700 > > David Christensen wrote: > > > > > >> I must detach e-mail attachments and save them on the server > > > > You could run an IMAP server on your server, set up an account in > > your email client with a suitable directory structure and drag and > > drop old email into archives, complete with attachments, so > > everything remains online. Many email clients can do this fairly > > automatically. > > > > It's easier still if you run a full MTA on the server, and don't use > > local email accounts at all, but many people don't want the (very > > minimal) maintenance needs. > > > I hosted WWW and NWN servers at my home many years ago. Bad idea. > > > I have domain hosting through he.net, and prefer their professionally > managed e-mail. > > Yes, I would never consider running a public web server, I know just enough about web security to know that I don't know anything like enough to keep it secure. But I don't expose the IMAP server, either, it's internal only. I get to it by ssh or vpn while away from home. It's less convenient, but less to worry about. -- Joe
Re: New debian installation disk partition
On 10/11/21 23:58, Andrei POPESCU wrote: On Lu, 11 oct 21, 13:56:28, David Christensen wrote: On 10/11/21 13:39, Andrei POPESCU wrote: ZFS has native encryption now, any particular reason to prefer using a LUKS container instead? I use LUKS because ZFS native encryption was not available OOTB the last time I looked on Debian. What version of d-i has ZFS native encryption? I wasn't aware of any kind of support for ZFS in d-i. If d-i does not have native support for ZFS encryption, then when I break my computer I will be unable to use the d-i media to access my disk(s). Therefore, I prefer a LUKS container. David
Re: New debian installation disk partition
On Lu, 11 oct 21, 13:56:28, David Christensen wrote: > On 10/11/21 13:39, Andrei POPESCU wrote: > > On Lu, 11 oct 21, 12:29:48, David Christensen wrote: > > > > > > Once Debian is running, I suggest that you connect the HDD, partition the > > > HDD using GPT, create one partition using 95% of available space, > > > initialize > > > a LUKS container inside the partition, and create a ZFS pool with name > > > "data" and with option "copies=2" using the encrypted mapper node. The > > > zpool will be mounted at "/data", will be able to store ~237 GB, and ZFS > > > will be able to survive "one or a few" sectors going bad without any data > > > loss (it is wise to scrub periodically). > > > > ZFS has native encryption now, any particular reason to prefer using a > > LUKS container instead? > > I use LUKS because ZFS native encryption was not available OOTB the last > time I looked on Debian. What version of d-i has ZFS native encryption? I wasn't aware of any kind of support for ZFS in d-i. The Debian ZFS wiki page doesn't mention root-on-ZFS at all and the official upstream instructions (for buster) are using debootstrap from a live image for installation. https://wiki.debian.org/ZFS https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: New debian installation disk partition
On 10/11/21 13:13, Joe wrote: On Mon, 11 Oct 2021 12:29:48 -0700 David Christensen wrote: I must detach e-mail attachments and save them on the server You could run an IMAP server on your server, set up an account in your email client with a suitable directory structure and drag and drop old email into archives, complete with attachments, so everything remains online. Many email clients can do this fairly automatically. It's easier still if you run a full MTA on the server, and don't use local email accounts at all, but many people don't want the (very minimal) maintenance needs. I hosted WWW and NWN servers at my home many years ago. Bad idea. I have domain hosting through he.net, and prefer their professionally managed e-mail. Yes, detaching can get tedious, but I am wary of attempting to automate such and it's not a huge burden. David
Re: New debian installation disk partition
On 10/11/21 13:39, Andrei POPESCU wrote: On Lu, 11 oct 21, 12:29:48, David Christensen wrote: Once Debian is running, I suggest that you connect the HDD, partition the HDD using GPT, create one partition using 95% of available space, initialize a LUKS container inside the partition, and create a ZFS pool with name "data" and with option "copies=2" using the encrypted mapper node. The zpool will be mounted at "/data", will be able to store ~237 GB, and ZFS will be able to survive "one or a few" sectors going bad without any data loss (it is wise to scrub periodically). ZFS has native encryption now, any particular reason to prefer using a LUKS container instead? I use LUKS because ZFS native encryption was not available OOTB the last time I looked on Debian. What version of d-i has ZFS native encryption? David
Re: New debian installation disk partition
On Lu, 11 oct 21, 12:29:48, David Christensen wrote: > > Once Debian is running, I suggest that you connect the HDD, partition the > HDD using GPT, create one partition using 95% of available space, initialize > a LUKS container inside the partition, and create a ZFS pool with name > "data" and with option "copies=2" using the encrypted mapper node. The > zpool will be mounted at "/data", will be able to store ~237 GB, and ZFS > will be able to survive "one or a few" sectors going bad without any data > loss (it is wise to scrub periodically). ZFS has native encryption now, any particular reason to prefer using a LUKS container instead? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: New debian installation disk partition
On Mon, 11 Oct 2021 12:29:48 -0700 David Christensen wrote: > I must detach > e-mail attachments and save them on the server You could run an IMAP server on your server, set up an account in your email client with a suitable directory structure and drag and drop old email into archives, complete with attachments, so everything remains online. Many email clients can do this fairly automatically. It's easier still if you run a full MTA on the server, and don't use local email accounts at all, but many people don't want the (very minimal) maintenance needs. -- Joe
Re: New debian installation disk partition
On 10/11/21 04:18, Josef Strýček wrote: Hi, I have a question how to partition new debain installation.I have 64GB ssd and 500GB hdd. Can I have / on ssd with ext4 and hdd with btrfs /hame /var /tmp /opt. You should be able to achieve that layout with the Debian installer (d-i) by choosing "Partitioning method" -> "manual". I ran btrfs for a few years, but did not understand the maintenance requirements. Over time, the disks became slow and slower. Eventually, I had to learn about btrfs balancing, write Perl script to perform it, and run the script repeatedly to recover and maintain the disks. Eventually, I got lazy and reinstalled using ext4. Could you recommend layout for ssd and hdd, that ssd is not overwritten unnecessarily and ideal filesystem for ssd and hdd. When SSD's first came out, there was a lot of fuss about minimizing wear and maximizing performance -- disabling swap, over-provisioning, trim, etc.. Since then, SSD's have improved and operating systems have become better at using SSD's. So, I would not worry about Debian wearing out the SSD; just run d-i and let it do the work. Once the system is in operation, some people like to run fstrim(8) periodically (e.g. monthly, weekly). A key idea that still applies is that your OS and applications should be on one disk and your data should be on another disk. I use SSD's for OS disks (including /home) and I keep the vast majority of my data in a file server (Samba) on HDD's in a ZFS mirror. A killer feature of d-i is that it can build OS disks with encryption. But, a plaintext "/boot" partition is required to boot the computer. I prefer to keep my OS images small enough to fit onto "16 GB" devices. This facilitates imaging, cloning, and disaster preparedness. I can save 3 monthly images for 6 computers on a 300 GB USB HDD. But, there is only one active user account on each machine, I must limit how much software I install, I must detach e-mail attachments and save them on the server, and I must keep my home directory usage at a minimum. Here are my disk partitioning notes from when I installed my Debian 10 daily driver: Partitioning method manual Encrypted volume (sda2_crypt) - 1.0 GB Linux device-mapper (crypt) #1 1.0 GB f swap swap Encrypted volume (sda3_crypt) - 13.0 GB Linux device-mapper (crypt) #113.0 GB f ext4 / SCSI5 (0,0,0) (sda) - 60.0 GB ATA INTEL SSDSC2CW06 #1 primary 999.3 MB B F ext4 /boot #2 primary1.0 GB K crypto (sda2_crypt) #3 primary 13.0 GB K crypto (sda3_crypt) 45.0 GBFREESPACE Finish partitioning and write changes to disk Notes: 1. I am using MBR partitioning, because some of my computers are 14 years old and MBR is the lowest common denominator. I can build a Debian OS disk in one computer and then move the disk (or image) to another computer. (The partition scheme chosen by the d-i is determined by the firmware mode of the computer running d-i -- e.g. BIOS -> MBR, EUFI -> GPT.) 2. Partition #1 is 1 GB, plaintext ext4 /boot 3. Partition #2 is 1 GB, encrypted swap (random key) 4. Partition #3 is 13 GB, encrypted ext4 root (passphrase) I suggest that you disconnect the HDD (both power and data cables) and install Debian onto the SSD similar to the above. It is best if the SSD has device node /dev/sda. You may want a larger root partition. It is important to have a swap partition; do not eliminate it. Once Debian is running, I suggest that you connect the HDD, partition the HDD using GPT, create one partition using 95% of available space, initialize a LUKS container inside the partition, and create a ZFS pool with name "data" and with option "copies=2" using the encrypted mapper node. The zpool will be mounted at "/data", will be able to store ~237 GB, and ZFS will be able to survive "one or a few" sectors going bad without any data loss (it is wise to scrub periodically). David
Re: New debian installation disk partition
Hi Josef, On Mon, Oct 11, 2021 at 01:18:55PM +0200, Josef Strýček wrote: > I have a question how to partition new debain installation.I have 64GB ssd > and 500GB hdd. Can I have / on ssd with ext4 and hdd with btrfs /hame /var Of course. > /tmp /opt. Could you recommend layout for ssd and hdd, that ssd is not > overwritten unnecessarily and ideal filesystem for ssd and hdd. You've asked questions which are largely down to taste so you will get a lot of different answers. I would use "manual layout" in the installer to ensure I got exactly what I wanted. I would use whatever filesystems I wanted and not care about SSD writes unless it's an ancient SSD or a truly exceptional use case. For most uses /tmp is best left as a tmpfs (memory-backed) and /opt starts off empty. If you think you're going to use /opt then you must have some idea what you're going to put into it. I would put a 1G or so swap partition on HDD and then dedicate whole rest of the HDD to either btrfs or to LVM, in both cases for the purposes of volume management. That way if your initial guesses for sizing are incorrect you can easily change them and/or switch things into btrfs subvolumes or LVM logical volumes later on. But to be honest, SSD is life changing compared to HDD so I'd want to put everything on SSD as long as it fits. I am a big lover of redundancy so the lack of matched pairs of storage worries me, but assuming that can't be changed I think I would use say the first 5GiB of SSD for / and then the rest as either btrfs or LVM again for volume management. I'd then create subvolumes or logical volumes for /home and /var and initially have them on the SSD for speed. I'd move them into the btrfs/LVM on the HDD only if you began to run out of SSD space. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: New debian installation disk partition
On Lu, 11 oct 21, 13:18:55, Josef Strýček wrote: > > Hi, > > I have a question how to partition new debain installation.I have 64GB ssd > and 500GB hdd. Can I have / on ssd with ext4 and hdd with btrfs /hame /var > > /tmp /opt. Sure you can. > Could you recommend layout for ssd and hdd, that ssd is not > overwritten unnecessarily My recommendation would be to have only /home on the HDD, unless you expect the others to become too big for the SSD. For regular use[1] the SSD should be just fine, and you should already have a good strategy to restore your operating system quickly if needed. If your SSD fails too soon it wasn't worth it anyway and hopefully you can still replace it in warranty ;) > and ideal filesystem for ssd and hdd. There is no such thing as "ideal", it depends very much on your needs. In almost all cases ext4 will be just fine for general use. You are unlikely to notice any significant improvement with other file systems unless you have very special[1] needs. Since you mentioned btrfs, do you actually need any of its additional features compared to ext4? With only one HDD its benefits will be limited (snapshots and subvolumes only?) while increasing complexity. See also: https://arstechnica.com/gadgets/2021/09/examining-btrfs-linuxs-perpetually-half-finished-filesystem/ [1] You would know if your use is special ;) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: New debian installation disk partition
On Mon, Oct 11, 2021 at 01:18:55PM +0200, Josef Strýček wrote: > > Hi, > > I have a question how to partition new debain installation.I have 64GB ssd > and 500GB hdd. Can I have / on ssd with ext4 and hdd with btrfs /hame /var > > /tmp /opt. Could you recommend layout for ssd and hdd, that ssd is not > overwritten unnecessarily and ideal filesystem for ssd and hdd. > > > > > Thank you in advance > > Josef Strýček Hi Josef, I'd suggest you boot with the installer and use expert mode which will allow you more control over partitioning. Take the ssd and use guided partitioning - put everything in one partition. That will set up the appropriate partitions for booting, for / and add a swap partition at the end of 1G size. Partition the 500G hdd however you wish - add a partition for /var and /tmp. What sort of thing are you planning for /opt - it's not often used in Debian but only for third party packages. Nothing is written on the filesystems until you finish the partitioning on each disk. With every good wish, as ever, Andy Cater
New debian installation disk partition
Hi, I have a question how to partition new debain installation.I have 64GB ssd and 500GB hdd. Can I have / on ssd with ext4 and hdd with btrfs /hame /var /tmp /opt. Could you recommend layout for ssd and hdd, that ssd is not overwritten unnecessarily and ideal filesystem for ssd and hdd. Thank you in advance Josef Strýček
Re: how to change debian installation mirror list?
Hi, Fred 1 wrote: > hope I can change it and rebuild the netinstall ISO with jigdo maybe ? Jigdo is not suitable for making changes to the ISO which it reconstructs. (It is rather suitable for reducing the download effort with ISOs which are slightly changed towards an ISO which you already have. See the question "Files to scan:" of program jigdo-lite.) If you have files which you want to add to the ISO or if you want to replace existing files of the ISO, then maybe https://lists.debian.org/debian-user/2021/08/msg01170.html is of help, where i propose how to override a kernel and an initrd in the ISO. As mentioned in that post, there is the possibility that checksum lists or certficates let the booting system detect that existing files were altered. Your mileage may vary. Have a nice day :) Thomas
Re: how to change debian installation mirror list?
Fred 1 writes: I would like to know where the installation pulls the list of Debian mirrors. hope I can change it and rebuild the netinstall ISO with jigdo maybe ? It would be nice if I could manually add a custom one during install, but I didn't see such option, strictly just pick from the list I can only answer the last of your questions: If you want to add a custom mirror during the install, go to the top of the menu and choose "enter information manually". The installer will then ask you for the host name, path and proxy information of your custom mirror. Scroll near the end of https://masysma.lima-city.de/37/debian_i386_installation_reports_att/m6-d11a3-i386-netinst.xhtml for screenshots of the respective dialogs. It is from an an alpha release of the installer but the dialogs should not differ too much from the final one. HTH Linux-Fan öö [...] pgpuHOOoPciDc.pgp Description: PGP signature
Re: how to change debian installation mirror list?
On 24/08/2021 02:00, Dan Ritter wrote: Fred 1 wrote: I would like to know where the installation pulls the list of Debian mirrors. hope I can change it and rebuild the netinstall ISO with jigdo maybe ? It would be nice if I could manually add a custom one during install, but I didn't see such option, strictly just pick from the list You can do it in an expert install, or you can pause the install and edit /etc/apt/sources.list, or you could use FAI, or you could intercept DNS queries, or ... What is the actual problem you are trying to solve? The best answer might not have occurred to you. Read https://xyproblem.info/ -dsr- Thanks, I tried the textual install, so yes the first option to manual add the debian mirror, must have missed it in the graphical install. Anyway, as for changing the list, I suspect unlikely the list comes from sources.list, surely the installation will WRITE the sources.list based on your selection. Thanks
Re: how to change debian installation mirror list?
Fred 1 wrote: > I would like to know where the installation pulls the list of Debian > mirrors. > > hope I can change it and rebuild the netinstall ISO with jigdo maybe ? > > It would be nice if I could manually add a custom one during install, but I > didn't see such option, strictly just pick from the list You can do it in an expert install, or you can pause the install and edit /etc/apt/sources.list, or you could use FAI, or you could intercept DNS queries, or ... What is the actual problem you are trying to solve? The best answer might not have occurred to you. Read https://xyproblem.info/ -dsr-
Re: how to change debian installation mirror list?
On Tue 24 Aug 2021 at 01:36:41 +1000, Fred 1 wrote: > I would like to know where the installation pulls the list of Debian > mirrors. > > hope I can change it and rebuild the netinstall ISO with jigdo maybe ? > > It would be nice if I could manually add a custom one during install, but I > didn't see such option, strictly just pick from the list It is likely that a mirror of your choice can be preseeded: d-i mirror/http/hostname string http.us.debian.org -- Brian.
Re: how to change debian installation mirror list?
Am Montag, 23. August 2021, 17:36:41 CEST schrieb Fred 1: Hi, you do not need to reinstall. You will find a list of debian mirrors on the website of debian. Then you can entry or edit the mirror in the file /etc/apt/sources.list. You can also use deb.debian.org as debian repo in this file. Doing so, it will try to find the nearest mirror in your place automatically. For more information take a look into the documentations. Have fun! Best Hans > I would like to know where the installation pulls the list of Debian > mirrors. > > hope I can change it and rebuild the netinstall ISO with jigdo maybe ? > > It would be nice if I could manually add a custom one during install, > but I didn't see such option, strictly just pick from the list > > Thanks signature.asc Description: This is a digitally signed message part.
how to change debian installation mirror list?
I would like to know where the installation pulls the list of Debian mirrors. hope I can change it and rebuild the netinstall ISO with jigdo maybe ? It would be nice if I could manually add a custom one during install, but I didn't see such option, strictly just pick from the list Thanks
Re: Error starting any Debian installation (on an AMD SEV enabled KVM)
Yes, unfortunately, this is necessary to use SEV. Please take a look at these instructions. https://libvirt.org/kbase/launch_security_sev.html https://developer.amd.com/sev/ The settings memtune, uefi, iommu are required to use launchSecurity = sev The use for secured KVM using AMD Secure Encrypted Virtualization (SEV) is unfortunately not mentioned in your link. I showed you how to create a KVM and boot it to an Ubuntu or Centos image. It works that way but not with Debian. The question that arises is what is different about the other images than Debian Images. If you want I can of course also test other OS. with --location http://deb.debian.org/debian/dists/buster/main/installer-amd64/ I cannot boot with sev on — this only works without launchSecurity sev virsh destroy buster-amd64 ; virsh undefine buster-amd64 --nvram virt-install --virt-type kvm --name buster-amd64 \ --boot uefi \ --location http://deb.debian.org/debian/dists/buster/main/installer-amd64/ \ --network network=ovs-test,model=virtio,driver.iommu=on \ --os-variant debian10 \ --graphics vnc,keymap=de,password='testing passwd' \ --video=cirrus \ --disk size=20 --memory 4096 \ --memtune hard_limit=4563402 \ --launchSecurity sev Best, Daniel > There is no need to PM me. I am subscribed to the mailinglist. > > > On Tue, Aug 10, 2021 at 02:06:04PM +0200, Office onFocus wrote: >> these are my iso files: >> > [...] > >> wget >> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.10.0-amd64-netinst.iso >> wget >> https://get.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso >> > Those should do. > > [...] > > >> >> >> ## Testing DEBIAN >> >> This Debian 10 test is NOT successful. You can boot the ISO and select any OS >> from the GRUB menu. For example "Debian Installer". >> >> Debian GNU/Linux Live (kernel 4.19.0-17-amd64) >> Debian Live with Localisation Support >> Graphical Debian Installer >> *Debian Installer >> Debian Installer with Speech Synthesis >> >> The kernel should be loaded, but the KVM reboots and you are back in the >> GRUB menu :( >> >> >> >> The KVM creation is identical to Ubuntu except for the iso file and the >> os-variant parameter, >> but the setting of the os-variant parameter has no effect. >> >> --- >> root@server:/var/lib/libvirt/images# virsh destroy sev-test; virsh undefine >> sev-test --nvram >> s \ >> --launchSecurity sev >> >> >> Domain 'sev-test' destroyed >> >> Domain 'sev-test' has been undefined >> >> root@server:/var/lib/libvirt/images# rm /var/lib/libvirt/images/sev-test* >> /var/lib/libvirt/qemu/nvram/sev-test_VARS.fd >> rm: cannot remove '/var/lib/libvirt/qemu/nvram/sev-test_VARS.fd': No such >> file or directory >> root@server:/var/lib/libvirt/images# qemu-img create -f qcow2 >> /var/lib/libvirt/images/sev-test.qcow2 20G >> Formatting '/var/lib/libvirt/images/sev-test.qcow2', fmt=qcow2 >> cluster_size=65536 extended_l2=off compression_type=zlib size=21474836480 >> lazy_refcounts=off refcount_bits=16 >> root@server:/var/lib/libvirt/images# >> root@server:/var/lib/libvirt/images# virt-install \ >>> --name sev-test \ >>> --memory 4096 \ >>> --memtune hard_limit=4563402 \ >>> --boot uefi \ >>> --disk >>> /var/lib/libvirt/images/debian-live-10.10.0-amd64-standard.iso,device=cdrom >>> \ >>> --disk /var/lib/libvirt/images/sev-test.qcow2,device=disk,bus=scsi \ >>> --os-type linux \ >>> --os-variant debian10 \ >>> --import \ >>> --controller type=scsi,model=virtio-scsi,driver.iommu=on \ >>> --controller type=virtio-serial,driver.iommu=on \ >>> --memballoon driver.iommu=on \ >>> --graphics vnc,keymap=de,password='test passwd' \ >>> --network network=ovs-test,model=virtio,driver.iommu=on \ >>> --video=cirrus \ >>> --launchSecurity sev >> WARNING Graphics requested but DISPLAY is not set. Not running virt-viewer. >> WARNING No console to launch for the guest, defaulting to --wait -1 >> >> Starting install... >> >> Domain is still running. Installation may be in progress. >> Waiting for the installation to complete. >> --- >> > > Is there a reason why you do it this way and you use all these > options? Or is this just something you found on google? > > Please try a much simpler approach for testing debian: > > virt-install --virt-type kvm --name buster-amd64 \ > --location http://deb.debian.org/debian/dists/buster/main/installer-amd64/ \ > --os-variant debian10 \ > --disk size=20 --memory 4096 > > This is btw. from the debian wiki (https://wiki.debian.org/KVM) > > -H > > > -- > Henning Follmann | hfollm...@itcfollmann.com >
Re: Error starting any Debian installation (on an AMD SEV enabled KVM)
There is no need to PM me. I am subscribed to the mailinglist. On Tue, Aug 10, 2021 at 02:06:04PM +0200, Office onFocus wrote: > these are my iso files: > [...] > wget > https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-10.10.0-amd64-netinst.iso > wget > https://get.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso > Those should do. [...] > > > ## Testing DEBIAN > > This Debian 10 test is NOT successful. You can boot the ISO and select any OS > from the GRUB menu. For example "Debian Installer". > > Debian GNU/Linux Live (kernel 4.19.0-17-amd64) > Debian Live with Localisation Support > Graphical Debian Installer > *Debian Installer > Debian Installer with Speech Synthesis > > The kernel should be loaded, but the KVM reboots and you are back in the GRUB > menu :( > > > > The KVM creation is identical to Ubuntu except for the iso file and the > os-variant parameter, > but the setting of the os-variant parameter has no effect. > > --- > root@server:/var/lib/libvirt/images# virsh destroy sev-test; virsh undefine > sev-test --nvram > s \ > --launchSecurity sev > > > Domain 'sev-test' destroyed > > Domain 'sev-test' has been undefined > > root@server:/var/lib/libvirt/images# rm /var/lib/libvirt/images/sev-test* > /var/lib/libvirt/qemu/nvram/sev-test_VARS.fd > rm: cannot remove '/var/lib/libvirt/qemu/nvram/sev-test_VARS.fd': No such > file or directory > root@server:/var/lib/libvirt/images# qemu-img create -f qcow2 > /var/lib/libvirt/images/sev-test.qcow2 20G > Formatting '/var/lib/libvirt/images/sev-test.qcow2', fmt=qcow2 > cluster_size=65536 extended_l2=off compression_type=zlib size=21474836480 > lazy_refcounts=off refcount_bits=16 > root@server:/var/lib/libvirt/images# > root@server:/var/lib/libvirt/images# virt-install \ > > --name sev-test \ > > --memory 4096 \ > > --memtune hard_limit=4563402 \ > > --boot uefi \ > > --disk > > /var/lib/libvirt/images/debian-live-10.10.0-amd64-standard.iso,device=cdrom > > \ > > --disk /var/lib/libvirt/images/sev-test.qcow2,device=disk,bus=scsi \ > > --os-type linux \ > > --os-variant debian10 \ > > --import \ > > --controller type=scsi,model=virtio-scsi,driver.iommu=on \ > > --controller type=virtio-serial,driver.iommu=on \ > > --memballoon driver.iommu=on \ > > --graphics vnc,keymap=de,password='test passwd' \ > > --network network=ovs-test,model=virtio,driver.iommu=on \ > > --video=cirrus \ > > --launchSecurity sev > WARNING Graphics requested but DISPLAY is not set. Not running virt-viewer. > WARNING No console to launch for the guest, defaulting to --wait -1 > > Starting install... > > Domain is still running. Installation may be in progress. > Waiting for the installation to complete. > --- > Is there a reason why you do it this way and you use all these options? Or is this just something you found on google? Please try a much simpler approach for testing debian: virt-install --virt-type kvm --name buster-amd64 \ --location http://deb.debian.org/debian/dists/buster/main/installer-amd64/ \ --os-variant debian10 \ --disk size=20 --memory 4096 This is btw. from the debian wiki (https://wiki.debian.org/KVM) -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: Error starting any Debian installation (on an AMD SEV enabled KVM)
On Mon, Aug 09, 2021 at 02:04:49PM +0200, Office onFocus wrote: > I cannot start an installation of a debian * .iso (install, live, ..) from > any installation medium. > > This problem affects all Debian images. There are no problems with Ubuntu or > CentOS! As soon as you > boot the ISO and click Install, there is no error message and the boot > process begins again (loop). How did you create your installation media? > > This problem has been around for a long time, and it only occurred to me now > that it only affects Debian. For testing I recommend the tutorial > https://docs.ovh.com/asia/en/dedicated/enable-and-use-amd-sme-sev/ > > Server: buster / sid > Libvirt: 7.0.0-3 > qemu: 1: 5.2 + dfsg-11 > > I hope you can help me soon so that I can install a KVM (sev) with Debian. I assume you want to create a KVM image? How do you try to start the instance for installation? (Please list the complete line for running kvm) -H -- Henning Follmann | hfollm...@itcfollmann.com
Error starting any Debian installation (on an AMD SEV enabled KVM)
I cannot start an installation of a debian * .iso (install, live, ..) from any installation medium. This problem affects all Debian images. There are no problems with Ubuntu or CentOS! As soon as you boot the ISO and click Install, there is no error message and the boot process begins again (loop). This problem has been around for a long time, and it only occurred to me now that it only affects Debian. For testing I recommend the tutorial https://docs.ovh.com/asia/en/dedicated/enable-and-use-amd-sme-sev/ Server: buster / sid Libvirt: 7.0.0-3 qemu: 1: 5.2 + dfsg-11 I hope you can help me soon so that I can install a KVM (sev) with Debian.
Re: debian installation issue
David Wright composed on 2021-07-04 10:29 (UTC-0500): > On Tue 29 Jun 2021 at 13:26:04 (-0400), Felix Miata wrote: >> David Wright composed on 2021-06-29 11:16 (UTC-0500): ... >>> I don't understand the attraction of messing about with boot flags >>> in order to choose which primary partition to boot from. It seems >>> inelegant to write to the drive just for that. ... >> 2-The system was invented over 4 decades ago, before the PC compatible HD >> partitioning system was upgraded to allow for more than 4 partitions per HD. > Sorry, what system? My fallible memory may have mislead. I believe the 66 byte, 4 primary entry partition table "standard" MBR (system) was pioneered by the IBM PC/AT, which debuted with DOS 3.0, a good bit less than 4 decades ago. The reference book I had that spelled such things out never came back from a lend, and it's not proven worth my time to dig that bit of trivia out of the WWW. I did look on Wikipedia, but didn't spot a clear answer. The extended type adaptation with logical partitions arrived with DOS 3.2, which I skipped over to get 3.3 for 3.5" floppy and Bernoulli Box support. >> 3-I have yet to intentionally install Grub2 on an MBR system. I use mostly >> openSUSE's Grub Legacy, which supports ext4 (as long as 64bit is not >> enabled), on >> all MBR systems, > I'm not sure of the relevance of the Grub version, but I assume, from > your previous post, that Grub is installed in individual partitions, > not in the MBR/"on the disk". Grub Legacy maintenance doesn't require much effort or education. I can clone a partition, then run tune2fs to change UUID and LABEL, and setup Grub Legacy on the clone, from the same shell session in less than a minute, without need for any script, .conf file or partition mounting. It needs only a device.map and the Grub binary. Except when IBM BM is the primary bootloader on a system, I always have Grub Legacy on a primary partition. Historically, each / partition has it as well, but with the increasing absence of its availability, many of my installations have been going without having a bootloader installed by the host OS. -- 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: debian installation issue
On Tue 29 Jun 2021 at 13:26:04 (-0400), Felix Miata wrote: > David Wright composed on 2021-06-29 11:16 (UTC-0500): > > On Thu 24 Jun 2021 at 00:07:56 (-0400), Felix Miata wrote: > >> David Wright composed on 2021-06-22 10:50 (UTC-0500): > > >> I'm not sure there is "a" definition. One could be any code that a Windows > >> installation would not replace. Another could be based on what it does: > > >> 1-locate a legal boot flag > >> 2-load an appropriate sector pointed to by a legal flag > >> 3-announce error if the above conditions are not met > > >> A legal flag is any flag on a primary partition on a disk on which no > >> other boot > >> flags are present in the MBR table. > > > I don't understand the attraction of messing about with boot flags > > in order to choose which primary partition to boot from. It seems > > inelegant to write to the drive just for that. > > 1-It's Windows compatible. With it, Windows 7/10 won't refuse to complete > updates > when it doesn't find something it expects in the partition table. "Refuse" in > this > case means install a big heap of updates, then decide it can't finish, and > wastes > more time uninstalling those it just installed, followed by announcing there > are a > heap of updates to install, repeat ad nauseum. I haven't met that problem. I've run W10 on UEFI with stretch and buster on BIOS-MBR using Grub, and the two OSes were effectively unaware of each other. (I can't speak to W7, as that had been upgraded by the time I started using the machine. > 2-The system was invented over 4 decades ago, before the PC compatible HD > partitioning system was upgraded to allow for more than 4 partitions per HD. Sorry, what system? > 3-I have yet to intentionally install Grub2 on an MBR system. I use mostly > openSUSE's Grub Legacy, which supports ext4 (as long as 64bit is not > enabled), on > all MBR systems, I'm not sure of the relevance of the Grub version, but I assume, from your previous post, that Grub is installed in individual partitions, not in the MBR/"on the disk". OK, yes, I can see that you have a reason, apparently, to keep Grub away from the MBR on the systems where there's a sensitive Windows installation, but for someone like the OP, coming to a linux system afresh, I can't see any reason for them to add complexity by not installing Grub on the MBR (assuming BIOS booting is in force). > and Grub2-efi on UEFI systems, including Intel Mac. > > >> > Are there OSes that would install it themselves to a new blank disk? > > >> One version would be code a Windows installation would put there. > > >> Another would be the result of FDISK /MBR from a MS or PC DOS boot, or > >> FDISK > >> /NEWMBR or LVM /NEWMBR from an OS/2, eCS or ArcaOS boot. > > >> I would expect the FreeDOS version of FDISK or its installer to do the > >> same. > > >> I normally use code derived from OS/2, installed by DFSee when I first > >> partition a > >> disk. > > > Obtaining DFSee might be alright for someone invested in MBR booting, > > but for most people, MBR is obsolescent. Putting Grub on the MBR can > > give a user interface more similar to current machines that use Grub > > on UEFI, which seems an advantage. > > UEFI is an incontrovertible improvement over MBR, but MBR will be around > quite a > while yet for machines that don't include UEFI. > > DFSee isn't a mere partitioner, and is not for MBR systems only. Among other > features, it's also a copier/cloner, a binary editor of files and raw > sectors, can > be scripted, and it logs in plain text. Its logs are an indispensable part of > my > environment, facilitating inventorying several hundred partitions and > operating > systems spread across tens of uniquely partitioned and OS-equipped multiboot > machines. It includes free personal support from its author, as well as a > helpful > support mailing list. It's interface is identical whether run from DOS, Linux, > Mac, OS/2 or Windows. Yes, you've posted inventories listed with that tool in the past (I have one here, for ST HP GB0500…) and that's what I meant by being "invested in". But again, it's just extra complexity for most people. Don't misunderstand me, I'm not criticising your individual approach, but I can't find any more religion in Greg's (qualified) remark than in your views expressed about Grub/Grub2 and MBRs. I see them both as strong preferences, held for good reasons. Cheers, David.
Re: debian installation issue
David Wright composed on 2021-06-29 11:16 (UTC-0500): > On Thu 24 Jun 2021 at 00:07:56 (-0400), Felix Miata wrote: >> David Wright composed on 2021-06-22 10:50 (UTC-0500): >> I'm not sure there is "a" definition. One could be any code that a Windows >> installation would not replace. Another could be based on what it does: >> 1-locate a legal boot flag >> 2-load an appropriate sector pointed to by a legal flag >> 3-announce error if the above conditions are not met >> A legal flag is any flag on a primary partition on a disk on which no other >> boot >> flags are present in the MBR table. > I don't understand the attraction of messing about with boot flags > in order to choose which primary partition to boot from. It seems > inelegant to write to the drive just for that. 1-It's Windows compatible. With it, Windows 7/10 won't refuse to complete updates when it doesn't find something it expects in the partition table. "Refuse" in this case means install a big heap of updates, then decide it can't finish, and wastes more time uninstalling those it just installed, followed by announcing there are a heap of updates to install, repeat ad nauseum. 2-The system was invented over 4 decades ago, before the PC compatible HD partitioning system was upgraded to allow for more than 4 partitions per HD. 3-I have yet to intentionally install Grub2 on an MBR system. I use mostly openSUSE's Grub Legacy, which supports ext4 (as long as 64bit is not enabled), on all MBR systems, and Grub2-efi on UEFI systems, including Intel Mac. >> > Are there OSes that would install it themselves to a new blank disk? >> One version would be code a Windows installation would put there. >> Another would be the result of FDISK /MBR from a MS or PC DOS boot, or FDISK >> /NEWMBR or LVM /NEWMBR from an OS/2, eCS or ArcaOS boot. >> I would expect the FreeDOS version of FDISK or its installer to do the same. >> I normally use code derived from OS/2, installed by DFSee when I first >> partition a >> disk. > Obtaining DFSee might be alright for someone invested in MBR booting, > but for most people, MBR is obsolescent. Putting Grub on the MBR can > give a user interface more similar to current machines that use Grub > on UEFI, which seems an advantage. UEFI is an incontrovertible improvement over MBR, but MBR will be around quite a while yet for machines that don't include UEFI. DFSee isn't a mere partitioner, and is not for MBR systems only. Among other features, it's also a copier/cloner, a binary editor of files and raw sectors, can be scripted, and it logs in plain text. Its logs are an indispensable part of my environment, facilitating inventorying several hundred partitions and operating systems spread across tens of uniquely partitioned and OS-equipped multiboot machines. It includes free personal support from its author, as well as a helpful support mailing list. It's interface is identical whether run from DOS, Linux, Mac, OS/2 or Windows. -- 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: debian installation issue
On Thu 24 Jun 2021 at 00:07:56 (-0400), Felix Miata wrote: > David Wright composed on 2021-06-22 10:50 (UTC-0500): > > On Fri 11 Jun 2021 at 16:57:35 (-0400), Felix Miata wrote: > > >> OTOH, putting a bootloader on the MBR of a disk on a PC designed for > >> Windows is a > >> relative newcomer to the world of booting such a PC. I've been installing > >> operating systems on IBM-compatible PCs for more than 3 decades. Not once > >> have I > >> intentionally installed Grub on an MBR. In the dearth of instances where > >> it did > >> happen I wiped whatever caused it, and started over with > >> DOS/OS2/Windows/Linux-compatible MBR code on the MBR. IOW, Grub can live > >> elsewhere > >> than on the MBR. > > > Can you elaborate on what your "DOS/OS2/Windows/Linux-compatible MBR > > code" is, what functionality you get, and where you obtain it. > > I'm not sure there is "a" definition. One could be any code that a Windows > installation would not replace. Another could be based on what it does: > > 1-locate a legal boot flag > 2-load an appropriate sector pointed to by a legal flag > 3-announce error if the above conditions are not met > > A legal flag is any flag on a primary partition on a disk on which no other > boot > flags are present in the MBR table. I don't understand the attraction of messing about with boot flags in order to choose which primary partition to boot from. It seems inelegant to write to the drive just for that. With the mbr package from Debian, you can choose at a boot-time prompt. With Grub, you can also choose for the next boot, any time the system is running. > > Are there OSes that would install it themselves to a new blank disk? > > One version would be code a Windows installation would put there. > > Another would be the result of FDISK /MBR from a MS or PC DOS boot, or FDISK > /NEWMBR or LVM /NEWMBR from an OS/2, eCS or ArcaOS boot. > > I would expect the FreeDOS version of FDISK or its installer to do the same. > > I normally use code derived from OS/2, installed by DFSee when I first > partition a > disk. Obtaining DFSee might be alright for someone invested in MBR booting, but for most people, MBR is obsolescent. Putting Grub on the MBR can give a user interface more similar to current machines that use Grub on UEFI, which seems an advantage. Cheers, David.
Re: debian installation issue
David Wright composed on 2021-06-22 10:50 (UTC-0500): > On Fri 11 Jun 2021 at 16:57:35 (-0400), Felix Miata wrote: >> OTOH, putting a bootloader on the MBR of a disk on a PC designed for Windows >> is a >> relative newcomer to the world of booting such a PC. I've been installing >> operating systems on IBM-compatible PCs for more than 3 decades. Not once >> have I >> intentionally installed Grub on an MBR. In the dearth of instances where it >> did >> happen I wiped whatever caused it, and started over with >> DOS/OS2/Windows/Linux-compatible MBR code on the MBR. IOW, Grub can live >> elsewhere >> than on the MBR. > Can you elaborate on what your "DOS/OS2/Windows/Linux-compatible MBR > code" is, what functionality you get, and where you obtain it. I'm not sure there is "a" definition. One could be any code that a Windows installation would not replace. Another could be based on what it does: 1-locate a legal boot flag 2-load an appropriate sector pointed to by a legal flag 3-announce error if the above conditions are not met A legal flag is any flag on a primary partition on a disk on which no other boot flags are present in the MBR table. > Are there OSes that would install it themselves to a new blank disk? One version would be code a Windows installation would put there. Another would be the result of FDISK /MBR from a MS or PC DOS boot, or FDISK /NEWMBR or LVM /NEWMBR from an OS/2, eCS or ArcaOS boot. I would expect the FreeDOS version of FDISK or its installer to do the same. I normally use code derived from OS/2, installed by DFSee when I first partition a disk. >> With a UEFI "BIOS", the boot process begins rather differently than on an >> MBR-only >> system. On a UEFI system's ESP (Extensible Firmware Interface System >> Partition; a >> quasi-"boot" partition), there are no files containing the string "grub" in >> their >> name. I have no idea what I was thinking when I wrote that last sentence. I was probably looking at an installation that had been installed without any bootloader, which is not where I should have been focused. >> Thus it seems to be a debatable issue whether "bootloader" is actually an >> appropriate name for Grub 2, as its primary purpose seems to be presenting a >> menu >> from which to select what kernel, initrd (if any), and kernel command line >> parameters (if any) to load into RAM to /continue/ the boot process >> initiated by >> the UEFI firmware. > I'm not quite following your point. Are you saying that the ~250 Grub > modules are just a waste of space, and that the while boot process is > carried out by the EFI firmware? The process is initiated by the EFI firmware, begun by probing a panoply of available media for ESP partition files that fulfill requirements for proceeding with a boot process defined by the Multiboot Specification. Usually, it's more or less the start of a chain loading process finished by an installed "bootloader". OTOH, the UEFI firmware might start a PC completely (of sorts) by loading a single file on the ESP originally named mt83x64.efi (memtest86 v8.3). All the Grub modules aren't required or employed on any given installation. A more sophisticated Grub installer could conceivably install there only those components required for the hardware present during installation. -- 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: debian installation issue
On Mi, 23 iun 21, 19:43:14, Richard Hector wrote: > > Is that something that needs to be done by one company? Perhaps because of > how SecureBoot is implemented? For a logistic point of view, at least for x86, Microsoft appears to be the natural choice: many mainboard manufacturers, but most hardware will end up running Windows anyway[1]. > I'd prefer to be able to add Debian's key either in addition to or instead > of Microsoft's, which could also be happily installed alongside those of > Intel, AMD, your favourite government security agency or whoever. And Debian > can get theirs signed by whichever of those they might think is appropriate. > But I want to be able to reduce that list to just Debian's, or just the > EFF's, or mine. Whatever combination I choose. In my limited understanding and experience with Secure Boot it's mostly up to the mainboard manufacturer. As far as I can tell for the ASRock board here it's possible to provide a machine owner key, possibly also to revoke all other keys. Even if it does work, I'm pretty sure 99% of home users don't actually care about any of this. [1] Yes, I'm aware there are lots of x86 Chromebooks, but those are special purpose hardware, and even there it might make sense to include Microsoft's key, just in case someone wants to attempt installing Windows on the limited storage available :D Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: debian installation issue
On 22/06/21 12:54 am, Steve McIntyre wrote: [ Apologies, missed this last week... ] to...@tuxteam.de wrote: On Mon, Jun 14, 2021 at 09:20:52AM +0300, Andrei POPESCU wrote: On Vi, 11 iun 21, 15:07:11, Greg Wooledge wrote: > > Secure Boot (Microsoft's attempt to stop you from using Linux) relies on > UEFI booting, and therefore this was one of the driving forces behind it, > but not the *only* driving force. If your machine doesn't use Secure Boot, > don't worry about it. It won't affect you. While I'm not a fan of Microsoft: https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_NOT.3F Quoting from there: "Microsoft act as a Certification Authority (CA) for SB, and they will sign programs on behalf of other trusted organisations so that their programs will also run." Now two questions: - do you know any other alternative CA besides Microsoft who is capable of effectively doing this? In a way that it'd "work" with most PC vendors? I've been in a number of discussions about this over the last few years, particularly when talking about adding arm64 Secure Boot and *maybe* finding somebody else to act as CA for that. There's a few important (but probably not well-understood) aspect ofs the CA role here: * the entity providing the CA needs to be stable (changing things is expensive and hard) * they need to be trustworthy - having an existing long-term business relationship with the OEMs is a major feature here * they need to be *large* - if there is a major mistake that might cause a problem on a lot of machines in production, the potential cost liability (and lawsuits) from OEMs is *huge* There are not many companies who would fit here. Intel and AMD are both very interested in enhancing trust and security at this kind of level, but have competing products and ideas, for example. Is that something that needs to be done by one company? Perhaps because of how SecureBoot is implemented? I'd prefer to be able to add Debian's key either in addition to or instead of Microsoft's, which could also be happily installed alongside those of Intel, AMD, your favourite government security agency or whoever. And Debian can get theirs signed by whichever of those they might think is appropriate. But I want to be able to reduce that list to just Debian's, or just the EFF's, or mine. Whatever combination I choose. I think that should all work ok? Changing things, rather than being expensive and hard, should just be a matter of either getting a new organisation to sign Debian's key, and/or having them revoke one. As one of those on the list. As an aside, I'd like to see this with web certificates too - I want to be able to get my cert signed by LetsEncrypt _and_ whatever commercial CA or CAs I choose, so if one of them does something stupid and needs to be removed from the list of approved CAs, it doesn't break the internet, because any significant site will have its certs signed by others as well. Richard
Re: debian installation issue
On Fri 11 Jun 2021 at 16:57:35 (-0400), Felix Miata wrote: > Greg Wooledge composed on 2021-06-11 15:07 (UTC-0400): > > On Fri, Jun 11, 2021 at 09:38:37PM +0300, Semih Ozlem wrote: > > >> How to check where grub is installed? And what is a friendly guide to > >> learning about grub? > > > GRUB should be installed on the *disk* (not on a partition) that you > > intend to boot. > Not to detract from the wisdom of the rest of Greg's excellent reply, but TBC, > this statement is religion at one extreme, opinion at the other, not fact. > Note he > wisely did not say "must", but "should". For most traditional (BIOS/MBR; > designed > for "Windows" PCs) configurations, it's probably prudent to put the > bootloader on > the "disk". For pure Debian installations, as opposed to multiboot, whether > or not > to install it on the "disk" really doesn't matter. > > OTOH, putting a bootloader on the MBR of a disk on a PC designed for Windows > is a > relative newcomer to the world of booting such a PC. I've been installing > operating systems on IBM-compatible PCs for more than 3 decades. Not once > have I > intentionally installed Grub on an MBR. In the dearth of instances where it > did > happen I wiped whatever caused it, and started over with > DOS/OS2/Windows/Linux-compatible MBR code on the MBR. IOW, Grub can live > elsewhere > than on the MBR. Can you elaborate on what your "DOS/OS2/Windows/Linux-compatible MBR code" is, what functionality you get, and where you obtain it. Are there OSes that would install it themselves to a new blank disk? > A less innocuous error is not clearly qualifying the quoted statement to apply > only to non-UEFI boot environments, which usually means an MBR-partitioned > boot > disk. On a UEFI installation, which requires GPT partitioning, the first > sector > normally contains nothing until near its end, where a disk identifier and the > start of the disk's multi-sector partition table begin. No executable code is > required on this sector. > > With a UEFI "BIOS", the boot process begins rather differently than on an > MBR-only > system. On a UEFI system's ESP (Extensible Firmware Interface System > Partition; a > quasi-"boot" partition), there are no files containing the string "grub" in > their > name. # ls -GlgR /boot/efi/ /boot/efi/: total 4 drwx-- 4 4096 Apr 3 2020 EFI /boot/efi/EFI: total 8 drwx-- 2 4096 Apr 3 2020 BOOT drwx-- 2 4096 Apr 3 2020 debian /boot/efi/EFI/BOOT: total 3988 -rwx-- 1 1322936 Mar 2 16:23 BOOTX64.EFI -rwx-- 1 1206824 Mar 2 16:23 fbx64.efi -rwx-- 1 1549696 Mar 2 16:23 grubx64.efi /boot/efi/EFI/debian: total 5228 -rwx-- 1 108 Mar 2 16:23 BOOTX64.CSV -rwx-- 1 1206824 Mar 2 16:23 fbx64.efi -rwx-- 1 126 Mar 2 16:23 grub.cfg -rwx-- 1 1549696 Mar 2 16:23 grubx64.efi -rwx-- 1 1261192 Mar 2 16:23 mmx64.efi -rwx-- 1 1322936 Mar 2 16:23 shimx64.efi # Whatever grubx64.efi is, it's copied from grub-efi-amd64-signed, aka grub-efi-amd64-signed_1+2.02+dfsg1+20+deb10u4_amd64.deb currently. > Thus it seems to be a debatable issue whether "bootloader" is actually an > appropriate name for Grub 2, as its primary purpose seems to be presenting a > menu > from which to select what kernel, initrd (if any), and kernel command line > parameters (if any) to load into RAM to /continue/ the boot process initiated > by > the UEFI firmware. I'm not quite following your point. Are you saying that the ~250 Grub modules are just a waste of space, and that the while boot process is carried out by the EFI firmware? Cheers, David.
Re: debian installation issue
On Mon, Jun 21, 2021 at 12:54:31PM +, Steve McIntyre wrote: > [ Apologies, missed this last week... ] No need to apologise: I appreciate the detailed answer. > > - do you know any other alternative CA besides Microsoft [...] > I've been in a number of discussions about this over the last few > years, particularly when talking about adding arm64 Secure Boot and > *maybe* finding somebody else to act as CA for that. There's a few > important (but probably not well-understood) aspect ofs the CA role > here: > > * the entity providing the CA needs to be stable (changing things is >expensive and hard) > * they need to be trustworthy - having an existing long-term business >relationship with the OEMs is a major feature here > * they need to be *large* - if there is a major mistake that might >cause a problem on a lot of machines in production, the potential >cost liability (and lawsuits) from OEMs is *huge* This makes sense. It still feels... weird to have one company do it who has a bone to pick in the market. Watching Oracle/Java doesn't give me good feelings about that. It is even much more fundamental, because it's more or less all of the "general purpose computing devices" we are talking about here. > There are not many companies who would fit here. Intel and AMD are > both very interested in enhancing trust and security at this kind of > level, but have competing products and ideas, for example. That's why I think this shouldn't be done by "a company", but by a non-profit industry consortium, of which there are enough examples around. > > - is there any internationally legal binding of Microsoft for > > them to provide that service in the future, in a fair and non > > discriminatory way? > > That is a question I *can't* answer as I've not seen anything > personally. But I would be shocked if agreements like that have not > been made with various vendors. This can cut both ways. Vendors have interests (and be it that other competing vendors be kept out of the market). If things don't happen transparently... > Having worked with Microsoft and a number of representatives from the > Linux distros, I *can* confirm that Microsoft care about Linux and SB > working well. Hell, they're even using SB (shim, etc.) themselves for > their own small Linux distro. That's not a *guarantee* of future > goodwill, but they're not about to break things here on a whim. Winds change. The above example of Oracle/Java (as that horrible SCO saga, remember?) should teach people some care... Colour me... sceptical. Cheers - t signature.asc Description: Digital signature
Re: debian installation issue
[ Apologies, missed this last week... ] to...@tuxteam.de wrote: > >On Mon, Jun 14, 2021 at 09:20:52AM +0300, Andrei POPESCU wrote: >> On Vi, 11 iun 21, 15:07:11, Greg Wooledge wrote: >> > >> > Secure Boot (Microsoft's attempt to stop you from using Linux) relies on >> > UEFI booting, and therefore this was one of the driving forces behind it, >> > but not the *only* driving force. If your machine doesn't use Secure Boot, >> > don't worry about it. It won't affect you. >> >> While I'm not a fan of Microsoft: >> >> https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Boot_NOT.3F > >Quoting from there: > > "Microsoft act as a Certification Authority (CA) for SB, and they will > sign programs on behalf of other trusted organisations so that their > programs will also run." > >Now two questions: > > - do you know any other alternative CA besides Microsoft who is > capable of effectively doing this? In a way that it'd "work" > with most PC vendors? I've been in a number of discussions about this over the last few years, particularly when talking about adding arm64 Secure Boot and *maybe* finding somebody else to act as CA for that. There's a few important (but probably not well-understood) aspect ofs the CA role here: * the entity providing the CA needs to be stable (changing things is expensive and hard) * they need to be trustworthy - having an existing long-term business relationship with the OEMs is a major feature here * they need to be *large* - if there is a major mistake that might cause a problem on a lot of machines in production, the potential cost liability (and lawsuits) from OEMs is *huge* There are not many companies who would fit here. Intel and AMD are both very interested in enhancing trust and security at this kind of level, but have competing products and ideas, for example. > - is there any internationally legal binding of Microsoft for > them to provide that service in the future, in a fair and non > discriminatory way? That is a question I *can't* answer as I've not seen anything personally. But I would be shocked if agreements like that have not been made with various vendors. Having worked with Microsoft and a number of representatives from the Linux distros, I *can* confirm that Microsoft care about Linux and SB working well. Hell, they're even using SB (shim, etc.) themselves for their own small Linux distro. That's not a *guarantee* of future goodwill, but they're not about to break things here on a whim. -- Steve McIntyre, Cambridge, UK.st...@einval.com "We're the technical experts. We were hired so that management could ignore our recommendations and tell us how to do our jobs." -- Mike Andrews
Re: Secure Boot in QEMU (was Re: debian installation issue)
On Mon, Jun 14, 2021 at 06:07:50AM -0400, Kenneth Parker wrote: > Okay. I am running Debian Bullseye (selected earlier, during its testing > phase, because I needed its level of QEMU to import a VM from Mint 20's > QEMU: Buster's QEMU refused). My computer is an HP EliteDesk 705 G1-SFF. > > I have a special requirement to run a Licenced version of Windows 10 Pro as > a QEMU/KVM Guest. I have already set up QEMU GCOW2 files as gpt and > partitioned them with UEFI environments, but only with Linux guests so far, > as well as (in one instance) Refind. > > Does QEMU/KVM support setting up Secure Boot, in a way that passes > Microsoft Muster? > > Okay, I may be finding my own answers, via a Super User web page on this, > using Manjaro and ovmf: > > https://superuser.com/questions/1389103/windows-10-uefi-physical-to-kvm-libvirt-virtual > > And now I see that Bullseye has ovmf available as a package. > > So this will be my next Project. I guess I am asking if anyone on this > list has been successful with a virtualized Secure Boot that Microsoft > likes? > > Have a nice day :) > > > > Thomas > > > > Many thanks! > > Kenneth Parker Hi Kenneth, Install OVMF. I tend to use Virtual Machine Manager just because it's easier for me. Essentially, you do get the choice to use Secure Boot and there are two options - one for Microsoft and one generic, I think. Andy C.
Re: [Off topic thoughts] Re: debian installation issue
On Mon, 14 Jun 2021 11:41:37 +0200 wrote: > "Any sufficiently advanced malice is indistinguishable from > stupidity" > > (some call that "plausible deniability"). > > "People would rather appear stupid than evil". -- Joe
