Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On 12/03/2014 05:45 PM, Samuel Thibault wrote: Gedalya, le Wed 03 Dec 2014 17:22:41 -0500, a écrit : On 12/03/2014 05:12 PM, Samuel Thibault wrote: I'm not sure to understand what the original bug report is about precisely. AIUI, it is about the following scenario: 1) install debian in a Xen domU, ending up with systemd installed by default 2) install sysvinit-core to switch back to sysvinit boot 3) end up having to fix this and that to get sysvinit work properly "this and that" being very specifically one line added to inittab: co:2345:respawn:/sbin/getty hvc0 9600 linux Given the above scenario this needs to be done by hand. As I understand the code, currently d-i would still add that for the user, if /etc/inittab existed, and it doesn't because sysvinit-core is not installed. Well, yes. But this does not seem surprising to me: again, usually d-i tunes packages which it has installed. It doesn't tune much what could potentially get installed later on. And it should for sure not install a complete /etc/inittab, that would only confuse people who were used to configure things there. I'm just wondering one thing: between steps 1) and 2), does the installed system (using systemd) properly have a login banner on hvc0? It does. The problem occurs only after installing sysvinit-core. If the user really depends on a console then they would need to add this line before rebooting, and we can expect that they might not know to do so. Well, changing the init system is not something trivial indeed. What is new here is that sysvinit-core can now get initially installed not from d-i. And thus the tuning usually done by d-i can't work. Also, we probably have to think about ping-pong scenarii: install sysvinit-core, then switch back to systemd, purge sysvinit-core, and drop /etc/inittab. Change one's mind again, reinstall sysvinit-core. We still want to have a console on /dev/hvc0. We're far from d-i, so it'd rather be sysvinit-core which does the job of adding the console to inittab. Can't some of the logic in finish-install's 90console simply moved to sysvinit-core's postinst? The bug I initially opened was against sysvinit, asking for exactly this, and citing a case where this was already done, recently. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f9fa4.9080...@gedalya.net
Bug#771864: libdebian-installer - dependency resolver support excluding packages
Asbjørn Sloth Tønnesen (2014-12-03): > retitle 771864 libdebian-installer - dependency resolver needs to support > excluding packages > tags 771864 patch > thanks > > I have attached a more complete patch > > commit 44c141d0d050f8cc3f9311c07ddc42a0baf69092 > Author: Asbjørn Sloth Tønnesen > Date: Wed Dec 3 22:55:07 2014 + > > Add preference for resolving conditional dependencies > > Previously when parsing "Depends: A | B | C" only > a dependency on A would be registered. This patch > makes it possible to pass an di_slist of packages > to be skip on such a list, ie. if a was in the > exclude list, b would be considered, and so on. > If both A, B and C is on the exclude list, C > would be used anyway. > > This doesn't implement complete exclude support, > but support excluding packages in that are pulled > in via conditional dependencies. > > I have knownily broken the ABI for di_packages_special_read_file(), > since accordingly to codesearch.d.n it is only > used internally. > > Signed-off-by: Asbjørn Sloth Tønnesen > > include/debian-installer/package_internal.h | 1 + > include/debian-installer/packages.h | 33 > + > include/debian-installer/system/packages.h | 4 ++-- > src/package_parser.c| 27 ++- > src/packages_parser.c | 5 +++-- > 5 files changed, 61 insertions(+), 9 deletions(-) > > -- > Best regards > Asbjørn Sloth Tønnesen Thanks for the patch, but clearly not for jessie. Mraw, KiBi. signature.asc Description: Digital signature
Processed: Re: libdebian-installer - dependency resolver support excluding packages
Processing commands for cont...@bugs.debian.org: > retitle 771864 libdebian-installer - dependency resolver needs to support > excluding packages Bug #771864 [libdebian-installer] libdebian-installer - dependency resolver support excluding packages Changed Bug title to 'libdebian-installer - dependency resolver needs to support excluding packages' from 'libdebian-installer - dependency resolver support excluding packages' > tags 771864 patch Bug #771864 [libdebian-installer] libdebian-installer - dependency resolver needs to support excluding packages Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 771864: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771864 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.141764916125526.transcr...@bugs.debian.org
Bug#771864: libdebian-installer - dependency resolver support excluding packages
retitle 771864 libdebian-installer - dependency resolver needs to support excluding packages tags 771864 patch thanks I have attached a more complete patch commit 44c141d0d050f8cc3f9311c07ddc42a0baf69092 Author: Asbjørn Sloth Tønnesen Date: Wed Dec 3 22:55:07 2014 + Add preference for resolving conditional dependencies Previously when parsing "Depends: A | B | C" only a dependency on A would be registered. This patch makes it possible to pass an di_slist of packages to be skip on such a list, ie. if a was in the exclude list, b would be considered, and so on. If both A, B and C is on the exclude list, C would be used anyway. This doesn't implement complete exclude support, but support excluding packages in that are pulled in via conditional dependencies. I have knownily broken the ABI for di_packages_special_read_file(), since accordingly to codesearch.d.n it is only used internally. Signed-off-by: Asbjørn Sloth Tønnesen include/debian-installer/package_internal.h | 1 + include/debian-installer/packages.h | 33 + include/debian-installer/system/packages.h | 4 ++-- src/package_parser.c| 27 ++- src/packages_parser.c | 5 +++-- 5 files changed, 61 insertions(+), 9 deletions(-) -- Best regards Asbjørn Sloth Tønnesen exclude.patch Description: Binary data
Bug#771970: jenkins.d.n: test d-i over serial console
package: d-i.debian.org, qa.debian.org User: qa.debian@packages.debian.org Usertags: jenkins severity: wishlist Hi, there should be jenkins.d.n jobs testing d-i over serial console, so filing a bug, so that I don't forget :-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: vt2-6 still not available with base system
Am 03.12.2014 um 22:42 schrieb Samuel Thibault: > Simon McVittie, le Sun 09 Nov 2014 20:43:36 +, a écrit : >> I'm very tempted to say systemd in Debian should just make these 5 >> symlinks to preserve traditional Debian behaviour, at least for >> jessie. It doesn't really even need to run systemctl, it can just use >> ln -s or whatever. People who are so desperately short of memory that >> 5 agetty instances are undesired can always disable them. >> >> If you want it to be clear that it's a Debian-specific thing that's >> pulling them in, maybe it would be better to add a new >> debian-gettys.target or debian-gettys.service that Wants them, and make >> it WantedBy an appropriate target? > > That looks like the simplest way for now. Does anyone want to look into this and provide a patch for such a "static" gettys target. Maybe we could even make it Conditional on /usr/bin/dbus-daemon not being installed. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Providing (armhf) u-boot images together with d-i images?
On 2014-12-03, Karsten Merker wrote:
> several armhf systems do not have u-boot (or another firmware) in
> non-volatile (i.e. ROM/Flash) memory, but instead store their
> system firmware on a removable medium such as an SD card.
...
> Debian provides appropriate u-boot images for several supported
> systems in the u-boot-{exynos,imx,omap,sunxi} packages, but those
> are not easily accessible to somebody who does not already run a
> Debian/armhf system (or at least Debian on another architecture),
> so I am wondering whether we should offer these u-boot images
> (in unpacked form) together with the d-i images, similar to what
> we do with the device-tree files extracted from the linux-image
> package.
Simply extracting the relevent u-boot files doesn't seem like enough to
me. They still need to be installed at particular offsets to the raw SD
card, or in some cases, to a fat partition on the SD card, though may be
fussy about exactly where on the fat partition it resides in a rather
hair-pulling way... so providing just the binaries makes it a little
easier, but not a whole lot.
Providing complete u-boot images for each platform would be 19 images
for jessie, though each one is fairly small (each between
0.5-1M). Though I don't think we've consolidated all documentation
needed to generate all those platforms with the correct offsets (though
many are all the same, such as sunxi).
For images such as hd-media, we'd ideally want to provide complete
u-boot + kernel + initrd ( + gtk initrd) images, which would grow each
image considerably.
Could provide images that get concatenated together, one for the u-boot,
and one for the partition... netboot images could probably get away with
just u-boot, or u-boot with some text files (uEnv.txt) to edit. It
would be fairly easy to write a script to handle that for Debian. Not
sure how feasible it would be to write scripts for other GNU/Linux
systems, Windows or MacOS to handle that...
If we limited full images to known-tested platforms, we'd still get a
decent spread of images; I have tested wandboard-quad, cubox-i (i4pro),
beaglebone black, cubieboard and bananapi, and all either work or have
patches pending.
I'd be happy to put a bit more time into it, especially if we can get
support in for Jessie's debian-installer.
live well,
vagrant
signature.asc
Description: PGP signature
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
Gedalya, le Wed 03 Dec 2014 17:22:41 -0500, a écrit : > > On 12/03/2014 05:12 PM, Samuel Thibault wrote: > >I'm not sure to understand what the original bug report is about > >precisely. AIUI, it is about the following scenario: > > > >1) install debian in a Xen domU, ending up with systemd installed by > >default > >2) install sysvinit-core to switch back to sysvinit boot > >3) end up having to fix this and that to get sysvinit work properly > "this and that" being very specifically one line added to inittab: > co:2345:respawn:/sbin/getty hvc0 9600 linux > Given the above scenario this needs to be done by hand. > As I understand the code, currently d-i would still add that for the user, > if /etc/inittab existed, and it doesn't because sysvinit-core is not > installed. Well, yes. But this does not seem surprising to me: again, usually d-i tunes packages which it has installed. It doesn't tune much what could potentially get installed later on. And it should for sure not install a complete /etc/inittab, that would only confuse people who were used to configure things there. > >I'm just wondering one thing: between steps 1) and 2), does the > >installed system (using systemd) properly have a login banner on hvc0? > It does. The problem occurs only after installing sysvinit-core. If the user > really depends on a console then they would need to add this line before > rebooting, and we can expect that they might not know to do so. Well, changing the init system is not something trivial indeed. What is new here is that sysvinit-core can now get initially installed not from d-i. And thus the tuning usually done by d-i can't work. Also, we probably have to think about ping-pong scenarii: install sysvinit-core, then switch back to systemd, purge sysvinit-core, and drop /etc/inittab. Change one's mind again, reinstall sysvinit-core. We still want to have a console on /dev/hvc0. We're far from d-i, so it'd rather be sysvinit-core which does the job of adding the console to inittab. Can't some of the logic in finish-install's 90console simply moved to sysvinit-core's postinst? Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203224545.gi3...@type.youpi.perso.aquilenet.fr
Bug#769406: Serial console not set up after serial install
Hello, Geert Stappers, le Wed 03 Dec 2014 22:30:39 +0100, a écrit : > Jan 1 21:50:07 kernel: [0.00] Command line: > BOOT_IMAGE=http://alpaca.gpm.stappers.nl/d-i/jessie/amd64/linux vga=normal > console=ttyS0,19200,n8 -- > initrd=http://alpaca.gpm.stappers.nl/d-i/jessie/amd64/initrd.gz Options to be propagated to the installed kernel have to be put after --. With the recent kernel change which lead to #764675, it's actually now ---, so it'd be something like > vga=normal initrd=http://alpaca.gpm.stappers.nl/d-i/jessie/amd64/initrd.gz > --- console=ttyS0,19200,n8 How were this console= parameter added precisely? I have added to the manual's Boot Parameters section an explicit mention of this. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203222900.gh3...@type.youpi.perso.aquilenet.fr
Re: Providing (armhf) u-boot images together with d-i images?
On Wed, 3 Dec 2014 23:09:17 +0100
Karsten Merker wrote:
> several armhf systems do not have u-boot (or another firmware) in
> non-volatile (i.e. ROM/Flash) memory, but instead store their
> system firmware on a removable medium such as an SD card. In
> many cases the user does not receive a suitable firmware medium
> when buying the hardware, because the vendors often expect these
> devices to be used with pre-built android images. This means
> that a user who has freshly bought such a system and wants to
> install Debian on it, has to first find and install an appropriate
> u-boot image to be able to start d-i.
vmdebootstrap can create a suitable image although it isn't actually
the installer. There is an example script for beaglebone-black and if
someone has the knowledge of the u-boot setup for particular boards,
that can be added to the examples.
This gets around the problem of needing armhf setup first, via qemu.
> Debian provides appropriate u-boot images for several supported
> systems in the u-boot-{exynos,imx,omap,sunxi} packages, but those
> are not easily accessible to somebody who does not already run a
> Debian/armhf system (or at least Debian on another architecture),
There's also a lack of documentation of exactly how to use the u-boot
files for some boards and get to a working uboot.
> so I am wondering whether we should offer these u-boot images
> (in unpacked form) together with the d-i images, similar to what
> we do with the device-tree files extracted from the linux-image
> package.
The modules.tgz would also be handy...
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpp1B9A5S0K6.pgp
Description: OpenPGP digital signature
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On 12/03/2014 05:12 PM, Samuel Thibault wrote: I'm not sure to understand what the original bug report is about precisely. AIUI, it is about the following scenario: 1) install debian in a Xen domU, ending up with systemd installed by default 2) install sysvinit-core to switch back to sysvinit boot 3) end up having to fix this and that to get sysvinit work properly "this and that" being very specifically one line added to inittab: co:2345:respawn:/sbin/getty hvc0 9600 linux Given the above scenario this needs to be done by hand. As I understand the code, currently d-i would still add that for the user, if /etc/inittab existed, and it doesn't because sysvinit-core is not installed. I'm not aware of any other issue. I am not very surprised that it does not work. The various tuning that d-i does usually only work on what gets installed during d-i, not on what gets installed later on. That's particularly the case for software which doesn't provide nice hooks for d-i to use them. I'm just wondering one thing: between steps 1) and 2), does the installed system (using systemd) properly have a login banner on hvc0? It does. The problem occurs only after installing sysvinit-core. If the user really depends on a console then they would need to add this line before rebooting, and we can expect that they might not know to do so. If not, then it's indeed a problem, but not related with sysvinit and inittab. In the current logic, some more code should be added to finish-install's 90console script to handle the systemd case. I don't have a Xen system offhand to easily test that. Cyril Brulebois, le Mon 10 Nov 2014 20:51:28 +0100, a écrit : Would it make any sense to have $something created by d-i, consumed by both systemd and sysvinit to make sure consoles are available? It would make sense, but I'm not sure we can manage to write something that both sysvinit and systemd can understand easily. "include" support could be added to sysvinit, and /etc/inittab made to include the d-i-generate bits, but it'd still be in inittab format, which AIUI systemd wouldn't grok. So it would be something else, but then we would have to make sysvinit aware of what a serial login is, which it has never been made to, for flexibility reasons. Of course if I'm conflating issues that are orthogonal, please say so and we'll track both issues separately. I actually haven't quoted the vt2-6 issue here because I don't think it is related with d-i. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f8d31.8090...@gedalya.net
Processed: Re: Bug#769407: Should set up Grub for serial and console
Processing control commands: > reassign -1 grub-installer Bug #769407 [debian-installer] Should set up Grub for serial and console Bug reassigned from package 'debian-installer' to 'grub-installer'. No longer marked as found in versions 20141112-00:20. Ignoring request to alter fixed versions of bug #769407 to the same values previously set -- 769407: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769407 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.b769407.141764489530512.transcr...@bugs.debian.org
Bug#769407: Should set up Grub for serial and console
Control: reassign -1 grub-installer Geert Stappers, le Wed 03 Dec 2014 22:35:21 +0100, a écrit : > On Thu, Nov 13, 2014 at 02:19:50PM +0100, martin f krafft wrote: > > Following an install with > > > > auto console=tty0 console=ttyS0,115200n8 > > > > on the command line and using yesterday's amd64 daily jessie > > installer, the /etc/default/grub file had GRUB_TERMINAL=serial > > enabled. Please set that to > > > > GRUB_TERMINAL="console serial" > > > > to allow Grub to display on both, which it has supported for > > a while. > > To which package should this bugreport be assigned? This part is handled by grub-installer, reassigning. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203221446.gg3...@type.youpi.perso.aquilenet.fr
Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
I'm not sure to understand what the original bug report is about precisely. AIUI, it is about the following scenario: 1) install debian in a Xen domU, ending up with systemd installed by default 2) install sysvinit-core to switch back to sysvinit boot 3) end up having to fix this and that to get sysvinit work properly I am not very surprised that it does not work. The various tuning that d-i does usually only work on what gets installed during d-i, not on what gets installed later on. That's particularly the case for software which doesn't provide nice hooks for d-i to use them. I'm just wondering one thing: between steps 1) and 2), does the installed system (using systemd) properly have a login banner on hvc0? If not, then it's indeed a problem, but not related with sysvinit and inittab. In the current logic, some more code should be added to finish-install's 90console script to handle the systemd case. I don't have a Xen system offhand to easily test that. Cyril Brulebois, le Mon 10 Nov 2014 20:51:28 +0100, a écrit : > Would it make any sense to have $something created by d-i, consumed by > both systemd and sysvinit to make sure consoles are available? It would make sense, but I'm not sure we can manage to write something that both sysvinit and systemd can understand easily. "include" support could be added to sysvinit, and /etc/inittab made to include the d-i-generate bits, but it'd still be in inittab format, which AIUI systemd wouldn't grok. So it would be something else, but then we would have to make sysvinit aware of what a serial login is, which it has never been made to, for flexibility reasons. > Of course if I'm conflating issues that are orthogonal, please say so > and we'll track both issues separately. I actually haven't quoted the vt2-6 issue here because I don't think it is related with d-i. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203221226.gf3...@type.youpi.perso.aquilenet.fr
Providing (armhf) u-boot images together with d-i images?
Hello,
several armhf systems do not have u-boot (or another firmware) in
non-volatile (i.e. ROM/Flash) memory, but instead store their
system firmware on a removable medium such as an SD card. In
many cases the user does not receive a suitable firmware medium
when buying the hardware, because the vendors often expect these
devices to be used with pre-built android images. This means
that a user who has freshly bought such a system and wants to
install Debian on it, has to first find and install an appropriate
u-boot image to be able to start d-i.
Debian provides appropriate u-boot images for several supported
systems in the u-boot-{exynos,imx,omap,sunxi} packages, but those
are not easily accessible to somebody who does not already run a
Debian/armhf system (or at least Debian on another architecture),
so I am wondering whether we should offer these u-boot images
(in unpacked form) together with the d-i images, similar to what
we do with the device-tree files extracted from the linux-image
package.
Comments welcome :-).
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141203220916.ga17...@excalibur.cnev.de
Re: vt2-6 still not available with base system
Simon McVittie, le Sun 09 Nov 2014 20:43:36 +, a écrit : > I'm very tempted to say systemd in Debian should just make these 5 > symlinks to preserve traditional Debian behaviour, at least for > jessie. It doesn't really even need to run systemctl, it can just use > ln -s or whatever. People who are so desperately short of memory that > 5 agetty instances are undesired can always disable them. > > If you want it to be clear that it's a Debian-specific thing that's > pulling them in, maybe it would be better to add a new > debian-gettys.target or debian-gettys.service that Wants them, and make > it WantedBy an appropriate target? That looks like the simplest way for now. > A generator could be conditional on the absence of dbus.service, or > some such, but then again so could a debian-gettys.service with > ConditionPathExists=!/lib/systemd/system/dbus.service. Indeed. I'd however tend to just always start them, thus fixing along the way bug #760916 which is a pain for blind people, and for which I don't even know where to start debugging. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203214216.ga10...@type.youpi.perso.aquilenet.fr
Processed: tagging 764026
Processing commands for cont...@bugs.debian.org: > tags 764026 + pending Bug #764026 [installation-guide] installation-guide: update manual for the desktop changes Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 764026: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764026 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.141764256713985.transcr...@bugs.debian.org
Bug#769407: Should set up Grub for serial and console
On Thu, Nov 13, 2014 at 02:19:50PM +0100, martin f krafft wrote: > Package: debian-installer > Version: 20141112-00:20 > Severity: wishlist > > Following an install with > > auto console=tty0 console=ttyS0,115200n8 > > on the command line and using yesterday's amd64 daily jessie > installer, the /etc/default/grub file had GRUB_TERMINAL=serial > enabled. Please set that to > > GRUB_TERMINAL="console serial" > > to allow Grub to display on both, which it has supported for > a while. To which package should this bugreport be assigned? Groeten Geert Stappers Not sure if this BR should be merged with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769406 -- Leven en laten leven -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203213521.gx3...@gpm.stappers.nl
Re: Grub EFI fallback - patches for review
On Wed, Dec 03, 2014 at 04:18:23PM +, Steve McIntyre wrote: > >A more generic fix would be to add to a list of filesystems that need >unmounting, and trap to a new shell function that unmounts that >list. Not too hard, I think - I'll see if I can do that and get it >tested today. > >Frankly, I'd also like to move mountvirtfs and that new function over >to a more central d-i scripts location and cut down on the duplicated >code. That's definitely something for post-jessie, as it's going to >potentially cut across a lot of the d-i packages. >>The unmount is wanted or the leaving of /boot/efi mounted is? (I could >>see an argument either way actually). > >I need to make sure that /target/boot/efi is unmounted; otherwise >exiting and re-entering the rescue menu fails. > >Updated patch coming soon... And here it is. Differences from v1 are: * s/UEFI/EFI/ in messages for consistency * s/step_force_efi/step_force_efi_removable/ * Better handling of mounting and unmounting -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me >From cb00fb6bcae21d0628bd11e959629adae9c8fe39 Mon Sep 17 00:00:00 2001 From: Steve McIntyre Date: Wed, 3 Dec 2014 17:50:17 + Subject: [PATCH] Add support for using the UEFI removable media path Either during installation (low priority or preseeding), or as an extra rescue-mode option to help people fix their systems post-install once they realise they need to. (#767037) --- debian/changelog| 10 debian/grub-installer.templates | 43 ++ grub-installer | 14 + rescue.d/81grub-efi-force-removable | 93 +++ rescue.d/81grub-efi-force-removable.tst |3 + 5 files changed, 163 insertions(+) create mode 100755 rescue.d/81grub-efi-force-removable create mode 100755 rescue.d/81grub-efi-force-removable.tst diff --git a/debian/changelog b/debian/changelog index 6d94005..2879e27 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +grub-installer (1.102) unstable; urgency=medium + + [ Steve McIntyre ] + * Add extra support for forcing installation to the EFI +removable media path, either during installation (low priority or +preseeding), or as an extra rescue-mode option to help people fix +their systems post-install once they realise they need to. (#767037) + + -- Steve McIntyre <93...@debian.org> Mon, 01 Dec 2014 02:49:36 + + grub-installer (1.101) unstable; urgency=medium [ Steve McIntyre ] diff --git a/debian/grub-installer.templates b/debian/grub-installer.templates index e439ad0..e294afb 100644 --- a/debian/grub-installer.templates +++ b/debian/grub-installer.templates @@ -209,6 +209,21 @@ Type: text # :sl1: _Description: Updating /etc/kernel-img.conf... +Template: grub-installer/progress/step_force_efi_removable +Type: text +# :sl1: +_Description: Checking whether to force usage of the removable media path + +Template: grub-installer/progress/step_mount_filesystems +Type: text +# :sl1: +_Description: Mounting filesystems + +Template: grub-installer/progress/step_update_debconf_efi_removable +Type: text +# :sl1: +_Description: Configuring grub-efi for future usage of the removable media path + Template: debian-installer/grub-installer/title Type: text # Main menu item @@ -242,3 +257,31 @@ _Description: Failed to mount /target/proc Check /var/log/syslog or see virtual console 4 for the details. . Warning: Your system may be unbootable! + +Template: rescue/menu/grub-efi-force-removable +Type: text +# Rescue menu item +# :sl2: +_Description: Force GRUB installation to the EFI removable media path + +Template: grub-installer/force-efi-extra-removable +Type: boolean +Default: false +# :sl1: +_Description: Force GRUB installation to the EFI removable media path? + It seems that this computer is configured to boot via EFI, but maybe + that configuration will not work for booting from the hard + drive. Some EFI firmware implementations do not meet the EFI + specification (i.e. they are buggy!) and do not support proper + configuration of boot options from system hard drives. + . + A workaround for this problem is to install an extra copy of the EFI + version of the GRUB boot loader to a fallback location, the + "removable media path". Almost all EFI systems, no matter how buggy, + will boot GRUB that way. + . + Warning: If the installer failed to detect another operating system + that is present on your computer that also depends on this fallback, + installing GRUB there will make that operating system temporarily + unbootable. GRUB can be manually configured later to boot it if + necessary. diff --git a/grub-installer b/grub-installer index 4c12998..ef81dbf 100755 --- a/grub-installer +++ b/grub-installer @@ -785,6 +785,20 @@ if [ -z "$frdisk" ]; then fi fi + # Should we force a copy of
Re: Grub EFI fallback - patches for review
On Wed, Dec 03, 2014 at 09:44:08AM +, Ian Campbell wrote:
>On Wed, 2014-12-03 at 02:10 +, Steve McIntyre wrote:
>> >
>> >> +mountvirtfs () {
>> >> + fstype="$1"
>> >> + path="$2"
>> >> + if grep -q "[[:space:]]$fstype\$" /proc/filesystems && \
>> >> + ! grep -q "^[^ ]\+ \+$path " /proc/mounts; then
>> >> + mkdir -p "$path" || \
>> >> + die grub-installer/mounterr "Error creating $path"
>> >> + mount -t "$fstype" "$fstype" "$path" || \
>> >> + die grub-installer/mounterr "Error mounting $path"
>> >> + trap "umount $path" HUP INT QUIT KILL PIPE TERM EXIT
>> >
>> >trap doesn't stack, does it? You call mountvirtfs twice, so only the
>> >second umount will actually happen on error.
>>
>> True. This (buggy) code is already in use elsewhere in grub-installer,
>> I've just borrowed it. :-/
>
>Hrm, yes.
A more generic fix would be to add to a list of filesystems that need
unmounting, and trap to a new shell function that unmounts that
list. Not too hard, I think - I'll see if I can do that and get it
tested today.
Frankly, I'd also like to move mountvirtfs and that new function over
to a more central d-i scripts location and cut down on the duplicated
code. That's definitely something for post-jessie, as it's going to
potentially cut across a lot of the d-i packages.
>> Right. I've absolutely *no* idea how well any of the existing EFI
>> stuff will work with BSD...!
>
>Me neither.
Again, I'm tempted to leave that alone for now then.
>> >The main invocation would invoke this with a --target="foo-efi". Not
>> >sure if this matters or not.
>>
>> Nope, the code in grub-install already picks up on the right platform
>> by default. I could add this too, but I'm not convinved it's necessary.
>
>Lets leave it then.
Agreed.
>> >In order to avoid having to repeat all the logic twice perhaps you could
>> >arrange to do the debconf-set-selections thing first and then run
>> >dpkg-reconfigure or something in the target to force the main postinst
>> >to rerun and reinstall?
>>
>> Maybe, yeah. I'll take a look.
>>
>> >> + db_input critical grub-installer/grub-install-failed || true
>> >> + db_go || true
>> >> + db_progress STOP
>> >> + exit 1
>> >
>> >You don't umount /target/boot/efi on this path.
>>
>> Correct, and that's definitely wanted.
>
>The unmount is wanted or the leaving of /boot/efi mounted is? (I could
>see an argument either way actually).
I need to make sure that /target/boot/efi is unmounted; otherwise
exiting and re-entering the rescue menu fails.
Updated patch coming soon...
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141203161823.gv16...@einval.com
Bug#761815: wow, huh
I just got bitten by this bug myself. As a long time gentoo + ubuntu user, I was baffled after getting the solution to this problem. I have worked through several different kind of fstab files, but this was a serious wtf. Why wasn't removable storage working for me? I just couldn't figure it out, everything 'looked' normal. I'd increase the severity of this report, as it is far far from obvious. Olliver -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/547f2ab4.8020...@schinagl.nl
Re: Grub EFI fallback - patches for review
On Wed, Dec 03, 2014 at 09:42:20AM +, Ian Campbell wrote: >On Wed, 2014-12-03 at 01:55 +, Steve McIntyre wrote: >> On Tue, Dec 02, 2014 at 08:36:31AM +, Ian Campbell wrote: >> >On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote: >> > >> >Starting with grub-install-fallback.patch: >> > >> >> >From e384e597914b6e1b1dcbf96ef6782cf9bcc2313b Mon Sep 17 00:00:00 2001 >> >> debian/patches/grub-install-extra-removable.patch | 115 >> >> ++ >> > >> >Could you send this to grub-de...@gnu.org? Or at least provide a commit >> >log for the upstream bit inline in the patch for whoever does end up >> >forwarding it. >> >> Sure, no problem. I've added a header for now. As my stuff is >> intermingled with other changes in the Debian tree, I'm not sure how >> well that will work upstream... > >Ah yes, if it is dependent on other non-upstream stuff then probably no >point sending off in isolation. ACK. It's not *functionally* dependent, but it's intermingled in the patches. >> Rebased patch V2 against current git master attached... > >Looks good to me. Cool. I don't (think I) have push access to the git repo, so if you could do the honours and apply, that would be lovely. :-) I'm also wanting to get this into Jessie if we can, along with the 32-bit EFI work that's next...! -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141203152655.gu16...@einval.com
Document syntax for X-Debbugs-CC with more than one mail address [ Re: Bug#771607: unblock: brltty/5.2~20141018-2 ]
Hi, Holger Levsen wrote: > On Montag, 1. Dezember 2014, Samuel Thibault wrote: > > X-Debbugs-Cc: debian-boot@lists.debian.org > > X-Debbugs-Cc: debian-accessibil...@lists.debian.org > > > > I then guess bts only keep the last one. > > seperating them with commas on the same line works. Maybe it should be documented on https://www.debian.org/Bugs/Reporting, how to insert more than one mail address to a X-Debbugs-Cc: line? I have prepared a patch, attached. debian-www in CC. So long Holger -- Created with Sylpheed 3.2.0 under the new D E B I A N L I N U X 7 . 0 W H E E Z Y ! Registered Linux User #311290 - https://linuxcounter.net/ Index: english/Bugs/Reporting.wml === RCS file: /cvs/webwml/webwml/english/Bugs/Reporting.wml,v retrieving revision 1.79 diff -u -r1.79 Reporting.wml --- english/Bugs/Reporting.wml 30 Apr 2014 06:29:26 - 1.79 +++ english/Bugs/Reporting.wml 3 Dec 2014 10:26:09 - @@ -216,6 +216,9 @@ to the address(es) in the X-Debbugs-CC line as well as to debian-bugs-dist. +If you want to sent copies to more than address, add them +comma-separated in only one X-Debbugs-CC line. + Avoid sending such copies to the addresses of other bug reports, as they will be caught by the checks that prevent mail loops. There is relatively little point in using X-Debbugs-CC for this
Re: Grub EFI fallback - patches for review
On Wed, 2014-12-03 at 02:10 +, Steve McIntyre wrote:
> On Tue, Dec 02, 2014 at 08:51:24AM +, Ian Campbell wrote:
> >On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote:
> >I didn't review the text since that seems to have been done already.
> >
> >> diff --git a/rescue.d/81grub-efi-force-removable
> >> b/rescue.d/81grub-efi-force-removable
> >
> >I don't know much about rescue mode, is this offering an automatic fixup
> >for this issue? Does it appear in a menu to be selected rather than
> >asking everyone booting rescue on an EFI system?
>
> The .tst file is run as a test:
>
> [ -f /target/boot/grub/grub.cfg ] && ( grep -q /boot/efi /target/etc/fstab )
>
> So, the target system must have grub installed and a mention of
> /boot/efi in /etc/fstab. Assuming that it does, an extra rescue option
> of "Force GRUB installation to the EFI removable media path" will show
> up as an option for the user. If the user selects it, the help text in
> grub-installer/force-efi-extra-removable is shown, then they can
> select to set the option.
>
Neat, thanks for explaining.
> >
> >> +mountvirtfs () {
> >> + fstype="$1"
> >> + path="$2"
> >> + if grep -q "[[:space:]]$fstype\$" /proc/filesystems && \
> >> + ! grep -q "^[^ ]\+ \+$path " /proc/mounts; then
> >> + mkdir -p "$path" || \
> >> + die grub-installer/mounterr "Error creating $path"
> >> + mount -t "$fstype" "$fstype" "$path" || \
> >> + die grub-installer/mounterr "Error mounting $path"
> >> + trap "umount $path" HUP INT QUIT KILL PIPE TERM EXIT
> >
> >trap doesn't stack, does it? You call mountvirtfs twice, so only the
> >second umount will actually happen on error.
>
> True. This (buggy) code is already in use elsewhere in grub-installer,
> I've just borrowed it. :-/
Hrm, yes.
> >Also you umount explicitly on the exit path, but don't cancel this trap,
> >so I guess you'll see some noise from umount the second time.
>
> True; I've not seen any such errors, as it seems they're hidden at
> that point.
>
> >I know we've established that in-target isn't widely used in this
> >particular bit of code -- but it does take care of all this sort of
> >thing automatically and (presumably!) correctly, as well as being only a
> >single place to fix if it is wrong (e.g. in-target handles BSD
> >explicitly too).
>
> Right. I've absolutely *no* idea how well any of the existing EFI
> stuff will work with BSD...!
Me neither.
> >> +log "Mounting filesystems"
> >> +# If we're installing grub-efi, it wants /sys mounted in the
> >> +# target. Maybe /proc too?
> >> +mountvirtfs proc /target/proc
> >> +mountvirtfs sysfs /target/sys
> >> +chroot /target mount /boot/efi || true
> >> +
> >> +db_progress STEP 1
> >> +db_progress INFO grub-installer/progress/step_install_loader
> >> +# Do the installation now
> >> +log "Running grub-install"
> >> +if ! chroot /target grub-install --force-extra-removable; then
> >
> >The main invocation would invoke this with a --target="foo-efi". Not
> >sure if this matters or not.
>
> Nope, the code in grub-install already picks up on the right platform
> by default. I could add this too, but I'm not convinved it's necessary.
Lets leave it then.
> >In order to avoid having to repeat all the logic twice perhaps you could
> >arrange to do the debconf-set-selections thing first and then run
> >dpkg-reconfigure or something in the target to force the main postinst
> >to rerun and reinstall?
>
> Maybe, yeah. I'll take a look.
>
> >> + db_input critical grub-installer/grub-install-failed || true
> >> + db_go || true
> >> + db_progress STOP
> >> + exit 1
> >
> >You don't umount /target/boot/efi on this path.
>
> Correct, and that's definitely wanted.
The unmount is wanted or the leaving of /boot/efi mounted is? (I could
see an argument either way actually).
Ian.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1417599848.29004.20.ca...@hellion.org.uk
Re: Grub EFI fallback - patches for review
On Wed, 2014-12-03 at 01:55 +, Steve McIntyre wrote: > On Tue, Dec 02, 2014 at 08:36:31AM +, Ian Campbell wrote: > >On Mon, 2014-12-01 at 13:57 +, Steve McIntyre wrote: > > > >Starting with grub-install-fallback.patch: > > > >> >From e384e597914b6e1b1dcbf96ef6782cf9bcc2313b Mon Sep 17 00:00:00 2001 > >> debian/patches/grub-install-extra-removable.patch | 115 > >> ++ > > > >Could you send this to grub-de...@gnu.org? Or at least provide a commit > >log for the upstream bit inline in the patch for whoever does end up > >forwarding it. > > Sure, no problem. I've added a header for now. As my stuff is > intermingled with other changes in the Debian tree, I'm not sure how > well that will work upstream... Ah yes, if it is dependent on other non-upstream stuff then probably no point sending off in isolation. > Rebased patch V2 against current git master attached... Looks good to me. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1417599740.29004.18.ca...@hellion.org.uk
