Re: btrfs subvolume naming scheme
On Sat, Apr 23, 2016 at 05:51:25PM -0400, Nicholas D Steeves wrote: > On 23 April 2016 at 07:38, New Thread old subject joining team > wrote: > > On Sat, Apr 23, 2016 at 01:28:43PM +0200, Philipp Kern wrote: > >> On Fri, Apr 22, 2016 at 08:30:35PM -0400, Nicholas D Steeves wrote: > >> > >> > I'd also like to discuss whether the default subvolume naming scheme > >> > should follow Ubuntu, Fedora, OpenSUSE, or something else. > >> > >> What scheme are they using? > > > > Or a proposal for default subvolume naming scheme? > > > > Ubuntu avoids using the default subvolume (subvol ID 5). For the > rootfs their installer creates a subvol called @, for /home it creates > @home, etc. In fstab the device is specified and subvol=@ is added to > the mount option to specify which subvolume gets mounted. When the > volume is mounted without a subvol option, it mounts the whole tree. > The tree would be /btrfs/@ and /btrfs/@home if mounted from a rescue > disk. > > I think the symbol is visually striking, but it can be cumbersome > because @+ sometimes autocompletes as ipv6 addresses for root. > I'm also not sure if @ ever needs to be escaped \@. FWIW I have no memory of @ needed to be escape. A websearch on "linux shell when needs @ be escaped \@" ( https://www.google.nl/search?q=linux+shell++when+does+%40+needed+to+be+escaped+\%40 ) didn't show me that @ is special for bash. Doing @+ for autocompletion is done interactive by a thinking user, so I see no danger, I trust the thinking user. > Oh! I just booted OpenSUSE Leap (their LTS), and it looks like > they've now adopted the Ubuntu convention of using @. OpenSUSE has > also, to my knowledge, always avoided using the default subvolume. > Furthermore, OpenSUSE creates subvolumes for just about everything > @opt, @srv, @tmp, @usr/local, @var/crash, etc. > > Fedora 23 Workstation: When btrfs-style partitioning is selected, > their installer creates two subvolumes, home, and root. When the > volume is mounted to /btrfs without a subvol= option, the tree would > be /btrfs/home and /btrfs/root. Like Ubuntu and OpenSUSE default > subvolume is also not used. From what I gather this is a necessary > configuration to support btrfs send and receive. Eg: Bug #764056 is a > result of our current policy. > > Unlike LVM or disk partitions, all free space is shared between > subvolumes. In the future it will be possible to use qgroups (quota > groups) to prevent /var or /home from using up all available free > space in rootfs, but at this time I don't think we should support it > in the installer, because of the volume of associated bugs and code > churn on the linux-btrfs mailing list. Also, in the future it will be > possible to mount subvolumes with different options, but at this time > the first subvolume mounted sets the mount options for all members of > the volume--I'm not sure how to address this the D-I. > > In consultation with > https://btrfs.wiki.kernel.org/index.php/SysadminGuide#When_To_Make_Subvolumes > , a subvolume for rootfs and for /home seems sane, and sysadmins can > be instructed to consider making a subvolume for /var/www in > documentation. > > This brings us to a concern I have for documentation. How should > /var/www appear when it's mounted using a rescue disk? Should it be > /btrfs/var_www? If it was /btrfs/var/www, then the two possibilities > are: > > a)/btrfs/var is its own subvolume > and /btrfs/var/www is a child subvolume of /btrfs/var > > note: strictly speaking, all subvolumes what seems to be the root > volume are actually children of the default subvolume...the semantics > get tricky very quickly! > > or > > b)/btrfs/var is a normal directory > and in the case of /btrfs/var/www, www is actually a child of /btrfs. > > Finally, because subvolumes are partitions in POSIX namespace, it's > safe to mount a subvolume to two locations, and also to have a > /btrfs-admin directory where the whole volume is mounted, at the same > time as individual subvolumes are mounted. eg: you have your rootfs > mounted at /, and also at /btrfs-admin/rootfs or /btrfs-admin/@. > > The primary reason to do this is because most of the btrfs tools > operate on mountpoints rather than on devices. It also allows > centralisation of snapshots. eg: /btrfs-admin/snapshots is a normal > directory that holds snapshots of /btrfs-admin/rootfs, > /btrfs-admin/home, etc. > > Résumé: Do we follow Ubuntu and OpenSUSE with the @ convention and > work through the issues in bash-completion, or we follow Fedora's > plain text/alphanumeric convention, or do we do our own thing? The one which follows BTRFS upstream philosophy. However, I don't know if such guide exists. > Secondly, Do we want to limit the difficulty of supporting complicated > configurations by establishing simple conventions and recommendation > early on? eg: all subvolumes created in the installation are peers, > and a subvolume that will be mounted at /var/www is named var_ww
Re: joining the team
On 23 April 2016 at 02:43, Geert Stappers wrote: > On Fri, Apr 22, 2016 at 08:30:35PM -0400, Nicholas D Steeves wrote: >> to work on better btrfs integration. > > My respect for the itch scratching Thank you! I also hope it will help limit the number of btrfs issues submitted to the BTS as adoption of the fs increases. And also, the spirit of Debian is very much to give GPL software its best chance when competing against CDDL alternatives, no? ;-) Cheers, Nicholas
Re: joining the team
On 23 April 2016 at 02:57, Christian PERRIER wrote: > That's welcomed. The team, nowadays, is a bit small and most active > members have other commitments, either in Debian...or in many things > in RL, that makes the life of the team a bit less active than it has > been. Thank you :-) In the long-term, I'm not sure I'll have the time to do more than work on a very specific niche with very specific goals. > So, new energy and contributions are much welcomed. I kinda witnessed > your work on btrfs from far away and I thinnk the best to do is to > apply (on Alioth) for commit access to git so that you can directly > work on components where you'd like to see improvements. > > On behalf of the "team admins" (which shrinks to Cyril and /me) I > encourage you to do so. > Hi Christian! Yes, I remember you replied to my partman-btrfs RFS, concerning the rename of btrfs-tools to btrfs-progs. From what I gather, you prefer changes to be submitted with git, and Philipp Kern prefers diffs. As a result, I'm not sure what I'm I should be using... Also, is it a problem to publish Debian work on github? I've read that it is non-free, and wonder if I shouldn't be using it; it seemed like the only way to give you a git tree to pull from when I only have RO access to debian-installer on Alioth. Best regards, Nicholas
Bug#820483: accommodate rename of btrfs-tools to btrfs-progs
On 9 April 2016 at 03:04, Christian PERRIER wrote: > Quoting Nicholas D Steeves (nstee...@gmail.com): >> Package: partman-btrfs >> Version: 20 >> >> I am working on problems associated with bug #780081, where it was >> planned to have a fix staged in experimental after Jessie was >> released. > > > Changes seem to be OK, but I guess that we can't upload before the > btrfs-tools package hasn't been renamed, isn't it? > > From what I see, we need both btrfs-progs and the udeb in the archive > before partman-btrfs is uploaded, or it will: > - FTBFS > - fail when running > > I'm not sure if an upload to experimental is really useful, as the > installer and its components doesn't make good use of experimental. > > I'd say "go ahead for the package rename and we'll apply the changes > to partman-btrfs as soon as btrfs-progs is in unstable". Other > advices? An update: the btrfs-tools to btrfs-progs rename was uploaded to NEW earlier today. I've applied to join debian-boot both by email and on Alioth. Please approve the request if you'd like me to push my changes to Alioth. Otherwise, please let me know you'd prefer a diff, or to pull from my github tree. It seems I forgot to CC you my 9 April reply. Sorry about that! Sincerely, Nicholas
Re: joining the team
On 23 April 2016 at 07:28, Philipp Kern wrote: > Hi, > > On Fri, Apr 22, 2016 at 08:30:35PM -0400, Nicholas D Steeves wrote: >> I'd like to join the Debian Installer installer team to work on better >> btrfs integration. Recently I've been working on a rename of >> btrfs-tools to btrfs-progs, and I submitted at patch for >> partman-btrfs. The #1 feature I'd like to work on is support for >> installing to a btrfs subvolume. The #2 feature is btrfs-style >> multiple device support in the installer. > > that would be nice. I think submitting patches to the BTS is the right > way forward. Ok, I'll open two bugs for the two features once I've identified all the different parts that are affected. I've checked out a copy of debian installer according to the instructions on the wiki. >> I imagine #1 will be fairly easy. At this point in time I believe >> that #2 should be limited to the raid1 profile, with mandatory >> duplication of both metadata and data. Also, at this point in time I >> do not believe that compression should be supported. Additionally, >> I've read bug reports recommending displaying a notice in the >> installer as to the experimental nature of btrfs. That would be #3, >> but I'd be happy to re-prioritise it as #1 > > I think optimally the subvolume to install on could be preseeded for #1 > and be able to reuse an existing btrfs volume. Similarly it'd be nice > if one could provide some sort of list of subvolumes to create at > installation time. (Although touching the partman receipe stuff for this > might be a bit messy.) To break down the #1 goal "add subvolume support": a) Add ability to list existing, create, and delete subvolumes in partman-btrfs i. study partman-LVM to learn how to do this ii. alternatively, is partman-zfs in a state where I could use it as a base? -- I noticed that partman-zfs is based off of partman-LVM, and uses a lot of LVM terminology instead of ZFS -- This surprised me, because I thought partman-modules were independent from each other b) Provide defaults for this support in a preseed file i. study partman-LVM and example-preseed.txt to learn how to do this ii. alternatively, is partman-zfs in a state where I could use it as a base? c) How is "the subvolume to install on could be preseeded" distinct from "provide...list of subvolumes to create"? d) Tie into the module that manages fstab mount options, so a subvolume created for /var gets mounted with subvol=a_subvolume_for_var. This seems like the tricky part to me, and afaik there is no equivalent in LVM or zfs. Would this work also be limited to partman-btrfs, or are other modules/packages affected? > I don't think there needs to be such a scary warnings on the kernel > version stretch will ship with. What version is this likely to be? 4.4.x? 4.6.x? From a btrfs-perspective, I hope it's an LTS. >> The goal is to ship a "safest possible configuration", to enable those >> wish to use this next-gen filesystem to try it, while at the same time >> reducing bug reports that are caused by the current behaviour. For >> example one of the "killer features" of btrfs is the ability to dump a >> subvolume as a FAR data stream. This doesn't work out-of-the-box on >> Jessie, because the feature depends on a named subvolume. > > But right now it installs into "@", no? According to debian-installer/packages/partman-btrfs/TODO, support has not yet been added. I just installed debian-stretch-DI-alpha5-amd64-netinst; it failed at package selection after the base system was installed. I dropped to a shell to find out how the btrfs volume was set up. btrfs sub list /target (no output) mkdir /btrfs ; mount /dev/sda1 /btrfs btrfs sub list -a /btrfs (no output) <- if any subvolumes were created, they should have shown up here, without exception mount | grep btrfs /dev/sda1 on /target type btrfs (rw,noatime,space_cache,subvolid=5,subvol=/) /dev/sda1 on /dev/.static/dev type btrfs (rw,noatime,space_cache,subvolid=5,subvol=/dev) /dev/sda1 on /btrfs type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/) subvolid=5 is the default subvolume, and subvol=/ further specifies that this is not a subvolume. Unfortunately, like Jessie, it doesn't install into "@". @ is an Ubuntu convention (apparently adopted by OpenSUSE; stapp...@stappers.nl moved this discussion to the thread "New Thread old subject joining team"). Best regards, Nicholas
Bug#822353: marked as done ([keyboard-configuration] update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults)
Your message dated Sun, 24 Apr 2016 00:59:54 +0300 with message-id <20160423215954.ge14...@debian.lan> and subject line Re: Bug#822353: [keyboard-configuration] update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults has caused the Debian Bug report #822353, regarding [keyboard-configuration] update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 822353: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822353 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: keyboard-configuration Version: 1.123 Severity: normal #dpkg-reconfigure keyboard-configuration ... update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults https://lists.debian.org/debian-devel/2013/05/msg01109.html --- End Message --- --- Begin Message --- Package: keyboard-configuration Version: 1.138 On Sat, Apr 23, 2016 at 09:16:50PM +0300, Alexey Pikalev wrote: > > #dpkg-reconfigure keyboard-configuration > ... > update-rc.d: warning: start and stop actions are no longer supported; > falling back to defaults > > https://lists.debian.org/debian-devel/2013/05/msg01109.html Fixed in version 1.138. Anton Zinoviev--- End Message ---
Re: btrfs subvolume naming scheme
On 23 April 2016 at 07:38, New Thread old subject joining team wrote: > On Sat, Apr 23, 2016 at 01:28:43PM +0200, Philipp Kern wrote: >> On Fri, Apr 22, 2016 at 08:30:35PM -0400, Nicholas D Steeves wrote: >> >> > I'd also like to discuss whether the default subvolume naming scheme >> > should follow Ubuntu, Fedora, OpenSUSE, or something else. >> >> What scheme are they using? > > Or a proposal for default subvolume naming scheme? > Ubuntu avoids using the default subvolume (subvol ID 5). For the rootfs their installer creates a subvol called @, for /home it creates @home, etc. In fstab the device is specified and subvol=@ is added to the mount option to specify which subvolume gets mounted. When the volume is mounted without a subvol option, it mounts the whole tree. The tree would be /btrfs/@ and /btrfs/@home if mounted from a rescue disk. I think the symbol is visually striking, but it can be cumbersome because @+ sometimes autocompletes as ipv6 addresses for root. I'm also not sure if @ ever needs to be escaped \@. Oh! I just booted OpenSUSE Leap (their LTS), and it looks like they've now adopted the Ubuntu convention of using @. OpenSUSE has also, to my knowledge, always avoided using the default subvolume. Furthermore, OpenSUSE creates subvolumes for just about everything @opt, @srv, @tmp, @usr/local, @var/crash, etc. Fedora 23 Workstation: When btrfs-style partitioning is selected, their installer creates two subvolumes, home, and root. When the volume is mounted to /btrfs without a subvol= option, the tree would be /btrfs/home and /btrfs/root. Like Ubuntu and OpenSUSE default subvolume is also not used. From what I gather this is a necessary configuration to support btrfs send and receive. Eg: Bug #764056 is a result of our current policy. Unlike LVM or disk partitions, all free space is shared between subvolumes. In the future it will be possible to use qgroups (quota groups) to prevent /var or /home from using up all available free space in rootfs, but at this time I don't think we should support it in the installer, because of the volume of associated bugs and code churn on the linux-btrfs mailing list. Also, in the future it will be possible to mount subvolumes with different options, but at this time the first subvolume mounted sets the mount options for all members of the volume--I'm not sure how to address this the D-I. In consultation with https://btrfs.wiki.kernel.org/index.php/SysadminGuide#When_To_Make_Subvolumes , a subvolume for rootfs and for /home seems sane, and sysadmins can be instructed to consider making a subvolume for /var/www in documentation. This brings us to a concern I have for documentation. How should /var/www appear when it's mounted using a rescue disk? Should it be /btrfs/var_www? If it was /btrfs/var/www, then the two possibilities are: a)/btrfs/var is its own subvolume and /btrfs/var/www is a child subvolume of /btrfs/var note: strictly speaking, all subvolumes what seems to be the root volume are actually children of the default subvolume...the semantics get tricky very quickly! or b)/btrfs/var is a normal directory and in the case of /btrfs/var/www, www is actually a child of /btrfs. Finally, because subvolumes are partitions in POSIX namespace, it's safe to mount a subvolume to two locations, and also to have a /btrfs-admin directory where the whole volume is mounted, at the same time as individual subvolumes are mounted. eg: you have your rootfs mounted at /, and also at /btrfs-admin/rootfs or /btrfs-admin/@. The primary reason to do this is because most of the btrfs tools operate on mountpoints rather than on devices. It also allows centralisation of snapshots. eg: /btrfs-admin/snapshots is a normal directory that holds snapshots of /btrfs-admin/rootfs, /btrfs-admin/home, etc. Résumé: Do we follow Ubuntu and OpenSUSE with the @ convention and work through the issues in bash-completion, or we follow Fedora's plain text/alphanumeric convention, or do we do our own thing? Secondly, Do we want to limit the difficulty of supporting complicated configurations by establishing simple conventions and recommendation early on? eg: all subvolumes created in the installation are peers, and a subvolume that will be mounted at /var/www is named var_www. A default delimiter convention would also need to be chosen. I look forward to your replies, Cheers! Nicholas
Bug#405098: marked as done (Resizing/copying ext3 partitions with dir_index and resize_inode not supported)
Your message dated Sat, 23 Apr 2016 16:52:03 -0400 with message-id <571be073.3020...@ubuntu.com> and subject line Resizing/copying ext3 partitions with dir_index and resize_inode not supported has caused the Debian Bug report #405098, regarding Resizing/copying ext3 partitions with dir_index and resize_inode not supported to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 405098: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405098 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: debian-installer Severity: important i386 using RC1 netinst image I am copying my Debian installation onto a new hard drive with LVM and encrypted swap and /tmp. I tried to use the installer's option to "Copy data from partition," but after I selected the source partition, it complained about parted not being able to resize a partition that had dir_index enabled, saying that parted can only resize it if it disables dir_index first. I don't know why it would need to resize any of the partitions just to copy data from one partition to another, and I'm not sure if it was referring to the source partition, or the new, blank partition. The options in the dialog were "Ignore," "Cancel," and "Go Back." The first time I selected Ignore, and it started copying the data. At the end of the copy process, it started giving a series of error dialogs saying, "Block 2490887 shouldn't have been marked (1, 0)!" Choosing "Continue" caused it to pop up several more times, but the first number in the parentheses would double each time, and the block number would increase as well, though only by a few. After three or four of those, it would pop up a larger dialog saying, "Assertion (block < EXT2_SUPER_BLOCKS_COUNT)fs->sb)) at ../../../../libparted/fs/ext2/ext2.h:226 in function ext2_is_data_block() failed. \n\n A bug has been discovered! \n\n Ignore \n Cancel" (added "\n" myself to indicate newlines in error dialog) Choosing Ignore caused more of the "block shouldn't have been marked" errors, and after a few more of those, I'd get another one of this same larger error. IIRC, after getting into this situation, choosing Cancel or Go Back did the same as choosing Ignore, and the only way to get out of it was to reboot. But if I chose Cancel or Go Back when the first warning about resizing with dir_index appeared, all I got was a blank debconf screen, blue with a gray bay at the bottom, and no text. I rebooted then too. I've described this to the best of my recollection. Apologies for any errors. I will follow up with a few photos I took of some errors after I get my system running on the new disk. In the end, I used the rescue mode to use the Guided Partitioning for LVM and crypto setup, but then switched to a console and am copying over the data manually after making symlinks to the necessary libs so I could use GNU cp rather than busybox's. P.S. Is there no room for the GNU utils on the netinst iso? Busybox is nice but, for example, has no --help for cp, and no -v for cp either. I don't know about you, but when I'm copying tens of gigs of data, I'd like -v so I can see that it's working. :) --- End Message --- --- Begin Message --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Closing this old bug as all support for copying and resizing was removed some time ago. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJXG+BzAAoJEBB5UWFcu6UW4E0IAInlMDtcgoMgWXy10tV53nVx r04Gnne2Lp4K7tl4DAfg5HsZlb4x/YBn7LAKKO1JqrIxCQe0AEgVlAS3YdrPqU/p /64boxHCgcxaCDye5qv3OCFzTqwI+sze4QLzrG6zIhkiRKfndDPdR6SU5VsBFPTA KEoamJLlDXXkhOCbO/DtbRRL66bNBL3Mjbjh+ydoNm+W9gNVWGRp2QmzeYe+3A27 m6ABRFxKl93DP0U8tmhnouyGXjGUxeEyK7E7+bY+m34r1omQ7vi7sTQmS5K9GBgF MVyjyxnCeXfFeje72nVAFHEd/12J7DXw47bk94BmADfy7HN+e4gayG+lLv0aK+c= =mq7f -END PGP SIGNATURE End Message ---
Bug#822367: partman should check and warn if missing bios_grub partition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: partman-partitioning Version: 111 When installing to a GPT partitioned disk in bios mode, a bios_grub partition is required to install grub. Partman should warn the user of this if they do not have one. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCgAGBQJXG+AXAAoJEBB5UWFcu6UW2v8H/i/cK7EDTjQzijzf20V+wvLJ Z2bnCejkzvLfd/58lZ6ECHj/Vlp4Ab3ooyzrIsOr+fmLXeaPdD/hiE8/7NrHnoF8 K0jiXvfNC5GE6CLbhGb5LteArXPLIabAZboMklkPwlTobI55Xp/A3b4wzIQvu8JW Ar4LMUOhPC6AF9W9YuBYB8AcfI02O0cQf5zd75qNtNJg9NZ3PuZ4wVwqGhYHH3zl PZJOxCWWId/0gjhSf++3xOoJVLjYJVUUAc9Iry/pm0Usj57sofKx8ZhWM5TdCaGP eD+9oWshHn+MfIWMRRNHstWEriQAvJoBgeXr92DlYcc1856F9TqiqMmaYNIulF4= =wrti -END PGP SIGNATURE-
Re: Issues with Installation?
On 22 April 2016 at 21:36, Jen Longstreet wrote: > https://www.youtube.com/watch?v=u4A4r6wixN4 > > I do apologize for any shaking, background noises and fingers in the video. > This is what it has been doing since I installed from the first disc of > Debian. On 22 April 2016 at 20:47, Jen Longstreet wrote: > There are no error messages...it goes as if it will boot up but instead > of > booting, it goes to a black screen with a blinking cursor...this is any > time > after the installation this occurs...I can provide a short video of that > I > can take using my phone if It would help you understand better It looks like it isn't making it to GRUB; GRUB is the bootloader that lets your BIOS load the Linux kernel that Debian uses 99% of the time. To provide a recommendation on how to fix this I'll need more info. Could you please boot your installation media, and select rescue at the boot menu? Alternatively, type rescue at the boot: prompt. It will ask you some questions to find out where on your hard drive Debian is installed, and will then boot into it. From there you will be able to fix GRUB. But we're not there yet. The first thing I need to know is if you only have one hard drive, if there are no other operating systems installed, and if you're using the MBR or EFI bootloader. From the rescue shell, you can get this info with the command: parted -l (and press enter) <- this will show everything at once. If the text is legible, a photo is fine. or fdisk -l /dev/sda (press enter) fdisk -l /dev/sdb (...) If you get a graphical environment, then you can install gparted, or use the disk tool or partition manager that is already installed. Alternatively, if you're not comfortable with the command line you can use this live boot disk ( http://downloads.sourceforge.net/gparted/gparted-live-0.25.0-3-i686.iso ). Just boot it, find and open gparted (the graphical version of parted), and take a photo of what it finds. Also, in the upper-left of the window there will be a button that specifies which hard drive it looks at. You'll need to click that button and take a second photo if you have more than one hard drive. Oh, and actually fixing this is faster than gathering the info you need to fix it! Cheers, Nicholas
Bug#822353: [keyboard-configuration] update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Package: keyboard-configuration Version: 1.123 Severity: normal #dpkg-reconfigure keyboard-configuration ... update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults https://lists.debian.org/debian-devel/2013/05/msg01109.html
Bug#820911: installation-report: Accessibility for visual impaired is broken,, High-Contrast Theme is no longer activated by shortcut
On 04/16/2016 11:41 PM, Samuel Thibault wrote: Control: reassign -1 debian-installer Hello, Alex ARNAUD, on Wed 13 Apr 2016 17:51:45 +0200, wrote: I've tried to reproduce the instructions in the Debian installation guide in "Accessibility" section at "5.2.7 High-Contrast Theme" : https://www.debian.org/releases/jessie/amd64/ch05s02.html.en#idp71552032 * What was the outcome of this action? I'm not able to enable the high-contract theme. ? This works for me. Did you take care that the keyboard is using a qwerty layout at boot menu? Sorry for the lack of precisions. Like Steve McIntyre says, I speak about UEFI. * What outcome did you expect instead? The best way should be to have only a unique key shortcut (maybe "h" for high-contrast theme) to launch the ncurse installer. Well, it's not really the ncurses installer which matters, but selecting the dark theme. Now, a shortcut is something being considered, see thread on https://lists.debian.org/debian-boot/2016/01/msg00346.html I believe we agreed how we want it to look like, and now it's a "matter" of implementing it. Because of the severity of the issue I think a bug report is essential. This issue is the main barrier that renders visual impaired unable to install a Debian on recent computer. Personally the only way I found is to use my braille display to install Debian but I think I'm an exception, not all people can read braille and has braille display at his disposition. Best regards. -- Alex ARNAUD
Re: Use newer debian installer with old distro
Dear Alan, If you're going to install old release, you can try the so-called "unofficial/backports" d-i images, created by kmuto: - http://kmuto.jp/debian/d-i/ - http://cdimage.debian.org/cdimage/unofficial/backports/ Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
Bug#433568: [PATCH] Add vlan support, based on YunQiang Su patch and Philipp Kern's rewrite, with own additions. Closes: #433568
On Fri, Apr 15, 2016 at 03:17:00AM +0100, Dimitri John Ledkov wrote:
> ---
>
> Changes since last version:
> - Corrected Philipp's name
> - Adjusted vlan_failed text message
> - Adding a di_error if vlan_id is preseeded and not supported
> - Added NetworkManager vlan type
> - Sent templates for review
>From a patch point of view I'm mostly happy. But this should incorporate the
newly suggested templates as well. Plus there are a few nits below.
> +netcfg (1.139) UNRELEASED; urgency=medium
> +
> + * Add vlan support, based on YunQiang Su patch and Philipp Kern's
> +rewrite, with own additions. Closes: #433568
Please capitalize VLAN and put Closes into parantheses.
Suggested patch description:
Add VLAN support.
This is based on YunQiang Su patch and Philipp Kern's rewrite, with own
additions.
Closes: #433568
> +
> + -- Dimitri John Ledkov Mon, 04 Apr 2016 12:18:08 +0100
> +
> netcfg (1.138) unstable; urgency=medium
>
>[ Hendrik Brueckner ]
> diff --git a/debian/netcfg-common.templates b/debian/netcfg-common.templates
> index 2b77936..ebbfbb3 100644
> --- a/debian/netcfg-common.templates
> +++ b/debian/netcfg-common.templates
> @@ -26,6 +26,34 @@ _Description: Domain name:
> If you are setting up a home network, you can make something up, but make
> sure you use the same domain name on all your computers.
>
> +Template: netcfg/use_vlan
> +Type: boolean
> +Default: false
> +# :sl6:
> +_Description: Are you connected to an IEEE 802.1Q VLAN trunk port?
> + Virtual LAN (VLAN) is a concept of partitioning a physical network to create
> + distinct broadcast domains. Packets can be marked for different IDs by
> + tagging, so that a single interconnect (trunk) may be used to transport
> + data for various VLANs.
> + .
> + If your network interface is directly connected to a VLAN trunk port,
> + specifying a VLAN ID may be necessary to get a working connection.
> +
> +Template: netcfg/vlan_id
> +Type: string
> +# :sl6:
> +_Description: VLAN ID (1-4094):
> + If your network interface is directly connected to a VLAN trunk port,
> + specifying a VLAN ID may be necessary to get a working connection.
> +
> +Template: netcfg/vlan_failed
> +Type: error
> +# :sl6:
> +_Description: Error setting up VLAN
> + The command used to set up VLAN during the installation returned an
> + error, please check installer logs, or go back and try another
> + configuration.
> +
> Template: netcfg/get_nameservers
> Type: string
> # :sl1:
> @@ -371,4 +399,3 @@ _Choices: ${essid_list} Enter ESSID manually
> # :sl1:
> _Description: Wireless network:
> Select the wireless network to use during the installation process.
> -
> diff --git a/dhcp.c b/dhcp.c
> index fe06950..9476bac 100644
> --- a/dhcp.c
> +++ b/dhcp.c
> @@ -459,7 +459,7 @@ int netcfg_activate_dhcp (struct debconfclient *client,
> struct netcfg_interface
> kill_dhcp_client();
> loop_setup();
>
> -interface_up(interface->name);
> +netcfg_interface_up(interface);
>
> for (;;) {
> di_debug("State is now %i", state);
> diff --git a/netcfg-common.c b/netcfg-common.c
> index c6d1d8d..ac2c6df 100644
> --- a/netcfg-common.c
> +++ b/netcfg-common.c
> @@ -267,7 +267,7 @@ int is_raw_80211(const char *iface)
>
> #if defined(__s390__)
> // Layer 3 qeth on s390(x) cannot do arping to test gateway reachability.
> -int is_layer3_qeth(const char *iface)
> +int is_layer3_qeth(const struct netcfg_interface *interface)
> {
> const int bufsize = 1024;
> int retval = 0;
> @@ -277,6 +277,12 @@ int is_layer3_qeth(const char *iface)
> ssize_t slen;
> char* driver;
> int fd;
> +char* iface;
> +
> +if (interface->parentif)
> +iface = interface->parentif;
> +else
> +iface = interface->name;
>
> // This is sufficient for both /driver and /layer2.
> len = strlen(SYSCLASSNET) + strlen(iface) + strlen("/device/driver") + 1;
> @@ -329,7 +335,7 @@ out:
> return retval;
> }
> #else
> -int is_layer3_qeth(const char *iface __attribute__((unused)))
> +int is_layer3_qeth(const struct netcfg_interface *interface
> __attribute__((unused)))
> {
> return 0;
> }
> @@ -1338,6 +1344,24 @@ void interface_down (const char *if_name)
> }
> }
>
> +void netcfg_interface_up (const struct netcfg_interface *iface)
> +{
> + if (iface->parentif)
> + interface_up (iface->parentif);
> +
> + if (iface->name)
> + interface_up (iface->name);
> +}
> +
> +void netcfg_interface_down (const struct netcfg_interface *iface)
> +{
> + if (iface->name)
> + interface_down (iface->name);
> +
> + if (iface->parentif)
> + interface_down (iface->parentif);
> +}
> +
> void parse_args (int argc, char ** argv)
> {
> if (argc == 2) {
> @@ -1528,7 +1552,7 @@ int netcfg_detect_link(struct debconfclient *client,
> const struct netcfg_interfa
> if (ethtool_lite(if_name) == 1) /* ethtool-lite
Re: btrfs subvolume naming scheme
On Sat, Apr 23, 2016 at 01:28:43PM +0200, Philipp Kern wrote: > On Fri, Apr 22, 2016 at 08:30:35PM -0400, Nicholas D Steeves wrote: > > > I'd also like to discuss whether the default subvolume naming scheme > > should follow Ubuntu, Fedora, OpenSUSE, or something else. > > What scheme are they using? Or a proposal for default subvolume naming scheme?
Re: joining the team
Hi, On Fri, Apr 22, 2016 at 08:30:35PM -0400, Nicholas D Steeves wrote: > I'd like to join the Debian Installer installer team to work on better > btrfs integration. Recently I've been working on a rename of > btrfs-tools to btrfs-progs, and I submitted at patch for > partman-btrfs. The #1 feature I'd like to work on is support for > installing to a btrfs subvolume. The #2 feature is btrfs-style > multiple device support in the installer. that would be nice. I think submitting patches to the BTS is the right way forward. > I imagine #1 will be fairly easy. At this point in time I believe > that #2 should be limited to the raid1 profile, with mandatory > duplication of both metadata and data. Also, at this point in time I > do not believe that compression should be supported. Additionally, > I've read bug reports recommending displaying a notice in the > installer as to the experimental nature of btrfs. That would be #3, > but I'd be happy to re-prioritise it as #1 I think optimally the subvolume to install on could be preseeded for #1 and be able to reuse an existing btrfs volume. Similarly it'd be nice if one could provide some sort of list of subvolumes to create at installation time. (Although touching the partman receipe stuff for this might be a bit messy.) I don't think there needs to be such a scary warnings on the kernel version stretch will ship with. > The goal is to ship a "safest possible configuration", to enable those > wish to use this next-gen filesystem to try it, while at the same time > reducing bug reports that are caused by the current behaviour. For > example one of the "killer features" of btrfs is the ability to dump a > subvolume as a FAR data stream. This doesn't work out-of-the-box on > Jessie, because the feature depends on a named subvolume. But right now it installs into "@", no? > I'd also like to discuss whether the default subvolume naming scheme > should follow Ubuntu, Fedora, OpenSUSE, or something else. What scheme are they using? Kind regards and thanks Philipp Kern
cdebconf_0.209_i386.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 22 Apr 2016 15:39:45 +0200 Source: cdebconf Binary: cdebconf cdebconf-gtk libdebconfclient0 libdebconfclient0-dev cdebconf-udeb cdebconf-priority libdebconfclient0-udeb cdebconf-text-udeb cdebconf-newt-udeb cdebconf-gtk-udeb Architecture: source i386 all Version: 0.209 Distribution: unstable Urgency: medium Maintainer: Debian Install System Team Changed-By: Christian Perrier Description: cdebconf - Debian Configuration Management System (C-implementation) cdebconf-gtk - Gtk+ frontend for Debian Configuration Management System cdebconf-gtk-udeb - Gtk+ frontend for Debian Configuration Management System (udeb) cdebconf-newt-udeb - Newt frontend for Debian Configuration Management System (udeb) cdebconf-priority - Change debconf priority (udeb) cdebconf-text-udeb - Plain text frontend for Debian Configuration Management System (udeb) cdebconf-udeb - Debian Configuration Management System (C-implementation) (udeb) libdebconfclient0 - Debian Configuration Management System (C-implementation library) libdebconfclient0-dev - Development files for cdebconf libdebconfclient0-udeb - Debian Configuration Management System (C-implementation) (udeb) Changes: cdebconf (0.209) unstable; urgency=medium . [ Updated translations ] * Serbian (sr.po) by Dragan Filipović Checksums-Sha1: a2e6d40c4a7a6b1488748cb45e97803da5771455 2662 cdebconf_0.209.dsc 8578b6b3fe4348cae2885a33227ada17bfa840cc 271928 cdebconf_0.209.tar.xz 60c4b1b932d9906c4d2efa3a95bb241abfed1070 216158 cdebconf-dbgsym_0.209_i386.deb a356fa662398c1410bdcddbf476115c7401b07e9 82182 cdebconf-gtk-dbgsym_0.209_i386.deb b925e97dc4606393ddd31bc97d6f13dfa392aaae 32122 cdebconf-gtk-udeb_0.209_i386.udeb 0a441df2f52bb83c8fc01ed26e5619064bb65e6f 75200 cdebconf-gtk_0.209_i386.deb cd3c0db8ff7077cf27ea35c2b7852e3590bc8d11 21160 cdebconf-newt-udeb_0.209_i386.udeb d77deffe8cb58e4a6fe40527c69cacb298db4fc8 3160 cdebconf-priority_0.209_all.udeb d4b8c14a44e1bc0cf2db0802ca2df6346f58a1d4 24566 cdebconf-text-udeb_0.209_i386.udeb b6b9193715da4763e62628f89d112c0a4ef1c0f4 82194 cdebconf-udeb_0.209_i386.udeb 149a3599871d23d8d3f6e20c887c48107aefd142 182590 cdebconf_0.209_i386.deb 5f6fc1f1a3244946a9b07ce858bb97f0bd182020 5280 libdebconfclient0-dbgsym_0.209_i386.deb 6a20028c8d54b16dd7b0f75bb3e541ed679a70c4 51958 libdebconfclient0-dev_0.209_i386.deb 47a3bb6fea2251566cecdd7c59049e2fc3c1d4ca 3282 libdebconfclient0-udeb_0.209_i386.udeb c1ff6f1201644406026d7ddd823a495b24f69cb1 47540 libdebconfclient0_0.209_i386.deb Checksums-Sha256: 0938cb7bbd3d9898f1452104b83eeeb106c1212de4df08ef1141019c2eb436b2 2662 cdebconf_0.209.dsc d3fbeebee38f76bef1720a3eaf44133b295ec9ebf06d9c392a70b6d38c8697fb 271928 cdebconf_0.209.tar.xz 3c4f1895535e631f09e1ffad406655cea75cd3a64beac9ed3044b64e4f594fe5 216158 cdebconf-dbgsym_0.209_i386.deb 804c29de862e4b63acd96539a26e7a67c065a90f0090fd33359a43ff99b65c57 82182 cdebconf-gtk-dbgsym_0.209_i386.deb 7b87f6df0c4b16d5316edb70d579cfc3d84510a9d6fde7d660091d66ac91d579 32122 cdebconf-gtk-udeb_0.209_i386.udeb a8dcdc90729353ab0e1c3e785e44927c52f1cad9881c4155f57ac00d02a9f204 75200 cdebconf-gtk_0.209_i386.deb 9219b21e98334f2f2b342a55eaaf712db53de0f2db3013313d5ed730c407a827 21160 cdebconf-newt-udeb_0.209_i386.udeb abbe8478e63686368f67b9e0e49ef11223f506f6ccf2e90a1acbf8fcbbccb028 3160 cdebconf-priority_0.209_all.udeb 5ccc3d4d9573bdaaa10144be6f228b19989c437774d0f6fe196105402c6791a2 24566 cdebconf-text-udeb_0.209_i386.udeb 2131a6bf6b6d9d15bf5346b601826792653d3e30b5cf1446ca20dd603e1c1d08 82194 cdebconf-udeb_0.209_i386.udeb f2dcd75698f2d07c4450ea796b476c9952a9c18cee189e2ecbec7f49398bf832 182590 cdebconf_0.209_i386.deb 29c006baaa0620f5f0dd39e62928cc6c0a4d8731ccde1242edae9efd6820ea25 5280 libdebconfclient0-dbgsym_0.209_i386.deb 821c0657d8d89db1eb3dcb64062795bc0be74be3b143fa540d333b779cd2c3e7 51958 libdebconfclient0-dev_0.209_i386.deb 64b5ae69f423ff583cbd6d3d45818375ab35a8d939f6dc4f8341ca8f41e02371 3282 libdebconfclient0-udeb_0.209_i386.udeb 860a178d9a5039f73773e072654a112f0487bb23836c8a8a05cbdda60ac3158d 47540 libdebconfclient0_0.209_i386.deb Files: 21cd91aefaa0dc4386bfd7374afa0679 2662 utils optional cdebconf_0.209.dsc 5abcbaab54c4f4f6ecf18f7e438c9bdd 271928 utils optional cdebconf_0.209.tar.xz 85995aed887ddd65e505eb3061315bdc 216158 debug extra cdebconf-dbgsym_0.209_i386.deb c553f28823c13ccd987b150d6859be7a 82182 debug extra cdebconf-gtk-dbgsym_0.209_i386.deb 49b93f3606197a23c6aa127245d78217 32122 debian-installer optional cdebconf-gtk-udeb_0.209_i386.udeb cb2a43f8f11c20b5621b1b6e25390fda 75200 admin extra cdebconf-gtk_0.209_i386.deb 6e2d9b54b62d0bff9c545613897a6023 21160 debian-installer optional cdebconf-newt-udeb_0.209_i386.udeb e6d6fdf03d601bb0210b00c9c2745609 3160 debian-installer standard cdebconf-priority_0.209_all.udeb c57adbb26e316dd1c6ded570660c03aa 24566 debian-installer optional cdebconf-text-udeb_0.209_i386
Processing of cdebconf_0.209_i386.changes
cdebconf_0.209_i386.changes uploaded successfully to ftp-master.debian.org along with the files: cdebconf_0.209.dsc cdebconf_0.209.tar.xz cdebconf-dbgsym_0.209_i386.deb cdebconf-gtk-dbgsym_0.209_i386.deb cdebconf-gtk-udeb_0.209_i386.udeb cdebconf-gtk_0.209_i386.deb cdebconf-newt-udeb_0.209_i386.udeb cdebconf-priority_0.209_all.udeb cdebconf-text-udeb_0.209_i386.udeb cdebconf-udeb_0.209_i386.udeb cdebconf_0.209_i386.deb libdebconfclient0-dbgsym_0.209_i386.deb libdebconfclient0-dev_0.209_i386.deb libdebconfclient0-udeb_0.209_i386.udeb libdebconfclient0_0.209_i386.deb Greetings, Your Debian queue daemon (running on host coccia.debian.org)
Processing of cdebconf_0.209_i386.changes
cdebconf_0.209_i386.changes uploaded successfully to localhost along with the files: cdebconf_0.209.dsc cdebconf_0.209.tar.xz cdebconf-dbgsym_0.209_i386.deb cdebconf-gtk-dbgsym_0.209_i386.deb cdebconf-gtk-udeb_0.209_i386.udeb cdebconf-gtk_0.209_i386.deb cdebconf-newt-udeb_0.209_i386.udeb cdebconf-priority_0.209_all.udeb cdebconf-text-udeb_0.209_i386.udeb cdebconf-udeb_0.209_i386.udeb cdebconf_0.209_i386.deb libdebconfclient0-dbgsym_0.209_i386.deb libdebconfclient0-dev_0.209_i386.deb libdebconfclient0-udeb_0.209_i386.udeb libdebconfclient0_0.209_i386.deb Greetings, Your Debian queue daemon (running on host franck.debian.org)
