Bug#694068: (solved) Re: wireless fail after stretch installation
On Tue 06 Mar 2018 at 18:34:27 +, Ian Jackson wrote:
> bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > I think the idea needs to be talked over a little better, because using
> > e/n/i for wireless by default after first boot has implications if the
> > user (who is clueless) later installs a desktop environment.
>
> If installing a desktop environment, after putting the wireless in
> /e/n/i, does not work, then that is a bug in the desktop environment,
> surely ?
Most probably. But desktop environments were not the subject of this
thread. (Sorry for trying to keep on-topic).
> In practice I would expect the config in /e/n/i to keep working
> because nowadays network-manager will ignore things in /e/n/i. The
> difficulty would only come if you
> - used the installer to install a bare system over wifi
That difficulty is exactly the subject of this thread. The rest of this
post is snipped because it side-steps addressing the issue. What is put
in /e/n/i ceases to work because it is obliterated by the installer for
reasons unknown.
One user calls it a "sick joke". After five years and with no attempt
to rectify the situation, I'm beginning to have sympathy with that view.
(Yes, I know we are all volunteers).
--
Brian.
> - later install network-manager or wicd
> - then expect the system to give you a gui prompt for new wifi
> networks, rather than expect to have to edit /e/n/i
>
> It would be possible for the n-m and wicd packages to spot when this
> is happening and offer to take over the interface. And I do think
> that in the absence of code to do that, it would be more important to
> make the barebones system work in the first place, than to improve the
> behaviour you later install n-m.
>
> (I'm not sure if what I say about wicd is right. I use n-m on
> machines I have where the user needs to switch between various network
> connections, wifi networks, etc.)
>
> > I'd hate to see the bug tracker turned into a discussion forum though.
>
> The bug tyracker is precisely the right place to discuss how to solve
> a particular bug. So I have CC'd it.
>
> Ian.
>
> --
> Ian Jackson These opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
>
Bug#892206: Seagate: LUMP not started?
Package: debian-installer Version: 20170615 Severity: important Some users have reported that they cannot connect to the u-boot on their Seagate NAS anymore using clunc after installing Debian. I'll add more information about the investigation Simon Guinot did later. We're not sure this really is a bug since all released version of u-boot should listen for the magic packet (LUMP). However, there are version of u-boot that don't automatically do this (probably not released, but not 100% sure about this). In any case, we should modify the debian_boot variable so start lump directly (run start_lump or lump 3). The only downside is that the startup prcoess is 3 seconds longer. I'll add a patch soon and more info to this bug report. -- Martin Michlmayr http://www.cyrius.com/
LVM partitioning preseed.cfg / kickstart question
Hi All,
I seem to be having trouble with correctly partitioning a hard drive using a
PXE boot + preseed file , and am seeking help.
What works:
I can use an expert_recipe string as part of a preseed.cfg file contained in a
custom ISO (booted via grub-imageboot), and it correctly partitions a drive
with LVM. Additionally, and I can use http-served kickstart file commands like:
part /boot --fstype ext4 --size 1024 --asprimary
part pv.01 --size 1 --grow
volgroup linuxvg pv.01
logvol swap --fstype swap --vgname=linuxvg --size=6272 --name=swap
logvol / --fstype xfs --vgname=linuxvg --size=80248 --name=root_vol
logvol /spare --fstype xfs --vgname=linuxvg --size=61440 --name=spare_vol
logvol /home --fstype xfs --vgname=linuxvg --size=76800 --name=home_vol
--grow
in an http-served ks=http://path/to/file.ks file, and it will also partition
the drive with LVM, but my issue is that the results between the two aren't
consistent, and I want to use an expert_recipe string for both. This is
because the expert_recipe string allows for proportional partition sizes based
on the overall size of the disk. (Note: I use the "spare_vol" as a
placeholder, and it gets removed in the "post" install section of the
installer).
Where things break down for me:
For me, any attempt to use a kickstart / kickseed file served via http with an
expert_recipe string doesn't give me my desired partitions.
If I use bare d-i commands for the expert_recipe string in an http-served
preseed.cfg file, the partitions don't get picked-up at all.
I tried doing something like (note: this partition layout uses a "spare"
partition which gets removed in the "post" installer section):
echo "d-i partman-auto/expert_recipe string \
boot-root :: \
1024 1024 1024 ext4 \
$primary{ } \
$bootable{ }\
method{ format }\
format{ } \
use_filesystem{ } \
filesystem{ ext4 } \
mountpoint{ /boot } \
. \
100 1000 -1 xfs \
$defaultignore{ } \
$primary{ } \
method{ lvm } \
vg_name{ linux }\
. \
80248 80248 80248 xfs \
$lvmok{ } \
in_vg{ linux } \
lv_name{ root_vol } \
method{ format }\
format{ } \
use_filesystem{ } \
filesystem{ xfs } \
mountpoint{ / } \
. \
6272 6272 6272 linux-swap \
$lvmok{ } \
in_vg{ linux } \
method{ swap } \
lv_name{ swap_vol } \
format{ } \
filesystem{ swap } \
. \
61440 61440 61440 xfs \
$lvmok{ } \
in_vg{ linux } \
lv_name{ spare_vol }\
method{ format }\
format{ } \
use_filesystem{ } \
filesystem{ xfs } \
mountpoint{ /spare }\
. \
76800 76800 76800 xfs \
$lvmok{ } \
in_vg{ linux } \
lv_name{ home_vol } \
method{ format }\
format{ } \
use_filesystem{ } \
filesystem{ xfs } \
mountpoint{ /home } \
." >> /var/spool/kickseed/parse/preseed.cfg
But I wind up with partitions at /dev/sda1, /dev/sda5 - /sda9 (which I don't
want) instead of a primary partitions at /dev/sda1 along with a bunch of
/dev/mapper/ . . . LVM partitions (which I do want).
I've also tried including my preseed.cfg in a custom initrd.gz which is out on
the server, but to no avail.
I hope this all makes sense. Let me know if you have any advice or additional
questions.
Kind regards,
Jim
Bug#694068: (solved) Re: wireless fail after stretch installation
bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> I think the idea needs to be talked over a little better, because using
> e/n/i for wireless by default after first boot has implications if the
> user (who is clueless) later installs a desktop environment.
If installing a desktop environment, after putting the wireless in
/e/n/i, does not work, then that is a bug in the desktop environment,
surely ?
In practice I would expect the config in /e/n/i to keep working
because nowadays network-manager will ignore things in /e/n/i. The
difficulty would only come if you
- used the installer to install a bare system over wifi
- later install network-manager or wicd
- then expect the system to give you a gui prompt for new wifi
networks, rather than expect to have to edit /e/n/i
It would be possible for the n-m and wicd packages to spot when this
is happening and offer to take over the interface. And I do think
that in the absence of code to do that, it would be more important to
make the barebones system work in the first place, than to improve the
behaviour you later install n-m.
(I'm not sure if what I say about wicd is right. I use n-m on
machines I have where the user needs to switch between various network
connections, wifi networks, etc.)
> I'd hate to see the bug tracker turned into a discussion forum though.
The bug tyracker is precisely the right place to discuss how to solve
a particular bug. So I have CC'd it.
Ian.
--
Ian Jackson These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#888515: debian-installer: UEFI boot menu (grub) misses the help screen
Hello, Samuel Thibault, on lun. 05 févr. 2018 10:31:40 +0100, wrote: > I have reported the feature request to http://savannah.gnu.org/bugs/?53065 Here is an answer: “ the solution which is available atm is: set pager=1 cat ($root)/boot/grub/MESSAGE.txt unset pager echo -n "-- Press ESC or wait 60 sec to continue: " sleep --verbose --interruptible 60 There is no pause command. To stop for a minute before showing the menu: sleep continues on Escape key only. ” Samuel
Re: possibility to install debian in Russian using A11Y
Hello, александр епанешников, on mar. 06 mars 2018 18:37:34 +0300, wrote: > Hello. as far as I know now it is impossible to make installation using text > mode and speakup with espeakup in Russian. > > if I'm not mistaken this is because espeakup does not support unicode. in > the git I saw a commit correcting this. my question is: after the release > of espeakup will it be able to work with the Russian text. and whether the > problem with installation in Russian will be solved. That will be part of next release, Buster, yes. Samuel
possibility to install debian in Russian using A11Y
Hello. as far as I know now it is impossible to make installation using text mode and speakup with espeakup in Russian. if I'm not mistaken this is because espeakup does not support unicode. in the git I saw a commit correcting this. my question is: after the release of espeakup will it be able to work with the Russian text. and whether the problem with installation in Russian will be solved. Sincerely, Alexander
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
Please leave me out of this thread. Ben. -- Ben Hutchings Never attribute to conspiracy what can adequately be explained by stupidity. signature.asc Description: This is a digitally signed message part
Processing of debootstrap_1.0.93+nmu1_amd64.changes
debootstrap_1.0.93+nmu1_amd64.changes uploaded successfully to localhost along with the files: debootstrap_1.0.93+nmu1.dsc debootstrap_1.0.93+nmu1.tar.gz debootstrap-udeb_1.0.93+nmu1_all.udeb debootstrap_1.0.93+nmu1_all.deb debootstrap_1.0.93+nmu1_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Re: Armel: Debian installer freeezes (GuruPlug Server plus)
I made some "archeological diggings" with U-boot source code. If I understand correctly, U-boot/PowerPC normal style boot sequence is that MMU/virtual memory system is switched on by bootstrapping code after uncompressing kernel. That means, Image/uInitrd/fdt-blob file loading is made in "real" mode. On ARM/Kirkwood environment BootPron is executed and it already sets SoC to MMU/virtual mode. Bootstrapping code re-initializes MMU after image-load/kernel -uncompressing with new kernel compatible setup. DDR-ram init and MMU BootRom/bootstrapping code is made by Marvell, and becouse this 88F6281 is quite old chip Marwell-people might not update U-boot Kirkwood code anymore. At BootRom MMU-setup there is some limitations with image relocation which must be noticed by Kirkwood U-boot port. Anyway, PowerPC style fdt-load should be done with armel/armh -ports, too. KTA Kari Tanninen kirjoitti 5.3.2018 10:27: I think GuruPlug doesn't have SPI-flash -> BootRom is executed before U-boot -> virtual memory is set-up for MMU for U-boot. 88F6281 SoC is probably using Kirkwood series 12KB BootRom ver. 1.21 or later, but I cannot find prom source code (propietary/NDA stuff?). 88F6281 prom MMU memory setup is documented and there is some limitations for virtual memory address space (for physical/PCI memory address space mapping tables) after MMU setup and image needs special header -> special uImage format needed (?). In my case, I guess when loading fdt separatelly U-boots can set memory paging correctly for uInitrd. Loading to wrong place (=too high?) it overlaps virtul memory swithing tables. It depends ARM based SoC manufacturers BootRom MMU setups, if separete fdt loading is usable for general linux kernel/bootloder API. What will be d-i debian-armel policy? KTA Kari Tanninen kirjoitti 4.3.2018 20:08: To be exact, I have Guruplug Server plus -version, and this device SoC is 88F6281. KariT Kari Tanninen kirjoitti 4.3.2018 15:11: Ben wrote: "This behaviour is configurable. For armel and armhf we enable CONFIG_ARM_ATAG_DTB_COMPAT and CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER so that ATAG variables override the DTB" That is obvious cause of these uInitrd relocation problems. I don't exactly know how U-boot passes ATAG-values to kernel but in multiprocessing environment it is very difficult task anyway (and there is even BareBox forked from U-boot for non-flexible attitude of U-boot for these kernel/bootloader API issues). ARM MMU/multiprocessing environment is straightforward, but very complex. I found GuruPlug PXA168 SoC specifications, but there is thousands of pages of information and it is very difficult to guess how kernel/U-boot uses it. Linux kernel is expecting very complete setup on boot, and most difficult part (MMU init) must be done on bootloader. I think that BareBox approach is not very healthy either, there is some odd features to use FDT, too. Keeping up two versions of FDT, for example. Best way to do it with Linux -kernel is to use one FDT-blob generated by kconfig at kernel compile and load it by bootloader. At Kernel API point of view that should be same situation as PC and command line parameters and other boot-time variables is supplied by bootloader by modifying FDT-blob (for example "choosen") nodes. KariT Ben Hutchings kirjoitti 3.3.2018 16:13: On Fri, 2018-03-02 at 14:48 +0200, Kari Tanninen wrote: "In Debian installer, for the various plug devices, we append to the DTB at the end of the kernel rather than loading it separately." Is that possible/reasonable? U-boot have to link all files on boot and it is impossibe to append command line parametres to fdt-blob without resize fdt-blob at U-boot. U-boot is using physical addressing only(?) and I think kernel cannot resize itself before boot without relocation problems -> bootm_size variable issue. If fdt is used, kernel should discard ATAG-variables by default, I think. [...] This behaviour is configurable. For armel and armhf we enable CONFIG_ARM_ATAG_DTB_COMPAT and CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER so that ATAG variables override the DTB. Ben.
