Bug#919813: recognising devuan
So the remaining problem is that the Debian Buster os-prober did not recognise Devuan ascii. -- hendrik
Bug#919813: comparison with earlier release
Just for comparison, on Devuan ascii (stretch wirhout systend), I get: root@midwinter:/home/hendrik# os-prober File descriptor 8 (socket:[13898]) leaked on lvs invocation. Parent PID 2831: /bin/sh File descriptor 9 (socket:[13899]) leaked on lvs invocation. Parent PID 2831: /bin/sh File descriptor 10 (socket:[16454]) leaked on lvs invocation. Parent PID 2831: /bin/sh File descriptor 11 (socket:[16455]) leaked on lvs invocation. Parent PID 2831: /bin/sh File descriptor 18 (socket:[13991]) leaked on lvs invocation. Parent PID 2831: /bin/sh /dev/sda6:Debian GNU/Linux buster/sid:Debian:linux root@midwinter:/home/hendrik# Here it also does not recognise the OS it runs on, but it *does* recognise Debian. Could the problem be that it is does not recognise (a) its own OS, nor (b) any OS those root partition in on an LVM volume, even if its /boot is on a primary partition? -- hendrik
Bug#919813: os-prober fails to find any os's at all.
Package: os-prober Version: 1.77 os-prober fails to find any os's at all after a new Debian buster install, not even the installed and running DEbian buster. The install was done using the net-install CD on a USB stick on 2019 01 18, downloaded immediately before the installation. root@buster:/home/guest# os-prober root@buster:/home/guest# This was run the day after installation. The machine actually has two Linux systems installed: * the newly installed Debian buster. * /boot on /dev/sda2, and / on /dev/sda6. * Installed yesterday. * An older Devuan ascii. * /boot on /dev/sda1, and other partitions in an LVM on /dev/sda3 * Installed a few months ago. Both are now bootable from the grub2 boot menu installed by using the debian installer to install buster yesterday. Presumably the installer used os-prober succesfully, but the os-prober I installed today using aptitude does not work. Could they be different versions? I'm not aware of anything unusual about the enviromnent. It'a a Purism laptop. -- hendrik
Re: accessing efivarfs in debian-installer
On Fri, May 27, 2016 at 04:08:55PM +0100, Ben Hutchings wrote: > On Fri, 2016-05-27 at 09:13 -0400, Hendrik Boom wrote: > > On Fri, May 27, 2016 at 10:59:35AM +0100, Steve McIntyre wrote: > > > On Fri, May 27, 2016 at 10:41:39AM +0200, Francesco De Vita wrote: > > > > Hi > > > > > > > > On 25/5/2016 16:31, Cyril Brulebois wrote: > > > > > Francesco De Vita <fra...@inventati.org> (2016-05-24): > > > > > > So, is it possible to access the efivarfs interface and retrieve > > > > > > the required nvram-file inside the DI environment? > > > > > > > > > > I'm pretty sure we can do that from d-i since that's needed to get > > > > > UEFI support working AFAICT. Looking at udebs, it seems you want to > > > > > be loading this one, probably manually if you're at an early stage: > > > > > efi-modules-4.5.0-2-amd64-di_4.5.4-1_amd64.udeb > > > > > > > > > > It contains: > > > > > ./lib/modules/4.5.0-2-amd64/kernel/drivers/firmware/efi/efivars.ko > > > > > > > > > > which is likely to make it possible to access efivars, allowing you > > > > > to mount them on the mount point (which you mentioned, exists > > > > > already). > > > > > > > > This time I'm using the Stretch Alpha 6 DI. I successfully loaded the > > > > efivars module as you suggested, however the efivarfs interface remains > > > > inaccessible, it still cannot be mounted. > > > > > > > > I suppose that the efivarfs module has to be loaded too but there is no > > > > trace of efivarfs.ko in the DI and I didn't find any udeb containing > > > > it. Should I load it someway from an external source? > > > > > > Ah, that's your problem. It looks like we're not including that module > > > yet. Most EFI variable users like efibootmgr will fall back to the > > > older interfaces, so we've not noticed this yet. > > > > > > I'll go and fix that now. > > > > Wasn't mounting the efivars as a file system implicated in the complete > > bricking of someone's hardware a while ago? The problem being that it > > was too easy to rm those files, which deleted those efi variables, > > which included variable that were essential to making booting possible? > > Not just that it wouldn't boot the installed system any more; it could > > no longer boot anything, not even an operating-system installer? > > Fixed in Linux 4.5-rc5 and in 4.4.4. Now only variables on a known- > safe whitelist are allowed to be deleted. > > [...] > > Juat be very careful with efivars. > > We are. Excellent. -- hendrik
Re: accessing efivarfs in debian-installer
On Fri, May 27, 2016 at 10:59:35AM +0100, Steve McIntyre wrote: > On Fri, May 27, 2016 at 10:41:39AM +0200, Francesco De Vita wrote: > >Hi > > > >On 25/5/2016 16:31, Cyril Brulebois wrote: > >> Francesco De Vita(2016-05-24): > >> > So, is it possible to access the efivarfs interface and retrieve > >> > the required nvram-file inside the DI environment? > >> > >> I'm pretty sure we can do that from d-i since that's needed to get > >> UEFI support working AFAICT. Looking at udebs, it seems you want to > >> be loading this one, probably manually if you're at an early stage: > >> efi-modules-4.5.0-2-amd64-di_4.5.4-1_amd64.udeb > >> > >> It contains: > >> ./lib/modules/4.5.0-2-amd64/kernel/drivers/firmware/efi/efivars.ko > >> > >> which is likely to make it possible to access efivars, allowing you > >> to mount them on the mount point (which you mentioned, exists > >> already). > > > >This time I'm using the Stretch Alpha 6 DI. I successfully loaded the > >efivars module as you suggested, however the efivarfs interface remains > >inaccessible, it still cannot be mounted. > > > >I suppose that the efivarfs module has to be loaded too but there is no > >trace of efivarfs.ko in the DI and I didn't find any udeb containing > >it. Should I load it someway from an external source? > > Ah, that's your problem. It looks like we're not including that module > yet. Most EFI variable users like efibootmgr will fall back to the > older interfaces, so we've not noticed this yet. > > I'll go and fix that now. Wasn't mounting the efivars as a file system implicated in the complete bricking of someone's hardware a while ago? The problem being that it was too easy to rm those files, which deleted those efi variables, which included variable that were essential to making booting possible? Not just that it wouldn't boot the installed system any more; it could no longer boot anything, not even an operating-system installer? I'd be wary of anything that mounts the efivars. Especially leaving them mounted for more than the absolute minimum necessary to make use of them. Mind you, there was an argument that the hardware was bedly defined, in that it had no mechanism to reset the efi vars to a safe staate, the the guy who issued the rm -rf * was an idiot, and that systemd had left the efivars mounted and vulnerable. Juat be very careful with efivars. -- hendrik
Re: request
On Sun, Jan 17, 2016 at 02:54:29PM +0100, Geert Stappers wrote: > On Sun, Jan 17, 2016 at 03:06:14PM +0200, Moreanu Robert - Nicolae wrote: > > i looking to resolve this problem when I want to install debian 8.2 or 8.1. > > I receive this message after it's take to Grub install > > > > " the 'grub-pc' package failed to install into /target/ " > > after the operation of clean up on installing, i have a failed operations. > > > > I don't have such expertise, please make the debian on install with more > > information and what procedure to do that for the people don't have the > > time to study the debian. > > > > so.. how i could resolve this problem , any help from you, please > > > > robert, waiting for your response > > The mailinglist you are addressing is about development of debian-installer, > not for user requests. But this is clearly a request for a change in the debian installer -- that it provide more information on one kind of failure. Now it may be legitimate to say it's infeasible, and it may well be infeasible, but shuttong the user up without at least suggesting where he should go is, well, at least impolite. Suggesting that he submit an installation-report and that he post his question on debian-user would be appropriate. -- hendrik > > > Regards > Geert Stappers > -- > Ignoring is really harsh >
Re: Going ahead with non-free-firmware
On Sat, Jan 09, 2016 at 10:36:53PM +0100, Philippe Cerfon wrote: > And btw: > Even if Debian doesn't want to do the non-open thing now or perhaps > generally doesn't want to allow people to opt-out of closed source > software while keeping other non-free software, then the name > non-free-firmware seems to break the current naming, doesn't it? > main > contrib > non-free > > These all give the "license status" of their packages. > But non-free-firmware, would give license status and package type. > > > Oh and since this has been brought up by someone. > It seems better if packages wouldn't be in multiple suites. > That's also what I'd have intended with non-open, in other words, a > package that is in non-open is only there and not also in e.g. > non-open/firmware (and vice versa). Maybe closed-source would be clearer than non-open. -- hendrik
Re: Bug#800014: multipath-udeb: not installable: depends on libsystemd0
On Mon, Sep 28, 2015 at 11:17:42PM +0530, Ritesh Raj Sarraf wrote: > On Mon, 2015-09-28 at 18:53 +0200, Cyril Brulebois wrote: > > [ Adding debian-boot@lists.debian.org back. ] > > > > Sorry about that. > > > > > This was intentionally done because upstream added systemd > > > dependency > > > some time ago. For Jessie, I had disabled systemd support, but now, > > > it > > > makes sense to have it, and align with upstream and other > > > distributions. For the sake of derivatives without systemd, you might see if it's practical to leave the systemd dependency optional. -- hendrik > > > > > > So, I think the real question is about why libsystemd0 does not > > > have a > > > udeb ? > > > > > > systemd maintainers should provide that input. > > > > Some input from someone who doesn't know a thing about systemd or > > multipath: libmultipath.so.0 has a NEEDED entry on libsystemd.so.0, > > which seems to only define symbols named sd_* (which seems fair). The > > only use I see in libmultipath.so.0 is sd_listen_fds. > > > > Its manpage says: > > > >sd_listen_fds() shall be called by a daemon to check for file > >descriptors passed by the init system as part of the socket > > -based > >activation logic. > > > > There's no systemd in d-i, so there's no socket-based activation > > logic, > > and you can't rely on that in your multipath udeb. > > > Hmmm... I'll look into it later. But when you say "No systemd in d-i", > does it mean that is how it is going to remain ? > > -- > Ritesh Raj Sarraf | http://people.debian.org/~rrs > Debian - The Universal Operating System
Re: Kernel panic after format usb stick
On Mon, Aug 24, 2015 at 07:53:38AM -0500, Jorge Ernesto Guevara Cuenca wrote: Hello, I ejected a usb stick without umount and doesn't boot anymore, I formatted it again, prepare like the install manual[1] says and it don't boot never again. I tried with oficial images[2] and my own images created, and ever i obtain this kernel panic message: List of all partitiions: No filesystem could mount root, tried: kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) How can I use again this usb stick? I've never had a USB stick panic the kernel, but I have had them beome unusable on a random variety if systems (including Debian) if the weren't dismounted properly. fsck seemed to help. -- hendrik
Re: cdimage?? What should we call it?
On Tue, Aug 18, 2015 at 05:34:39PM +0100, Majid HUSSAIN wrote: hi there, hows about iso.debian.org? People have been calling them iso's -- hendrik it makes sence to me at least. thoughts? Majid On 18/08/2015, Simon Kainz si...@familiekainz.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Well, i created a Wiki Page for this, making it probably easier to decide upon things. I copied the already proposed names there: https://wiki.debian.org/NewNameForCDImage Bye, Simon Am 2015-08-18 um 18:15 schrieb Steve Langasek: On Tue, Aug 18, 2015 at 05:09:19PM +0100, Steve McIntyre wrote: Hey folks, We called our main installer images distribution site cdimage.debian.org a long time ago, when that was all it published and most people downloaded images of CDs. Ummm. Things have moved on in the intervening years, and this name is looking more silly over time: * lots of people are using USB sticks * we're providing live images that don't fit on CD * we're providing cloud images (Openstack so far, with others coming soon!) So, I'm looking for suggestions. What should we call it? I had initially thought that images.debian.org is more generic, but it's also likely to confuse people into looking there for pictures... :-) Please reply and let's see if we can come up with a better name. - seedy-image.debian.org - mothership.debian.org - ftp.debian.org - image-master.debian.org - get.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJV01y1AAoJEBy08PeN7K/pmF4P/1xqcLnQtAkIuR2AcMWDtKEz WAKE9Tejo+n977iU3aGRHK3jYcTkBgYPF4qaPbdQVcgrzPCMQUMJIj/jHR736Z9T 7Flqh9sNzUKLBY+TfHiKyYxehRRBFCs1nQstiZBEXaJjILlV/jiJUNuL6gVMEqmb /3LXze009YetRh/2228bCpafn5lf6KKoHXosZwBOT71cTISXVLymnP3xxeF1q2xm Z+rpUoNakF8daGXxIMqP7a7JoBKdfPBSXa2KghvRCrPqd3HbUqVGYydWvl0WeyjH TU9E7nNal8vmn99fhOOUWYOEDtDOrkNuKXC3C3vdloN1LLU8bnwhMJ2/j3yE0ao3 pgEals3UAAFY0CBv63HBfLaylQyUFCrqCkq3E7GSRbp5ayaF30L0uysVf0MOzfCU nW2rPGP9vqBB25XhvGehXH0nsj1/EN1fGvNliWR+jSC070Wmw0q9XuH+I6ZT3FFE nNW28yq+cOzl/N0edaC9gQ2ngcruiZZ7yacJEkHBqmpQKT8BjR7Qyx25GaC6icJs qYn9nUpf2Jmq6n8/tu1UzOvmiHj8qTfXUYZZd/Kn/pDMuu5lORWa87GwsCqw6usI 81GocuLuW6wJVeU/Ijenbme1R9bVYlbHxH8IZPXw2YKHQDvJ4KCAfxtARXw6Ixyx pmMGapXvzXWZ8Gpq3Awe =fve2 -END PGP SIGNATURE-
Re: Proposal: Drop ttf-cjk-compact, get fonts-droid
On Tue, Aug 11, 2015 at 03:02:32AM +0200, Cyril Brulebois wrote: Hi! Kenshi Muto km...@debian.org (2015-07-22): This is a proposal to replace ttf-cjk-compact with fonts-droid for next (Stretch) debian-installer. As long as this is a change for debian-boot, and not for the installed Debian I have no problems with this. But if it's for Debian itself, well, people may just prefer one set of fonts over the other for aesthetic reasons, and both should remain available. -- hendrik -- 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/20150811010801.gb3...@topoi.pooq.com
Re: proofreading the installation-guide
On Tue, Jul 28, 2015 at 09:06:03PM +0100, Justin B Rye wrote: Holger Wansing wrote: Justin B Rye justin.byam@gmail.com wrote: An interesting idea, but one that seems unlikely to work, especially given the way it's used in the text. For instance, there's a page welcome/what-is-debian-linux.xml, which is full of sentences like debian; was the first Linux distribution to include a package management system. It was mostly me changing Debian into debian; that days in 2010. If I remember correctly, it was initiated by a post of Frans Pop, who proposed that change. And the rationale was in fact, to get a manual, that can easily be turned from a Debian installer manual into a Ubuntu installer manual, for example. Whoever it is that's reworking the manual for the derivative is still going to need to go through the whole text changing the content. The debian; entity seems liable to cost us more effort than it saves them (a single extra search-and-replace operation). If that was the case, it would be a single search-and-replace operation for you, too. Just catch the ones you see while proofreading, leave the rest. The Debian derivative's people will catch the ones you miss, and you can someday, *when there's time to do it*, diff your source with theirs to find the rest. Of course, this is only for derivatives that use the same installer. And I can't see any particular pattern in when it's Debian installer, when it's debian; installer, and when it's d-i;. With the above been said, it should be as follows: In sentences which apply to Debian and also to its derivates, it should use debian; , while in sentences which only apply to Debian and not to the derivates, it should be Debian. It was also my intention to make it that way indeed, but: 1. I found out that the job was bigger than I first thought when taking it over, leading to mistakes. 2. due to the lack of manpower in the d-i team, especially the loss of Frans, the d-i manual guru (amongst other roles), there was probably not enough reviewing of that changes, and things may got overlooked. Oh, well, for now I'll plan on trying to get debian; into shape as part of my proofreading sweep - it would be easy enough to switch back from sometimes saying debian; to always saying Debian if we decide to give up on it. The debian-gnu; entity is effectively just shorthand for Debian GNU/arch-kernel; - confusing but handy. Wait, does it expand to Debian or debian;? The architecture;, arch-title; and arch-kernel; entities are slightly oddly named Since I keep losing track and having to check again, I'll leave a note for myself here: architecture; = 32-bit PC, 32-bit soft-float ARM, etc. arch-title; = i386, armel, etc. arch-kernel; = Linux, KFreeBSD, etc. but make sense as parametrisations, as do release; and releasename; as long as they're used for things that stay true for every release. (Oh, and I've just noticed there's a releasename-cap;, used instead of plain releasename; for no obvious reason in hardware/supported/arm.xml and nowhere else.) But there are also special entities for enterkey;, escapekey;, tabkey;, f10key;, and even ekey;! Most of these are only used once each - the rest of the time (and always for keys like F2 or space) it just uses keycap.../keycap. That entities like releasename-cap; enterkey; escapekey; tabkey; were created, to give translators a chance to follow the rules for their language there (for example, in German we write Jessie, Stretch or Unstable uppercase, while in English that's mostly lowercase: jessie, stretch, unstable) or to have tab key translated into Tabulator-Taste for German, for example. Sorry, I don't follow. Surely German needs *all* instances of releasename; to be capitalised? How does it help to have some of them replaced in the text with releasename-cap;? And why is it any easier to provide translations for tabkey; than for keycodeTab/keycode? Why would you need ones for f10key; and ekey;, but not keycodeF2/keycode or keycodeSpace/keycode? Hmm, I can imagine cases where the *English* version might benefit from having an entity indefinitearticle; that automatically selects either a or an depending on whether the following substituted-in word starts with a vowel sound! But let's not. Globally said, there may be several occurrences of above things not being perfectly consistent, because there are many editors for the manual these days, but there is no Frans Pop anymore, watching the changings and correcting things where needed. [PS included for convenience:] So I suppose it would be reasonable to put a comment in the document source explaining this, perhaps where these macros are defined, and making further changes as we discover the need and have time, possibly prompted by bug reports from Debian derivatives or forks, or
Re: proofreading the installation-guide
On Tue, Jul 28, 2015 at 07:00:27PM +0200, Holger Wansing wrote: Hi, Justin B Rye justin.byam@gmail.com wrote: Hendrik Boom wrote: Justin B Rye wrote: * entity questions - when am I meant to say Debian and when is it debian;? This like many of these entities seems to have no obvious function other than to make the source harder to interpret... * The d-i; entity expands to debian-installer in bold verbatim lowercase. If that is in effect the brandname of the software project then presumably we shouldn't be talking about the d-i; - that ought to be the Debian installer. Presumably both of these parametrisations are for the convenience of Debian derivatives and forks. By making these macros, it's easier for the, and it'll be easier for us to merge downstream patches. An interesting idea, but one that seems unlikely to work, especially given the way it's used in the text. For instance, there's a page welcome/what-is-debian-linux.xml, which is full of sentences like debian; was the first Linux distribution to include a package management system. It was mostly me changing Debian into debian; that days in 2010. If I remember correctly, it was initiated by a post of Frans Pop, who proposed that change. And the rationale was in fact, to get a manual, that can easily be turned from a Debian installer manual into a Ubuntu installer manual, for example. And I can't see any particular pattern in when it's Debian installer, when it's debian; installer, and when it's d-i;. With the above been said, it should be as follows: In sentences which apply to Debian and also to its derivates, it should use debian; , while in sentences which only apply to Debian and not to the derivates, it should be Debian. It was also my intention to make it that way indeed, but: 1. I found out that the job was bigger than I first thought when taking it over, leading to mistakes. 2. due to the lack of manpower in the d-i team, especially the loss of Frans, the d-i manual guru (amongst other roles), there was probably not enough reviewing of that changes, and things may got overlooked. The debian-gnu; entity is effectively just shorthand for Debian GNU/arch-kernel; - confusing but handy. The architecture;, arch-title; and arch-kernel; entities are slightly oddly named but make sense as parametrisations, as do release; and releasename; as long as they're used for things that stay true for every release. (Oh, and I've just noticed there's a releasename-cap;, used instead of plain releasename; for no obvious reason in hardware/supported/arm.xml and nowhere else.) But there are also special entities for enterkey;, escapekey;, tabkey;, f10key;, and even ekey;! Most of these are only used once each - the rest of the time (and always for keys like F2 or space) it just uses keycap.../keycap. That entities like releasename-cap; enterkey; escapekey; tabkey; were created, to give translators a chance to follow the rules for their language there (for example, in German we write Jessie, Stretch or Unstable uppercase, while in English that's mostly lowercase: jessie, stretch, unstable) or to have tab key translated into Tabulator-Taste for German, for example. Globally said, there may be several occurrences of above things not being perfectly consistent, because there are many editors for the manual these days, but there is no Frans Pop anymore, watching the changings and correcting things where needed. So I suppose it would be reasonable to put a comment in the document source explaining this, perhaps where these macros are defined, and making further changes as we discover the need and have time, possibly prompted by bug reports from Debian derivatives or forks, or even just doing a diff between our d-i manual and some of the derivatives' -- hendrik -- 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/20150728192418.gb4...@topoi.pooq.com
Re: Proposal: Drop ttf-cjk-compact, get fonts-droid
On Wed, Jul 22, 2015 at 12:26:02PM +0900, Kenshi Muto wrote: ... Cons: - increases +2MB for each graphical initrd. jessie-amd64/cdrom/gtk/initrd.gz: 25557641 - 281535694 Presumably there's a typo here -- this is a tenfold increase! hd-media/gtk/initrd.gz: 27747025 - 30340894 netboot/gtk/initrd.gz: 34425758 - 37539446 netboot/gtk/mini.iso: 49283072 - 52428800 - Some Japanese characters look bit funny. (I believe it is negligible for installer.) -- 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/20150726120736.ga10...@topoi.pooq.com
Re: proofreading the installation-guide
On Sun, Jul 26, 2015 at 01:15:18PM +0100, Justin B Rye wrote: * entity questions - when am I meant to say Debian and when is it debian;? This like many of these entities seems to have no obvious function other than to make the source harder to interpret... * The d-i; entity expands to debian-installer in bold verbatim lowercase. If that is in effect the brandname of the software project then presumably we shouldn't be talking about the d-i; - that ought to be the Debian installer. Presumably both of these parametrisations are for the convenience of Debian derivatives and forks. By making these macros, it's easier for the, and it'll be easier for us to merge downstream patches. -- hendrik -- 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/20150726122637.gb10...@topoi.pooq.com
Re: proofreading the installation-guide
On Sun, Jul 26, 2015 at 02:37:45PM +0100, Justin B Rye wrote: Hendrik Boom wrote: Justin B Rye wrote: * entity questions - when am I meant to say Debian and when is it debian;? This like many of these entities seems to have no obvious function other than to make the source harder to interpret... * The d-i; entity expands to debian-installer in bold verbatim lowercase. If that is in effect the brandname of the software project then presumably we shouldn't be talking about the d-i; - that ought to be the Debian installer. Presumably both of these parametrisations are for the convenience of Debian derivatives and forks. By making these macros, it's easier for the, and it'll be easier for us to merge downstream patches. An interesting idea, but one that seems unlikely to work, especially given the way it's used in the text. For instance, there's a page welcome/what-is-debian-linux.xml, which is full of sentences like debian; was the first Linux distribution to include a package management system. It makes me wonder whether this was originally the intention, but has become lost as generations of editors failed to follow up on it. -- hendrik -- 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/20150726153548.ga12...@topoi.pooq.com
Bug#791794: RAID device not active during boot
On Sat, Jul 11, 2015 at 10:16:15AM +0200, Nagel, Peter (IFP) wrote: The problem might be related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789152. However, in my case everything seems to be fine as long as all harddisks (within the RAID) are working. The Problem appears only if during boot one (or more) disk(s) out of the RAID device have a problem. The problem might be related to the fact that jessie comes with a new init system which has a stricter handling of failing auto mounts during boot. If it fails to mount an auto mount, systemd will drop to an emergency shell rather than continuing the boot - see release-notes (section 5.6.1): https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system Would a temporary work-around be to use another init system? For example: If you have installed your system to a RAID1 device and the system is faced with a power failure which (might at the same time) causes a damage to one of your harddisks (out of this RAID1 device) your system will (during boot) drop to an emergency shell rather than boot from the remaining harddisk(s). I found that during boot (for some reason) the RAID device is not active anymore and therefore not available within /dev/disk/by-uuid (what causes the drop to the emergency shell). A quickfix (to boot the system) would be, to re-activate the RAID device (e.g. /dev/md0) from the emergency shell ... mdadm --stop /dev/md0 mdadm --assemble /dev/md0 ... and to exit the shell. Nevertheless, it would be nice if the system would boot automatically (as it is known to happend under wheezy) in order to be able to use e.g. a spare disk for data synchronization. After all, isn't it the whole point of a RAID1 that it can keep going when one of its hard drives fails? I currently have this situation on a wheezy system, and it will continue until I have the replacement physical drive prepared for installation. The RAID1 is running fine with just one physical drive. It would be seriously inconvenient to be unable to boot in a straightforward manner. It's not as if it's being quiet about the matter -- I keep getting emails elling me that one of the drives is missing. -- hendrik -- 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/20150711161247.ga5...@topoi.pooq.com
Re: [preseed] multiple disks, rules to select the smallest one
On Wed, May 27, 2015 at 12:11:26PM -0400, Sandro Tosi wrote: ... In order to avoid writing a custom preseed file all the times, we're wondering if there is already a policy that would instruct d-i to use the smallest physical drive on the system as the one to partition and use for installation or alternatively how we should write our preseed.cfg to obtain that (eventually with some early_command?). the smallest drive? Like, for example, the floopy disk? -- hendrik -- 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/20150527164717.gd18...@topoi.pooq.com
Re: Bug#783358: installation-reports: Debian 8 CD - Graphical install is not the default (installation guide says it should be)
On Mon, May 04, 2015 at 11:31:20PM +0200, Cyril Brulebois wrote: (Not sure why To/Cc were changed this way, but replying there anyway…) Hendrik Boom hend...@topoi.pooq.com (2015-05-04): On Sun, May 03, 2015 at 10:22:17PM +0200, Cyril Brulebois wrote: Hello, Holger Wansing li...@wansing-online.de (2015-05-03): So, shall I revert the manual back to text install is default? Yes please. I asked Didier to keep an eye on it but he pretended being busy with other topics. ;) On the off-chance that this is a francism in English, and someone might be offended, 'pretended' in English means 'acted as if', whereas 'pretendre' in French means 'to claim', or to 'assert'. I presume that Didier was really busy with other topics, rather than acting as if he was busy. Without claiming to master all aspects of the English language, I think I meant what I wrote. Pretty sure Didier can react on his own if he feels offended by casual teasing followed by a smiley (and preceded by the same kind of remark in an earlier IRC conversation)… KiBi. That's fine, then. When I first moved to Quebec and started reading stuff and listening to the radio in both languages I found myself pretty confused the news I was reading because of the persistent use of 'pretend' and 'pretendre' as translaatis for each other. It took a while before I figured out what was happening. It's pretty common here, but not elsewhere, to hear 'pretend' used in English with the wrong meaning. In fact the 'claim' meaning has survived in orthodox English in the archaic phrase 'pretender to the throne'. My grade school English teacher was puzzled why anyone would be upset about someone merely pretending to be king. It wasn't until decades later that I figured out what was going on with the word. -- hendrik -- 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/20150504214213.gb...@topoi.pooq.com
Re: Bug#783358: installation-reports: Debian 8 CD - Graphical install is not the default (installation guide says it should be)
On Sun, May 03, 2015 at 10:22:17PM +0200, Cyril Brulebois wrote: Hello, Holger Wansing li...@wansing-online.de (2015-05-03): So, shall I revert the manual back to text install is default? Yes please. I asked Didier to keep an eye on it but he pretended being busy with other topics. ;) On the off-chance that this is a francism in English, and someone might be offended, 'pretended' in English means 'acted as if', whereas 'pretendre' in French means 'to claim', or to 'assert'. I presume that Didier was really busy with other topics, rather than acting as if he was busy. (Or will the default be changed with a point release of Jessie, or something like that? In that case it's probably not worse to change the manual.) Such a change in jessie wouldn't seem reasonable to me. Mraw, KiBi. -- 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/20150504210809.ga...@topoi.pooq.com
Re: Bug#764982: Backports, where is the danger (why the FUD)
On Mon, Apr 20, 2015 at 08:26:10AM +0100, Philip Hands wrote: While we're at it, it would be nice to have the same Only if I explicitly ask for it feature for non-free (and probably contrib). I may be willing to compromise my freedom in order to get my laptop wifi working, on the basis that I could always buy a better wifi card, but that does not mean I want anything else out of non-free. There is a case to me made that the documentation in non-free, especially that released uneder the GNU Free Documentation Licence with invariant parts, might be a special case here. -- hendrik -- 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/20150420153741.ga3...@topoi.pooq.com
Re: Package versioning and upgrades
On Mon, Mar 30, 2015 at 06:50:22AM +0200, Cyril Brulebois wrote: Wouter Verhelst wou...@debian.org (2015-03-28): Alternatively, you could use release version numbers rather than code names: 0.6.3-1.3-1~Debian7 (rather than wheezy), and 0.6.3-1.3-1~Debian8 (rather than jessie) Using the same scheme as stable security updates might be a good idea instead of inventing another versioning scheme? Meaning ~deb7u1 or +deb7u1 for the first upload to wheezy, ~deb7u2 or +deb7u2 for the next one; as for jessie, use ~deb8u1 or +deb8u1 for the first upload, etc. And people better not rely on these being in alphabetical order, they'll run into trouble transitioning 9 and 10. The advantage of code names is that no one would assume jessie is later in alphabetical order than wheezy. Protection for idiots. -- hendrik -- 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/20150330132735.gb9...@topoi.pooq.com
Re: [d-i manual] copyright declaration
On Sun, Mar 22, 2015 at 04:51:11PM +, peter green wrote: On 22/03/15 13:36, Holger Wansing wrote: Hi, is there a reason why the year for copyright declaration should not be converted into an entity? Would ease the repeating changing. Patch attached, works for both xml and po based translations. Correct me if I'm wrong here but shouldn't the copyright year only be updated when there is an actual change? Yes. I believe the copyright year is supposed to be the year of first publication. Which is why books updated frequently usually have multiple copyright years, one for each year new stuff got added. You get a notice like copyright 1968, 1979, 1997, 2014. -- hendrik -- 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/20150323144349.ga22...@topoi.pooq.com
Re: [d-i manual] copyright declaration
On Mon, Mar 23, 2015 at 10:43:49AM -0400, Hendrik Boom wrote: On Sun, Mar 22, 2015 at 04:51:11PM +, peter green wrote: On 22/03/15 13:36, Holger Wansing wrote: Hi, is there a reason why the year for copyright declaration should not be converted into an entity? Would ease the repeating changing. Patch attached, works for both xml and po based translations. Correct me if I'm wrong here but shouldn't the copyright year only be updated when there is an actual change? Yes. I believe the copyright year is supposed to be the year of first publication. Which is why books updated frequently usually have multiple copyright years, one for each year new stuff got added. You get a notice like copyright 1968, 1979, 1997, 2014. It might be possible to automate getting some of this information from revision control. -- hendrik -- 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/20150323144532.gb22...@topoi.pooq.com
Re: translations for d-i manual [ Was: Re: Status of D-I translations... ]
On Thu, Mar 12, 2015 at 08:48:47PM +0100, Holger Wansing wrote: Hi, Christian PERRIER bubu...@debian.org wrote: It means that we're indeed left with about only 10 languages that happen to be complete - those where translators act on their own and know what to do to get a fully translated D-I. For others, most of the time, the registered person with commit access either vanished or doesn't care anymore for D-I to be fully translated. The situation for the d-i manual is similar: we have some languages, that did not receive no or nearly no translation updates since the release of Wheezy. Should those languages be deactivated? These are:japanese (no update since 17 months) russian (no update since 24 months) swedish (no update since 2 years 7 months) vietnamese (no update since 2 years 7 months) chinese zh_CN (no update since 2 years 3 months) All of them are po-based translations, so the manuals are strictly spoken not outdated (changed paragraphs fall-back to english), but it of no good use for users probably? Well, if I had a choice between a manual thta was all in a foreign language and one that was half in a foreign language and half in mine, I'd prefer the one that was half in mine. -- hendrik k -- 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/20150312210105.gb25...@topoi.pooq.com
Re: Bug#768657: [Pkg-sysvinit-devel] Bug#768657: sysvinit: Please provide xen virtual console in inittab
On Mon, Nov 10, 2014 at 02:41:27PM -0500, Gedalya wrote: On 11/10/2014 01:43 PM, Steve Langasek wrote: On Mon, Nov 10, 2014 at 02:39:28AM -0500, Gedalya wrote: On 11/10/2014 02:19 AM, Steve Langasek wrote: It's not for the sysvinit-core package to fix up the installer's handling of consoles, when sysvinit-core is not installed. Reassigning this to the debian-installer package. And how could it possibly be debian-installer's job to modify a file that is part of your package, when the package is not installed? I find your response incomprehensible. This bug is about making sure inittab, part of sysvinit-core, supports the console on the platform is is running on. Currently sysvinit-core is defective in not doing so. My comment about debian-installer was just so that you could see an example for code that handles this, and it explains why the maintainers of this package coincidentally haven't had to worry about this problem thus far. One way or another, to reproduce this problem all one needs to do is to install sysvinit-core on a xen VM, with debian-installer nowhere in sight. I also don't understand why #745260 was fixed (exactly the same problem) and this one somehow not. Ok, I misunderstood what the bug was that you were reporting. I thought you were saying that the installer sets up /etc/inittab, but that this doesn't cause the console to work on systems where sysvinit-core is not being installed. I think fixing bug #745260 in sysvinit-core is dubious; I really think that the console setup should be done as part of the installer, not as part of init's maintainer scripts. However, since we are no longer installing sysvinit-core, it's a legitimate question whether the installer should be changed to create /etc/inittab on its own if it doesn't already exist, or if the installer should entirely hand over control of this file to the sysvinit package. I think we should get input from the installer team on this. I don't really see how it makes sense to create an /etc/inittab when we're installing systemd (silently and without asking). Without sysvinit, inittab doesn't belong there and doesn't make sense. The way I see it, the only way the installer can be of help here is if it is changed to prompt the user for his init system choice, which AFAIK wasn't the decision so far.. though it would please me very much! Otherwise we're sort of pre-creating a file for a hypothetical purpose.. Are there any other inits that use /etc/inittab? With the plethoors of inits that have showed up over the past decades, it wouldn't surprise me at all if some of them were compatible in this respect. Would it make sense to put /etc/inittab into annother package that sysvinit-core depends on? The way things look right now, with systemd being installed against their wishes, sysvinit users are being told to install sysvinit-core after installation, when they have finally booted the target system. This way, /etc/inittab would be installed for them at the same time. Any other inits could have the same dependency, as apropriate. -- hendrik -- 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/20141110204757.ga19...@topoi.pooq.com
Re: Bug#762614: stop preseeding desktop
On Tue, Sep 23, 2014 at 08:26:32PM +0100, Steven Chamberlain wrote: Hi, On 14:59, Joey Hess wrote: Once tasksel 3.27 is in testing, but not before, d-i should stop preseeding desktop=xfce for kfreebsd and hurd. This version of tasksel defaults to xfce for those architectures and will handle any other architecture variations in a single place. Agreed, although we should try evaluate if XFCE is still the best default for these (and perhaps find something that caters to other situations where GNOME isn't viable) After all this time (what is it? over a year now?) I thought the new Gnome might have improved and become viable. I tried it last weekend. It still isn't viable. I can't even figure out how to log out. Not what I want a beginner confronted with. -- hendrik I've created a spin-off page to discuss alternatives: https://wiki.debian.org/DebianDesktop/Alternative/Jessie Regards, -- Steven Chamberlain ste...@pyro.eu.org -- 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/20140923192632.gb6...@squeeze.pyro.eu.org -- 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/20140923193129.ga11...@topoi.pooq.com
Re: Bug#712907: grub-installer: No longer installs automatically on a normal machine with one hard drive
On Wed, Sep 10, 2014 at 09:39:24PM +0200, Cyril Brulebois wrote: Steven Chamberlain ste...@pyro.eu.org (2014-09-10): 3. for a user who blindly hits enter, they get our best guess to the correct device (instead of a bare now enter a device path prompt) Please stop pretending it's a best guess. IT'S NOT GOOD ENOUGH, and it has been known for *years*. But I haven't actually tested it yet :) Many users already have… and wedged their installation images. Slightly tired of repeating myself. KiBi. Does the installer no longer know to what device it installed the Debian system? Perhaps where it put /boot? Might *that* be a good place to put the bootloader? -- hendrik -- 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/20140911172303.ga12...@topoi.pooq.com
Re: Use dedicated partition for /boot/grub instead of /boot
On Tue, Aug 19, 2014 at 09:45:03PM +0900, Joel Rees wrote: 2014/08/18 14:57 Christopher Chavez 2000...@gmail.com: Questions: 1. Is it the case that the only reason for having a separate /boot was to provide easy access /boot/grub? I.e., was it intentional to provide easy access to kernels as well? I guess it depends on what you mean by easy access. If you mean, to keep the kernel where it can be easily found by the boot manager, yeah, that's one of the big reasons. Old systems used to have a strong restriction on which part of the hard drive could be read by the initial firmware bootloader. The exact boundary changed from time to time, as the dcades wore on, but there was such a restriction often enough that some measure wsas needed so that the initial boot would sastisfy this restriction. The easy way to manage this was to have a separte partition for the these files, and place it near the start of the hard drive. Hence /boot was born. It's probably wise to keep /boot for this purpose, since one of these years we're going to hit the next order-of-magitude restriction. But just what files are subject to such a restriction, and what the file format of that partition should be probably depende on the firmware-level bootloader. At the moment, /boot and the EFI partition seem to have boot-time restrictions, either because of firmware or bootloader restrictions. -- hendrik That information used to be a lot more available, until some IPidiots started trying to claim rights to it. IPidiots? Can I have more details or a reference on these IPidiots? -- hendrik -- 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/20140819172902.ga29...@topoi.pooq.com
Re: Re: the audio group
On Mon, Aug 18, 2014 at 05:20:19PM +0200, Floris wrote: how about users who will login remotely? They also have full access to all the audio devices, even when they don't able to hear the music, because the speaker is on the other side of the world. Remote login might be from a computer that's just on the other side of the room. -- hendrik -- 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/20140818162955.ga32...@topoi.pooq.com
Re: Use dedicated partition for /boot/grub instead of /boot
On Mon, Aug 18, 2014 at 12:40:13AM -0500, Christopher Chavez wrote: 2. Would it be a better idea to only have /boot/grub, instead of /boot, on a separate partition? (I can confirm that it works both when installing and in existing setups, i.e. grub-install and update-grub both work as expected.) If it's separate partition, it could be shared between several different bootable Linux systems. Might this actually work, given that files in .boot/grub might end up being updated by any of them? Which might actually be what we want? -- hendrik -- 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/20140818163350.gb32...@topoi.pooq.com
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
On Tue, Aug 12, 2014 at 12:22:01PM +0200, Josselin Mouette wrote: I just had a look at an online hardware store. Out of their 682 laptops and 332 desktops: * 1 model has 1 GiB * 48 models have 2 GiB * 470 models have 4 GiB * 495 have 6 GiB or more Which means 0,1% of the machines you can buy are not able to run a web browser anyway, 5% are more than enough for a full-fledged GNOME+web browser, and all the rest are very comfortable with anything you can run under Linux. I must be in the 0.1% then. I have a 1GB machine. I have no trouble running Chrome or Chromium. Or even both of those at the same time. But then, I'm using XFCE instead of Gnome. -- hendrik -- 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/20140812133809.ga22...@topoi.pooq.com
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
On Mon, Aug 11, 2014 at 10:23:38AM +0001, Anthony F McInerney wrote: And if it's machines in the wild with CD drives still again, we have woody, squeeze and wheezy for them. Does woody still have security support? In not, there are many old machines for which it is no longer an alternative. Whatever the chosen DE is, though, the installer should cater to installation on machines with scare resources, and the ways to get it to do so should be evident to the user. -- hendrik -- 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/20140811170828.ga5...@topoi.pooq.com
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
On Mon, Aug 11, 2014 at 01:35:28PM -0400, Lennart Sorensen wrote: On Mon, Aug 11, 2014 at 05:34:04PM +0200, Matthias Urlichs wrote: Or even showing them at all (certainly last time I bothered to look at gnome 3 it seemed to think buttons on windows were mostly to be avoided). People who are so afraid of new stuff to learn that they won't even figure out how to close a window are not Gnome's (or XFCE's, for that matter) target audience. They may well not be Gnome's target audience. We should not inflict Gnome on them. If you want that, install KDE and tell it to use one of the let's-mimic-Windows/MacOS themes. xfce is perfectly useable to most people by default. All I personally expect from a window manager is: Be able to launch programs (ideally using alt+F2) Be able to resize the window using the edge of the window Have a maximize/restore button Have a minimize button Have a close button (These last 3 should also show up when I hit alt+space, because well I have used that keystroke on many systems for over 20 years to do that). That's it. I don't need any more than that. Gnome 3 failed that out of the box. It looks as if Lennart Sorensen is not in Gnome's target audience. But I'd say he is definitely in Debian's target audience. -- hendrik -- 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/20140811174220.gb5...@topoi.pooq.com
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
On Tue, Aug 12, 2014 at 02:03:39AM +0200, Kees de Jong wrote: Are we really comparing RAM here as if it were the 90's? How many people here use Android? Today it needs 512 MB to function properly. In two years that could be 1 or 2 GB and that's a mobile OS. How much RAM does your browser use? My Chrome/Firefox easily uses 1 GB. My GNOME 3.10 desktop (running Fedora now because I needed a modern GNOME version for Exchange support for work) is using about 800 MB to 1200 MB. Do I really care? No, because RAM is cheap and I have 8 GB. Do I need to buy more? No, because 8 GB is still more than enough. My everyday system has 1 GiB. Can't even put more than 2 on it if I were to try. I use XFCE. The question about the default isn't whether *my* system can run it. It's whether the novice will get an installed system he cannot use. At the very least the installer should tell him to select something small (and tell him what it is) on a small machine, instead of blindly installing Gnome. -- hendrik -- 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/20140812021205.gc12...@topoi.pooq.com
Re: Reverting to GNOME for jessie's default desktop
On Fri, Aug 08, 2014 at 12:47:14PM +0100, David Goodenough wrote: I would have thought it better to have a two level structure, where you are asked for instance if you want a database, and if you select it you are then asked which one (which can have a default for newbies). Similarly for desktop you would be asked XFCE/Gnome/KDE. You could even ask the user at install time whether he wants (a) a small, efficient, usable desktop that takes care of only the essentials, or (b) a large, full-featured, usable desktop that may take a lot of download time and disk space, or even (c) (not recommended unless you're a developer and know what this is) none of the above, just a bare CLI. Or at least provide this information in some obvious way so that the beginner has some idea what he may be getting into; he probably has no idea what the words xfce and gnome mean. -- hendrik -- 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/20140808170400.ga5...@topoi.pooq.com
Re: Captive laptop
On Fri, Feb 28, 2014 at 08:14:48AM -0800, Schlacta, Christ wrote: On Feb 28, 2014 7:59 AM, Lennart Sorensen lsore...@csclub.uwaterloo.ca wrote: On Fri, Feb 28, 2014 at 07:41:39AM -0700, R Edwards wrote: Hello, I have a persistent problem and I was hoping that the Debian install discs would solve it. I have a new laptop with Windows 8 on it (was purchased for the hardware) and Windows is holding it prisoner. I am unable to install any other Operating system on it whatsoever including Debian 7.4 that I downloaded from this site. It will not allow the 'test' with no files installed or the full installation. I am not exactly a computer newbie but have only 'new' level of linux background. I have tried six different OS packages from two or three different devices for installs and all have failed. Windows 8 will not let any install. Any chance you have an ISO that will produce a dvd disc that can be bootable from a bare harddrive. The 7.4 version I downloaded gets an 'invalid media' message and I have tried more than one copy/download/version with the same results. In the attempt to run from dvd without installing files, get a 'try compatibility settings' message that always fails. I am apparently not the only one with this problem. Please help. I NEED my computer without the Windows garbage taking control of it. I am even willing to pay for a 'guaranteed' installation disc but I try it before I pay as I feel Windows will defeat all comers at this point. Looking forward to being proved wrong! When I bought the laptop, I never dreamed that it would take months to attempt to get Windows off of it and still be failing. I feel like billing Microsoft for taking my laptop prisoner but that would get me as far as this installation is gettingnowhere. If you download the installer (say DVD-1 iso or netinstall iso) and then burn it as an image to the DVD: http://windows.microsoft.com/en-ca/windows7/burn-a-cd-or-dvd-from-an-iso-file So windows can do that apparently. It should then be bootable, but of course you have to tell the BIOS/EFI/whatever you have, to boot from the DVD drive. You may also have to disable secure boot. (1) Disabling secure boot is apparently something you can do from within Windows. (2) Does the laptop have and an intel processor? Or an ARM processor? If it's an ARM processor you'd have to use the appropriate ARM version of Linux. But you're probably still be out of luck -- some time ago Microsoft announced that Windows 8 on an ARM processor will be totally locked down. As far as I know that hasn't been cracked yet. -- hendrik -- 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/20140305164917.ga14...@topoi.pooq.com
Re: install/run problems with Debian 7.1.0
On Mon, Nov 25, 2013 at 10:34:08AM -0500, Lennart Sorensen wrote: On Sat, Nov 23, 2013 at 12:29:35PM -0800, John wrote: PROBLEM 2: Your hardware setup is generally very good, but recent changes in video detection and setup by Linux developers mess up in handling older video cards/chips and monitors. As a result, Debian 7.1.0 has a correct-resolution correct-refresh setup for my monitor for installation, but sets my video improperly for regular use. I think the video refresh is set too high. It produces some snow on my CRT monitor and just doesn't look right, and there doesn't seem to be any graphic tool in Gnome 3 to change these settings. Some code in the installation to let the user select the desired screen video settings would be nice. If that isn't available, upgrading to Debian 7 isn't such a good idea. You can do the right video settings---the installation display proves it. Just leave it as is if it's satisfactory. X setup is pretty much automatic these days and doesn't even need a config file anymore unless you want to override what X does automatically. Not an installer issue anyhow, since that is managed by X. Let me try to translate the complaint into your terminology. I think he's complaining that the installer gets X configuration right for its own use, but wrong for the installed system, where apparently X gets it wrong, There's some plausibility to the claim that the installed system *should* be able to get things as right as the installer. Maybe this isn't as much an installer problem than an installed systen problemm. Presumably whatever code the installer uses at install time should also be part of X, or whatever setup happens at boot time. It' a bit ironic that the complaint should be against the piece of code that actually does get it right, but I guess that's life. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131125223441.ga26...@topoi.pooq.com
Re: Bug#718855: [Pkg-xfce-devel] network-manager-gnome - full gnome recommends chain
On Wed, Oct 09, 2013 at 10:29:10AM +0200, Per Olofsson wrote: Hi, On Tue, Oct 08, 2013 at 23:54 +0200, Michael Biebl wrote: Both recommends are there for a reason. gnome-bluetooth relies heavily on gnome-control-center when you try to pair / manage devices and network-manager-applet relies on gnome-bluetooth for DUN and PAN connections. So no, I don't see those recommends go away. According to policy, The Recommends field should list packages that would be found together with this one in all but unusual installations. Is it really unusual to use Network Manager without bluetooth? Doesn't most people use Network Manager to connect to wifi and ethernet? I certainly use xfce and the network manager, and I've even shut bluetooth off in the BIOS. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131009151628.gb...@topoi.pooq.com
Re: your mail
On Wed, Aug 07, 2013 at 07:36:28PM -0700, Alan Hutchinson wrote: Hi there My name is Alan Hutchinson and I would like to install Debian on a raid 0 system that I have at home , on my home network that I created, I have bean reading up on some of the things that I will need to complete a successful install, for example the raid manager (MDADM) and you also mentioned DebianInstaller does not include a driver for my xyz network card, but I have (tarball) driver sources. What are the steps for building that driver? My home server has a RAID for most of its storage. It's a software RAID. WHen I bought the controller card for my machine (so I could get more SATA drives on it) it turned out to be a RAID controller. I completely ignored its RAID capabilities, opting to use Debian's excellent md support instead. I created large primary partitions on my IDE hard drives to contain one RAID, and large partitions on my 3-terabyte drives for the second RAID. Yes, that's right, two independent RAIDS -- the IDE drives for legacy stuff, the new 3T drives for newer (ald larger) stuff. My long-term plans are for the IDE drives to be replaced by still bigger drives in a year or two when they become necessary. And within those RAIDs I used LVM for flexibility in allocating partitions of flexible size. To make everything work smoothly, hpwever, it helped to (a) use gdisk instead of fdisk onthe new huge drives. fdisk doesn't work anh more in 3T drives -- they're too big. (b) make sure that there was a working boot partition outside of the RAID. Some bootloaders had problems with boot partitions on LVM on RAID. (c) made sure that the first physical partition on the drive contianing /boot starte *after* the first cylinder. Apparently LILO now needed more space than it used to, and it needs to invade the first cylinder. (d) I use the badblocks program to do a full-surface destructive read-write test of every disk drive I buy. Yes, it can take longer than a week, so I buy them one at a time, even if I plan to use them in pairs. But about 20% of them fail the test, and are immediately exchanged. I no longer worry that I'm being excessively paranoid. I'm now testing my second USB backup drive. My plan it to keep at least one backup drive off-site at all times. I use rdiff-backup; it keeps history. Also, I made sure I could boot from either grub2 in the usual manner, or from LILO on a floppy. I test them regularly to make sure they both work. If either ever fails during an upgrade, I still have the other. Finally, I'm doing the whole thing using wheezy. It seems to be the first Debian release that fully supports disk hardware write blocks -- even through LVM -- so that file systems like ext3 and ext4 have a reasonable chance of processing their journals properly even in the presence of unexpected power failures. -- hendrik A: It's possible to do this, but we do not yet have good end-user docs explaining how to do so. We're waiting for an end user to accomplish it and write them from experience. We're glad to help you through the process, I have a brand new D-LINK 2320 that I would like to install with Debian installation, I have not tried to do an LSPCI-V on the raid hardware as yet, I can do that with PUREDYNE, and send you the data , B.F.N Alan Hutchinson . -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130808172627.ga24...@topoi.pooq.com
Re: Bug#718698: [os-prober] ReiserFS support
On Mon, Aug 05, 2013 at 03:32:23PM +0200, Francesco Muzio wrote: if the Debian installer doesn't allow the use of reiserFS this mean that there will be no new users with this filesystem. But old users (like me) could survive (silently) again for few years. Shouldn't os-prober at least be able to recognise OS's that use reiser as other OS's? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130805172654.ga18...@topoi.pooq.com
Re: task-desktop: default desktop environment for Jessie
On Sun, Jun 02, 2013 at 08:42:00PM +0100, Steven Chamberlain wrote: On 02/06/13 20:27, Hendrik Boom wrote: If someone wants to have gnome or KDE anyway, he's can acquire a second CD, or access the net after installing packages from the first CD, or use a DVD or USB key or something bigger. That's an interesting idea... if CD-1 was XFCE, would it contain enough of the common/base packages that only one additional CD is needed to complete either a GNOME or a KDE desktop? Which additional CD you would need anyway for GNME and KDE. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130603134859.ga24...@topoi.pooq.com
Re: task-desktop: default desktop environment for Jessie
On Sun, Jun 02, 2013 at 07:36:35PM +0100, Brian Potkin wrote: On Fri 31 May 2013 at 15:11:50 -0400, Michael Gilbert wrote: On Fri, May 31, 2013 at 3:06 PM, Cyril Brulebois wrote: Michael Gilbert mgilb...@debian.org (31/05/2013): It would probably be good to get that discussion started early during this cycle to reduce the surprise factor. Since it was rather difficult to fit gnome onto 1 cd in wheezy (and I think some pieces were left off anyway), I think it makes sense now to start moving toward something like xfce as the default that's small, and mostly capable, and 4.10 (now making its way into unstable) brings much needed accessibility features. A somewhat related question is whether we're going to keep trying to fit stuff onto CD#1, as opposed to moving to supporting various “USB key sizes”. If I'm not mistaken, Steve has expressed such a wish (or intent) during the last wheezy preparation steps. As a point of reference, I still have (and use every now and then) an old laptop that has a cd-rom but no dvd-rom, and its bios does not support usb booting. I have two desktops and a laptop (not all that old, five years) which do not entertain booting from USB. So you learn to be resourceful. For Debian we have the hd-media kernel and initrd. grub-mkrescue will make an iso with them and include a grub.cfg. iso-scan will find whatever ISO you choose to put on another USB stick. I hope Debian will continue to support those of us have such 'ancient' machines. Eventually, we are going to run out of ideas or patience with fitting a useful GNOME, KDE etc on CD#1. Its a lost battle. This is the time for innovation. Get it discussed and decided now and not two or three months before the next release. If gnome or KDE doesn't fit on the first CD, it makes no sense to pretend it does. Put something that *does* fit on the first CD. It's perfectly possible to put the packages for a viable Linux system on a single CD, but you'd need a desktop that takes less CD space. If someone wants to have gnome or KDE anyway, he's can acquire a second CD, or access the net after installing packages from the first CD, or use a DVD or USB key or something bigger. I'm not in favour of software bloat. Let those who are use the second CD or another installation medium. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130602192745.ga20...@topoi.pooq.com
wheezy installation and upgrades?
Now that we have the first release candidate for the wheezy installer, is it also the time to make another serious try at upgrading squuze to wheezy? Is the infrastructure ready for this? I've tried the upgrade before last year, with diappointing results, each time reverting to squeeze in order to have a working system. Still, my long-term testing=wheezy systems, updated continually since squeeze went stable, hae always run just fine. The big leap seems to be trouble. -- hendrik -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130219201911.gc19...@topoi.pooq.com
Bug#262070: failed installation report
Package: installation-reports Debian-installer-version: http://cdimage.debian.org/pub/cdimage-testing/daily/i386/20040727/sarge-i386-netinst.iso uname -a: Linux lovesong 2.4.26-1-386 #2 Sat May 1 16:31:24 EST 2004 i686 GNU/Linux Date: 2004 07 28 at about 3P.M. EDT Method: Used SBM to boot from the CD I burned from the above-mentioned .iso image. Never got as far as reaching the network. Machine: ASUS motherboard Processor:, Athlon processor, 1600 MHz. Memory: 1 gigabyte Root Device: an IDE DVD drive, reading from a CD-ROM. Root Size/partition table: Root partition is /dev/hda3, 8.5 Gigabytes. The entire sarge system is being installed within this partition, including /home, /boot, and everything. It is formatted during installation with the reiser file system. /dev/hda4 contains a working woody system. It works perfectly before and after the sarge installation. /dev/hda1 contains a working Windows ME system. It works just as badly before and after installation., Output of lspci: :00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] :00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] :00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) :00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) :00:0f.0 RAID bus controller: Promise Technology, Inc. PDC20265 (FastTrak100 Lite/Ultra100) (rev 02) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 80) :00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge :00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) :01:00.0 VGA compatible controller: ATI Technologies Inc R200 BB [Radeon All in Wonder 8500DV] Base System Installation Checklist: Initial boot worked:[O] Configure network HW: [E] Config network: [E] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. My experiences are quite similar to those I had with the Beta-4 installer I tried yesterday and reported on in bug#261745. Everything went smoothly, except: After the reboot I about 16 complaints of the form: NETDEV WATCHDOG: eth0: transmit timed out eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 When I specified the Debian mirror I wanted to use, and it tried to reach the site, I again got these messages, after which it informed me that the mirror was unreachable. Methinks it is /dev/eth0 that is unreachable. The messages continued sporadically until I rebooted out of the installation. Please let me know what additional actins you would like me to take to diagnose this problem. I suspect it may not be a problem with the installer per se, but perhaps with some of the software being installed. My woody system, on the same machine in partition /dev/hda4, works perfectly. For completeness, here is the routing table (obtained by route -n): Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 172.25.1.0 0.0.0.0 255.255.255.0 U 0 00 eth0 0.0.0.0 172.25.1.1 0.0.0.0 UG0 00 eth0 and here's the output from ifconfig: eth0 Link encap:Ethernet HWaddr 00:0A:E6:55:93:CD inet addr:172.25.1.4 Bcast:172.25.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:18 Base address:0xb400 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:96 errors:0 dropped:0 overruns:0 frame:0 TX packets:96 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:8688 (8.4 KiB) TX bytes:8688 (8.4 KiB) I have a woody system on partition /dev/hda4, and it gives me the same
Bug#261745: bug#262070
I repeated the installation with a recent daily build, it failed in the same way, so the bug is not just an obsolete beta-4 bug. See bug#262070 for a more recent installation report. -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#261745: [hendrik@pooq.com: Re: Did that. Now no net.]
Package: installation-reports Debian-installer-version: Fill in date and from where you got the image uname -a: The result of running uname -a on a shell prompt Date: Date and time of the install Method: How did you install? What did you boot off? If network install, from where? Proxied? Machine: Description of machine (eg, IBM Thinkpad R32) Processor: Athlon maybe 1600? Memory: 1 Gigabyte Root Device: IDE? SCSI? Name of device? /dev/hda2, 8.5Gig Root Size/partition table: Feel free to paste the full partition table, with notes on which partitions are mounted where. Output of lspci: pcilib: Cannot open /sys/bus/pci/devices :00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] :00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] :00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) :00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) :00:0f.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02) :00:10.0 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 80) :00:10.1 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 80) :00:10.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 80) :00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge :00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 06) :00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) :01:00.0 VGA compatible controller: ATI Technologies Inc R200 BB [Radeon All in Wonder 8500DV] Base System Installation Checklist: Initial boot worked:[O] Configure network HW: [E] Config network: [E] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Comments/Problems: Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. I tried to install sarge on /dev/hda3, shile preserving an existing woody on /dev/hda4, just in case... /dev/hda1 is a Windows ME system, ans /dev/hda2 is an extended partition with lots of secondary partitions, mostly for Windows, but one swap partition. I downloaded the beta-4 iso and burned a CD from it. I booted that CD using the SBM disk that I think I once got from www.bootdisk.com. This got me into the debian net-installer, and installed onto /dev/hda3. /dev/hda4 still contains my woody system, which still works perfectly. My Windows ME partition still works as imperfectly as ever. But the new and very minimal sarge can't access the net. Pings don't seem to get as far as the ethernet card. Here's the routing table: Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 172.25.1.0 0.0.0.0 255.255.255.0 U 0 00 eth0 0.0.0.0 172.25.1.1 0.0.0.0 UG0 00 eth0 It's identical to the routing table on the woody system. Here's the output from ifconfig: eth0 Link encap:Ethernet HWaddr 00:0A:E6:55:93:CD inet addr:172.25.1.4 Bcast:172.25.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:18 Base address:0xb400 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:657 (657.0 b) TX bytes:657 (657.0 b) It's the same as the one from woody, except that woody gives me nonzero packet counts. etho has interrupt: 18 instead of interrupt:5 Aren't these dynamically assigned during boot, though? Pinging to 172.25.1.4 and 127.0.0.1 work fine. Both of them are, of course, IP numbers for the machine doing the pinging, so it doesn't need to get to the ethernet card. What should I do to diagnose the problem. Did the installer, which seemed pretty straightforward, miss some essential component? I did the default (I presume nonexpert 2.4 kernel) installation. Did I do something unobviously wrong? Needless to say, I can't access any of the Debian archives to get any further. I might add that my
Bug#261745: further info about bug 261745
I just realized I left out some of the fields in the installation report template for bug#261745 Debian-installer-version: Beta 4, downloaded from http://cdimage.debian.org/pub/cd-image-testing/sarge_d-i/i386/beta4/sarge-i386-netinst.iso uname -a: Linux lovesong 2.4.25-1-386 #2 Wed Apr 14 19:38:08 EST 2004 i686 GNU/Linux Date: July 26 and 27, 2004. Method: Booted from the Beta-4 net-install CD using a Smart Boot Manager floppy. Never got around to the network part of the install; that's the problem. Not proxied, but if it had worked, it would have been through an IP-masquerading woody installation running on a 100 MHz Pentium. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]