want some advice on grub 2 chaining issues
Want to figure out whether to file a bug on this or not, and maybe how many.
Three drives, four installs of Linux at this time.
80G drive hung off the motherboard's controller, 16OG and 320G hung
off the expansion card's controller in the master positions of the
primary and secondary channels:
00:0f.0 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
ata-Maxtor_4R080L0_R2T745PE
00:07.0 Mass storage controller: Integrated Technology Express, Inc.
IT/ITE8212 Dual channel ATA RAID controller (rev 13)
ata-Maxtor_6B160P0_B41H5J7H
ata-WDC_WD3200AAJB-00J3A0_WD-WCAV2Z842365
Debian is in the 1st partition of the 80G drive on the motherboard's
controller, single partition.
Fedora 14 is in the 1st and 3rd partition of the 160G drive on the
primary channel of the expansion card. Also, a liveCD install of F14
on the 4th partition of the 320G drive.
Fedora 15 is on the 1st and 2nd partitions of the 320G drive.
With only one drive connected (at the same points as above), I can
boot each of the OSses.
With all three connected as above, I can only boot Debian and the F14
on the 160G drive. But I can't chain boot anything.
Trying to boot the 320G drive or chain boot the 160G or 320G drive,
there is no response after the selector screen.
Trying to chain boot the 80G drive to itself gives the message,
"invalid signature".
/etc/grub.d/40_custom:
---
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
# chainload the first three disks blindly
menuentry "chain first drive (self)" {
# set root=(hd0,1)
insmod part_msdos
insmod ext2
set root=(hd2,msdos1)
search --no-floppy --fs-uuid --set=root 32e25b11-5b7b-4686-b6bd-e36159a3162b
chainloader +1
}
menuentry "chain second" {
# set root=(hd1,1)
insmod part_msdos
insmod ext2
set root=(hd0,msdos1)
search --no-floppy --fs-uuid --set root=6f56e069-9379-4552-91d9-e30920bbd173
chainloader +1
}
menuentry "chain third" {
# set root=(hd3,1)
insmod part_msdos
insmod ext2
set root=(hd1,msdos1)
search --no-floppy --fs-uuid --set=root bfb92d48-0cd1-4eb0-8e33-ea54e93936dd
chainloader +1
}
menuentry "chain third part 4" {
# set root=(hd3,4)
insmod part_msdos
insmod ext2
set root=(hd1,msdos4)
search --no-floppy --fs-uuid --set=root da739f32-f4b4-4632-bc74-4e908ea02d2c
chainloader +1
}
-- /boot/grub/device.map--
(hd0) /dev/disk/by-id/ata-Maxtor_6B160P0_B41H5J7H
(hd1) /dev/disk/by-id/ata-WDC_WD3200AAJB-00J3A0_WD-WCAV2Z842365
(hd2) /dev/disk/by-id/ata-Maxtor_4R080L0_R2T745PE
--/boot/grub/grub.cfg after update-grub:
-
rover@deb:~$ cat /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
insmod part_msdos
insmod ext2
set root='(hd2,msdos1)'
search --no-floppy --fs-uuid --set 32e25b11-5b7b-4686-b6bd-e36159a3162b
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
load_video
insmod gfxterm
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='(hd2,msdos1)'
search --no-floppy --fs-uuid --set 32e25b11-5b7b-4686-b6bd-e36159a3162b
set locale_dir=($root)/boot/grub/locale
set lang=ja
insmod gettext
set timeout=5
play 480 440 1
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='(hd2,msdos1)'
search --no-floppy --fs-uuid --set 32e25b11-5b7b-4686-b6bd-e36159a3162b
insmod png
if background_image /usr/share/images/desktop-base/spacefun-grub.png; then
set color_normal=light-gray/black
set color_highlight=white/black
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/08_os-prober ###
menuentry "Fedora (2.6.35.13-91.fc14.i686.PAE) (on /dev/sdb1)" {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set 6f56e069-9379-4552-91d9-e30920bbd173
linux /boot/vmlinuz-2.6.35.13-91.fc14.i686.PAE ro
root=UUID=6f56e069-9379-4552-91d9-e30920bbd173 rd_LVM_LV=f15/f15_swap
rd_LVM_LV=vg_f11/f11swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=ja_JP.UTF-8
KEYTABLE=jp106 rhgb quiet
initrd /boo
Bug#637452: Lower priority of first user's fullname question
(Noise from a sometimes user) On Fri, Aug 12, 2011 at 1:27 AM, Lennart Sorensen wrote: > On Thu, Aug 11, 2011 at 05:20:57PM +0100, Colin Watson wrote: >> On Thu, Aug 11, 2011 at 05:34:30PM +0100, Miguel Figueiredo wrote: >> > Good question, but the installer just setups the first account, doesn't >> > manage >> > user's accounts. >> >> The installer should set up the first account in a manner that does not >> require later management simply in order to bring it into sync with how >> future accounts would be created, especially for such a user-facing >> thing as the user's full name. > > Exactly. > > Why should my first account that is most likely mine, not show nicely > in kdm and gdm and such by default? I'm not a developer or even a regular user. My opinion is my own. But this is sort of a favorite topic with me. In a corporate environment, the user name would not necessarily have any connection with a real person. Whether Debian wants to target a corporate environment or not aside, even a privately owned machine should have an admin account separate from both root and the regular user's working account. That should probably be the first account set up. I ranted on this some years back, on my personal web server where very few people would end up seeing it, but I'll post a link to the rant for reference: <http://reiisi.homedns.org/~joel/cs/security/makesafeusers.html>. Like much on my website, it needs a lot of work, but perhaps it would provide some food for thought here. Joel Rees -- 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/CAAr43iN=3OO6myWmUwMbSpKzvTAZ-=ZO5=izf+gvy5cypxl...@mail.gmail.com
Bug#637452: Lower priority of first user's fullname question
(Noise from a sometimes user who forgets that the debian list handles mail correctly, and fails to put the list address in the To: field) On Fri, Aug 12, 2011 at 1:27 AM, Lennart Sorensen wrote: > On Thu, Aug 11, 2011 at 05:20:57PM +0100, Colin Watson wrote: >> On Thu, Aug 11, 2011 at 05:34:30PM +0100, Miguel Figueiredo wrote: >> > Good question, but the installer just setups the first account, doesn't >> > manage >> > user's accounts. >> >> The installer should set up the first account in a manner that does not >> require later management simply in order to bring it into sync with how >> future accounts would be created, especially for such a user-facing >> thing as the user's full name. > > Exactly. > > Why should my first account that is most likely mine, not show nicely > in kdm and gdm and such by default? I'm not a developer or even a regular user. My opinion is my own. But this is sort of a favorite topic with me. In a corporate environment, the user name would not necessarily have any connection with a real person. Whether Debian wants to target a corporate environment or not aside, even a privately owned machine should have an admin account separate from both root and the regular user's working account. That should probably be the first account set up. I ranted on this some years back, on my personal web server where very few people would end up seeing it, but I'll post a link to the rant for reference: <http://reiisi.homedns.org/~joel/cs/security/makesafeusers.html>. Like much on my website, it needs a lot of work, but perhaps it would provide some food for thought here. Joel Rees -- 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/CAAr43iP5yLFPdcqe7gOm1qzpsMtodTDBmt=s2qwgeuw+ryq...@mail.gmail.com
Re: How to get installer to align partitions on 4096 byte boundaries?
On Sun, May 4, 2014 at 5:14 PM, Rick Thomas wrote: > [...] > > So I ask again: Aside from doing the partitioning manually, myself, is > there any way to get the installer's partitioner to respect the new > guidelines for "Advanced Format" and SSD/flash disks? > Have you tried not using a Macintosh partition map -- using a DOS/BIOS partition map instead? Then you should be able to use the more normal partitioning tools. Or, kind of the reverse, have you tried partitioning it with the Mac OS installer's disk utility? Or pdisk? -- Joel Rees Be careful where you see conspiracy. Look first in your own heart.
Re: How to get installer to align partitions on 4096 byte boundaries?
On Sun, May 4, 2014 at 11:53 PM, Rick Thomas wrote: > > On May 4, 2014, at 1:24 AM, Joel Rees wrote: > > > On Sun, May 4, 2014 at 5:14 PM, Rick Thomas wrote: > > [...] > > > >> So I ask again: Aside from doing the partitioning manually, myself, is > there any way to get the installer's partitioner to respect the new > guidelines for "Advanced Format" and SSD/flash disks? > >> > > Have you tried not using a Macintosh partition map -- using a DOS/BIOS > partition map instead? Then you should be able to use the more normal > partitioning tools. > > > > Or, kind of the reverse, have you tried partitioning it with the Mac OS > installer's disk utility? Or pdisk? > > Hi Joel, > > Thanks for the suggestions. Unfortunately, I don't think they would > work... > > It's the boot disk for a Mac. It *has* to have a Macintosh partition map. > A DOS partition map would not be understood by the Mac firmware, > It's been a while since I had time to mess with ppc. (Not enough working displays in the house, and dyndns is no longer free, so the old ppc mini is sleeping right now.) But my memory is that you can, in fact, use DOS partition formats on some of the ppc hardware produced towards the end-of-line period. If that's something you want to think about. Really wish Jobs had been more willing to try carrying the PPC line in parallel with the intel line. I'm sure his plans to switch again to ARM had something to do with things, ... > And anyway, the object of the exercise is to use the default installer for > PowerPC Macs, not to force it manually, as would be the case with your > second suggestion. > To what purpose? Anyway, you do know about the manual options. One more thought, it was not so long ago that the entire idea of trying to fight with a hard disks internal idea of the physical layout of the partitions was considered counterproductive. Are you then, primarily, focused on less-intelligent controllers for bulk flash persistent store? If so, I'm thinking that we need a feature request for the partitioning tools. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart.
Re: installing debian
On Thu, May 8, 2014 at 4:42 AM, monique morris wrote: > i would like to install debian on my mac g5 because i'm interested in this > linux ox > linux ox? ;-) Try this list: https://lists.debian.org/debian-powerpc/ And these pages: http://www.debian.org/releases/stable/powerpc/ -- Joel Rees Be careful where you see conspiracy. Look first in your own heart.
Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop
2014/08/08 18:14 "Yves-Alexis Perez" : > > [...] > > Put it another way, Xfce (and other DEs) have been hurt by the various > enforced transitions (ConsoleKit, > hal/devicekit-power/upower/upower-0.99), yes. Combined with the lack of > resources, that means it lays behind the people who decided those > transitions. > > Regards, > -- > Yves-Alexis As a user trying to find to participate more, can I put a huge "+1" on that? (Lots of things I'd like to help with on XFCE, among other things, but the recent transitions have been eating what time I might have had, plus a bit of work time I can't afford.) -- Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Reverting to GNOME for jessie's default desktop
2014/08/08 6:58 "Jordi Mallach" : > > Hi Debian, > > It's been around 9 months since tasksel changed (for real) the default > desktop for new installs. At the time of the change, it was mentioned > the issue would be revisited before the freeze, around debconf time. > > Well, it's roughly that time. :) So I'd like to plainly request GNOME is > reinstated as the default desktop environment for a number of reasons. First thought: Since systemd has been chosen as the one true way of the future, it seems only obvious that GNOME should be the default desktop. > Accessibility: GNOME continues to be the only free desktop environment that > provides full accessibility coverage, right from login screen. While it’s true > GNOME 3.0 was lacking in many areas, and GNOME 3.4 (which we shipped in wheezy) > was just barely acceptable thanks to some last minute GDM fixes, GNOME 3.12 > should have ironed out all of the issues and our non-expert understanding is > that a11y support is now on par with what GNOME 2.30 from squeeze offered. There are a number of regular participants on debian-user who have a11y needs. Would it be too much to ask, to ask them whether GNOME meets their needs? > Downstream health: The number of active members in the team taking care of > GNOME in Debian is around 5-10 persons, while it is 1-2 in the case of Xfce. > Being the default desktop draws a lot of attention (and bug reports) that only > a bigger team might have the resources to handle. It has been mentioned in the past, but developers work on what they want to work on. That may or may not be related to whether a particular DE is appropriate for general rcommendation. > Upstream health: While GNOME is still committed to its time-based release > schedule and ships new versions every 6 months, Xfce upstream is, > unfortunately, struggling a bit more to keep up with new plumbing technology. > Only very recently it has regained support to suspend/hibernate via logind, or > support for Bluez 5.x, for example. Should consider the reasons for the breakage, as well. > Community: GNOME is one of the biggest free software projects, and is lucky to > have created an ecosystem of developers, documenters, translators and users > that interact regularly in a live social community. Users and developers gather > in hackfests and big, annual conferences like GUADEC, the Boston Summit, or > GNOME.Asia. Only KDE has a comparable community, the rest of the free desktop > projects don’t have the userbase or manpower to sustain communities like this. With a community that big, would it be unreasonable to ask them to maintain their own distro? Or perhaps their own liveCD? Eh, well, liveSD. > Localization: Localization is more extensive and complete in GNOME. Xfce has > 18 languages above 95% of coverage, and 2 at 100% (excluding English), GNOME > has 28 languages above 95%, 9 of them being complete (excluding English). LOL. No, seriously, is there any meaning to the claim of "complete"? I've seen a lot of bad Japanese translation, recently, that, if I had more time, I'd file bugs on. > Documentation: Documentation coverage is extensive in GNOME, with most of the > core applications providing localized, up to date and complete manuals, > available in an accessible format via the Help reader. See above. Documentation and translation have something in common here. Particularly since documentation should be translation from technical language to the more common vernacular. > Hardware: GNOME 3.12 will be one of the few desktop environments to support > HiDPI displays, now very common on some laptop models. Lack of support for > HiDPI means non-technical users will get an unreadable desktop by default, and > no hints on how to fix that. > > Security: GNOME is more secure. There are no processes launched with root > permissions on the user’s session. All everyday operations (package management, > disk partitioning and formatting, date/time configuration…) are accomplished > through PolicyKit wrappers. > > Privacy: One of the latest focuses of GNOME development is improving privacy, > and work is being done to make it easy to run GNOME applications in isolated > containers, integrate Tor seamlessly in the desktop experience, better disk > encryption support and other features that should make GNOME a more secure > desktop environment for end users. > > Popularity: One of the metrics discussed by the tasksel change proponents > mentioned popcon numbers. 8 months after the desktop change, Xfce does not seem > to have made a dent on install numbers. The Debian GNOME team doesn’t feel > popcon’s data is any better than a random online poll though, as it’s an opt-in > service which the vast majority of users don’t enable. > > systemd embracing: One of the reasons to switch to Xfce was that it didn’t > depend on systemd. But now that systemd is the default, that shouldn’t be a > problem. Also given ConsoleKit is deprecated and dead upstream, KDE and Xfce > a
Re: Reverting to GNOME for jessie's default desktop
(Sure wish I could get drivers for this Acer tablet so I could get replace the vendor-constricted Android with a real OS and get software that wouldn't misinterpret what my fingers do on the screen. But, then, I suppose I should go to the trouble of booting up a regular computer for this.) 2014/08/11 7:32 "Joel Rees" : > > 2014/08/08 6:58 "Jordi Mallach" : > > > > > Hi Debian, > > > > It's been around 9 months since tasksel changed (for real) the default > > desktop for new installs. At the time of the change, it was mentioned > > the issue would be revisited before the freeze, around debconf time. > > > > Well, it's roughly that time. :) So I'd like to plainly request GNOME is > > reinstated as the default desktop environment for a number of reasons. > > First thought: Since systemd has been chosen as the one true way of the future, it seems only obvious that GNOME should be the default desktop. > > > Accessibility: GNOME continues to be the only free desktop environment that > > provides full accessibility coverage, right from login screen. While it’s true > > GNOME 3.0 was lacking in many areas, and GNOME 3.4 (which we shipped in wheezy) > > was just barely acceptable thanks to some last minute GDM fixes, GNOME 3.12 > > should have ironed out all of the issues and our non-expert understanding is > > that a11y support is now on par with what GNOME 2.30 from squeeze offered. > > There are a number of regular participants on debian-user who have a11y needs. Would it be too much to ask, to ask them whether GNOME meets their needs? > > > Downstream health: The number of active members in the team taking care of > > GNOME in Debian is around 5-10 persons, while it is 1-2 in the case of Xfce. > > Being the default desktop draws a lot of attention (and bug reports) that only > > a bigger team might have the resources to handle. > > It has been mentioned in the past, but developers work on what they want to work on. That may or may not be related to whether a particular DE is appropriate for general rcommendation. > > > Upstream health: While GNOME is still committed to its time-based release > > schedule and ships new versions every 6 months, Xfce upstream is, > > unfortunately, struggling a bit more to keep up with new plumbing technology. > > Only very recently it has regained support to suspend/hibernate via logind, or > > support for Bluez 5.x, for example. > > Should consider the reasons for the breakage, as well. > > > Community: GNOME is one of the biggest free software projects, and is lucky to > > have created an ecosystem of developers, documenters, translators and users > > that interact regularly in a live social community. Users and developers gather > > in hackfests and big, annual conferences like GUADEC, the Boston Summit, or > > GNOME.Asia. Only KDE has a comparable community, the rest of the free desktop > > projects don’t have the userbase or manpower to sustain communities like this. > > With a community that big, would it be unreasonable to ask them to maintain their own distro? Or perhaps their own liveCD? Eh, well, liveSD. > > > Localization: Localization is more extensive and complete in GNOME. Xfce has > > 18 languages above 95% of coverage, and 2 at 100% (excluding English), GNOME > > has 28 languages above 95%, 9 of them being complete (excluding English). > > LOL. > > No, seriously, is there any meaning to the claim of "complete"? > > I've seen a lot of bad Japanese translation, recently, that, if I had more time, I'd file bugs on. > > > Documentation: Documentation coverage is extensive in GNOME, with most of the > > core applications providing localized, up to date and complete manuals, > > available in an accessible format via the Help reader. > > See above. Documentation and translation have something in common here. Particularly since documentation should be translation from technical language to the more common vernacular. > > > Hardware: GNOME 3.12 will be one of the few desktop environments to support > > HiDPI displays, now very common on some laptop models. Lack of support for > > HiDPI means non-technical users will get an unreadable desktop by default, and > > no hints on how to fix that. I'm thinking this sounds like an argument for postponing freeze. > > Security: GNOME is more secure. There are no processes launched with root > > permissions on the user’s session. All everyday operations (package management, > > disk partitioning and formatting, date/time configuration…) are accomplished > > through PolicyKit wrappers. With the volume of new code, can su
Re: Reverting to GNOME for jessie's default desktop
On Mon, Aug 11, 2014 at 7:49 AM, Joel Rees wrote: (Having booted up a real OS, but still using Google's webmail fake MUA. heh.) > [...] > 2014/08/11 7:32 "Joel Rees" : >> 2014/08/08 6:58 "Jordi Mallach" : >> >> [...] >> > systemd embracing: One of the reasons to switch to Xfce was that it >> > didn’t >> > depend on systemd. But now that systemd is the default, that shouldn’t >> > be a >> > problem. Also given ConsoleKit is deprecated and dead upstream, KDE and >> > Xfce >> > are switching or are planning to switch to systemd/logind. > > Isn't this essentially the sum of your thesis That is, isn't this your thesis, in sum? >> > In addition to this, moving to Xfce now would mean yet another >> > transition to >> > a new desktop (if we consider GNOME 2.x → 3.x a transition, which it >> > is), >> > which would mean a new round of adapation for users installing Debian >> > from >> > scratch, and only after two years after getting used to the GNOME 3 >> > workflow. >> > jessie's GNOME 3.x release should be a lot more polished than what we >> > shipped >> > with wheezy, which means many of the rough edges and annoyances people >> > may >> > have found when upgrading from squeeze are probably now ironed out. So, we should move, yet again, before any CDs get burned, lest anyone doubt debian's allegiance to the one-true-and-coming-OS? (I should have held my tongue on that, I suppose, since these are the dev lists, and I am making some serious requests below.) >> > Many members of the Debian GNOME team feel shipping Xfce by default >> > would >> > mean regressing in a few key areas like, as mentioned before, >> > accessibility, >> > localisation and documentation of the default set of applications. We >> > are wary >> > about the state of some features of the current default with respect >> > to power management and bluetooth, for example. These features are >> > driven by, >> > and working since day 1, by GNOME 3.12. >> > >> > Jordi >> > -- >> > Jordi Mallach Pérez -- Debian developer http://www.debian.org/ >> > jo...@sindominio.net jo...@debian.org http://www.sindominio.net/ >> > GnuPG public key information available at http://oskuro.net/ Two years from now, your list of reasons might make sense. Right now, there has been no time to gather the sort of statistics needed to support your assertions. But, and I mean this seriously, since debian has made the move to systemd, it seems to me that your assertions are superfluous. It makes no sense not to make Gnome3 the default DE. That means, I think, that it also makes no sense to have a CD install image other than netinstall. It would be nice if the install media made DE options a little more accessible than is currently the case. I'm not sure if my memories here are from debian, but it seems to me that it used to be fairly easy to select, say, a desktop productivity set of initial packages and then go in and change the DE from Gnome2 to XFCE. Last time I tried the easy install, I didn't see any way to do that, and I ended up having to remove Gnome3 and install XFCE after the first boot. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- 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/caar43iofaofevnotsmnrbatqmwnvgm5p7ah_rqj1n4gvcdg...@mail.gmail.com
Re: Reverting to GNOME for jessie's default desktop
2014/08/12 1:12 "Jonas Smedegaard" : > > [...] > Still you are talking about cost in time. Few I have met in developing > countries were poor measured in time available. > [...] Developed country (Japan). My wife makes me scrimp on everything, so I still have megabit/sec download. Fiber or 10 Mb/s copper would cost me some JPY1000 a month more, up to about 3500/mo. (Roughly JPY100 to USD1.00.) So, when I download DVDs, I plan on leaving the download going all day. But I don't download DVDs because the installer will go to the net for the latest anyway, if you let it. Of course, that means upgrading to Jessy is going to be two days of down time. -- Joel Rees Computer memory is just fancy paper, CPUs just fancy pens. All is a stream of text flowing from the past into the future.
Re: Use dedicated partition for /boot/grub instead of /boot
2014/08/18 14:57 "Christopher Chavez" <2000...@gmail.com>: > > (Please let me know if there's a better venue for collecting feedback for this > idea, or additional ones I should solicit feedback from. I primarily use Ubuntu, > but I assume this is as upstream as it gets.) Upstream relative to what? Boot managers have their own projects and mailing lists. > Background: > > It has been discussed (in other venues) where a separate /boot partition (e.g. > for btrfs, LVM, and encrypted installations; or to workaround BIOS limitations), > depending on how large it was when created, will have a likelihood of becoming > full after multiple kernel updates, and there are corresponding bug reports > likewise (which I have not listed here). debian, at any rate, has not had problems with old kernels filling up the /boot partition for a long time. I don't care for the way it's being done, but it pretty much works. > One proposed measure was to not use a /boot partition in the first place, which > often works, but I have also managed to have installations fail with "core.img > is unusually large", particularly in instances where the disk was pre-formatted, > including Windows multiboot scenarios. I generally never bothered with a separate /boot on i386 back in the days of Fedora 4 or so, but I knew my BIOS could see the whole drive. openbsd uses a different partitioning scheme and a different way to boot, fits the boot-up code and all the openbsd partitions within a single BIOS recognized partition. It uses a kind of relay or trampoline technique, so the code that the BIOS passes control off to doesn't ever have to move. Grub 1 was kind of like that, too, but in a different way. openbsd can boot without a boot manager, but the whole purpose of grub is to hand off the boot to something else. > 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. That information used to be a lot more available, until some IPidiots started trying to claim rights to it. But you can still find it on wikipedia. But I think your question was answered in the chat session you quoted below. And elsewhere in this thread. It occurs to me that putting grub in its own partition might make it easier for the various distros to cooperate about updating the grub configuration file. But I don't know if anyone is working on that. I would definitely not do it with the old BIOS partitions. Not enough partitions to work with. > 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.) Have you found a way to tell each distro to use the independent grub? > 3. If so, then what should its size be? Does it vary by installation and is it > expected to grow over time? (In my case it requires ~5MB for i386, so I used a > ~30MB ext4 partition. I have not considered UEFI, e.g. if using the ESP is > better.) Have you looked at the grub project's site? > I attempted to collect some preliminary feedback on IRC (the following was > logged publicly): > > #ubuntu, 25 Jul 2014: > > [00:50] Does the size of /boot/grub vary by installation or > > over time, making it undesirable for separate partition? see description: > >http://ur1.ca/htmwi(Unsure if a support or development question, since I am > > seeking knowledge/opinion.) > > [00:52] chrstphrchvz: Yes, it can vary slightly as newer kernels are > > installed, if older kernels aren't also removed. I generally use a 512MB > > /boot/ file-system partition > > [00:56] chrstphrchvz: A separate /boot is something of an > > anachronism, dating back to limited PC BIOSes that could only handle small > > disks, so the boot files had to be at the start of the disk. Nowadays, this is > > no longer applicable . ^^^*^^^ > > [00:57] TJ-, I mean specifically /boot/grub rather than /boot > > (i.e. as an alternative). E.g. I can keep /boot on my root partition, and use > > a separate /boot/grub, but is a good idea? (I know it works.) > > [00:58] chrstphrchvz: You're asking to confuse GRUB, since it expects > > /boot/ and /boot/grub/ to be in the same root file-system or, more specifically, the grub configuration updater tool. > > [00:59] chrstphrchvz: but specifically, grub/ doesn't vary much in size, > > it contains the GRUB loadable modules, the saved environment, and grub.cfg > > [01:04] Bashing-om, GRUB is (theoretically) able to boot LVM > > etc. (what it is typically installed with nowadays) without a /boot partition, > > but it can result in "core.img unusually large" and failing to install (see > > description for cases). >
Re: LVM installer: select percentage of VG to use
2014/10/04 17:48 "Brian Candler" : > > In the current Debian installer[1], if you select Guided Partitioning with LVM, the entire volume group is allocated for filesystems and swap. > > This means you lose much of the flexibility of LVM (e.g. being able to choose which filesystems to extend later, or being able to create new logical volumes). You could reclaim space later by shrinking one of the filesystems/LVs, but this is relatively painful as it must be done off-line. > > This pretty much forces you to do a long-winded manual install if you want to leave space in your volume group, e.g. see[2] > https://nsrc.org/workshops/2014/wacren-virtualization/raw-attachment/wiki/Agenda/ex-debian-kvm-libvirt.htm#partitioning > > The Ubuntu installer fixed this by asking the user what percentage of the volume group to use. This simple feature is a huge improvement. > > Is there any chance this feature could be ported into Debian? Has this been discussed before? > > Thanks, > > Brian Candler. > > [1] I've just re-tested this with Jessie Beta 1, and the behaviour is unchanged > > [2] This is from a virtualization workshop using Debian as the base platform. We need to leave space in the volume group for creating logical volumes for virtual machines, with Ganeti. Today we have to make students do the whole long-winded process of creating logical volumes for root, swap and /var by hand. > Summarizing my interpretation of a number of threads on the subject, it is assumed that any default layout is going to be wrong, so just provide the layout least likely to cause serious problems. I think the idea is that people who have reason to use LVM should not want to use any default layout. I think, in my ideal world today, if you filed this as a bug/feature request and I tried to propose a fix (I'm not a dev.), I'd propose a guided partitioning script, starting with the question you suggest, but in reverse -- a target for how much to leave available. Then a couple of questions about intended use, a default layout that "ought to work" for the intended use, and slider controls to adjust the layout. Having used MacOS partitioning tools, I suspect the primary result of such an approach would be more people who think they know more than they do. But, hey, that's the basic result of every tool we make and let others use. At least, in our free/libre/open world, the source is open and can be learned from, to some extent, by those willing to look. Joel Rees It's five in the morning, I need to go to bed.
Re: serious problem, I don't know where to report!
On Sun, Aug 18, 2013 at 7:09 AM, Steven Chamberlain wrote: > On 17/08/13 16:56, Jack Wilborn wrote: >> [...] >> sending any kind of e-mail or writing virtually impossible. Ｔｈｅ >> ｔｈｉｎｇｓ ｃｈａｎｇｅｓ ｆｏｎｔｓ！！ > > Oh, wow! > > It's not actually the 'font' changing there, but the character set or > 'Unicode plane', I think; non-ASCII characters are being typed for some > reason. Does it always trigger after the first sentence? Good idea, try to figure out what triggers it, if not shift-space or ctrl-space. > Which desktop environment are you using? (GNOME, KDE, XFCE, LXDE...) > The maintainers of the relevant desktop environment might know what > causes this. I think they would be first interested in what he installed just before this started. > You may need to check settings for keyboard layout, language and > similar. I have a feeling your desktop is configured for an Asian > script instead of whatever you were expecting. I was thinking any of the scripts that allow more characters than the keyboard has would do the trick, including, say, Spanish. But I'm not familiar with how accents and tildes are input in Spanish. And I'm pretty sure Spanish doesn't use the double width versions of Latin, so maybe not Spanish after all. Asian includes Arab, Hebrew, Thai, and so forth, as well, of course. Japanese is the most easily suspect, since it's the Japanese encodings that basically forced the double width characters to be included in Unicode, IIRC. > Regards, > -- > Steven Chamberlain > ste...@pyro.eu.org Do Steven's comments help, Jack? I sure wasn't firing on all cylinders when I posted this morning. May not be firing on all cylinders, now. Hope I didn't cause too much confusion. -- Joel Rees -- 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/CAAr43iPny-YehaWO5iOz=PUnnDPb_J2E16Zm=hd8yiy-1je...@mail.gmail.com
Re: Problem with rogue translator
On Fri, Sep 13, 2013 at 4:46 PM, Fòram na Gàidhlig wrote: > [...] > I am sorry, but I am new to the project and there is no instructions on your > homepage that I can find for a central l10n list, or whom to contact about > central issues concerning translations. > [...] Ehhhttto ... > To UNSUBSCRIBE, [...] > Archive: http://lists.debian.org/5232c2e2.2030...@foramnagaidhlig.net Hmm. I wonder what one might find here: http://lists.debian.org/ ;-P -- Joel Rees -- 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/caar43iosxjumxeqdrz3++ujzszs24zeg7oygfsrjw_vfdmn...@mail.gmail.com
Re: Acer c720 OS replacement
2015/09/17 4:27 "Jake Lar" : > > Hello, I'm replacing the Chrome operating system on my Acer c720 That is an Intel processor. > and I'm not sure which netinst CD image is appropriate for the Exynos 5250 GAIA ARM processor That is not the processor in the c720. > (haswell architecture). Haswell is a code name for certain intel processors, none of which are ARM. > Could you give me any direction with this? As Miguel and Sergio indicate, AMD64 seems to be indicated if you really are talking about the c720. > Thank you! > > -J
Re: RFC: Switching guided partitioning to LVM by default?
2017/08/06 5:07 "Cyril Brulebois" : > > Hi, > > While preparing some slides for my “News from the Debian Installer” talk > at DebConf17, it occured to me that we might want to reconsider the > default here: > > Guided - use a whole disk > Guided - use a whole disk with LVM > Guided - use a whole disk with encrypted LVM > Manual > > Current default is the first entry, and I think we should switch to > second one, with LVM. > > If the user doesn't need to touch anything, that doesn't change much; if > the user wants to change partitioning afterwards, LVM's flexibility is > available. > > Is anyone aware of any drawbacks of switching to LVM by default? > > > KiBi. This would be a source of a lot of confusion and flame wars and other back-and-forth on debian-user. Making LVM a recommended, guided option with a lot of hand-holding, sure, especially if the default includes making a MSWindows readable partition for sharing. But that is not whole disk. Forcing people to do what we think is good for them never works out well. -- Joel Rees http://reiisi.blogspot.com
Bug#771040: installation-reports: Messes up Mac OS 9 driver partitions
On Wed, Nov 26, 2014 at 6:12 PM, Dan DeVoto wrote: > Package: installation-reports > Severity: normal > > Dear Maintainer, > > Installation was flawless, except the installer somehow makes my Mac > OS 9 partition unbootable. This can be fixed by booting from an OS 9 > install CD, running Drive Setup, and updating the drivers. This > appears to fix the driver partitions, but obviously this shouldn't > happen in the first place. > It's a long-standing bug, see for instance, http://ppcluddite.blogspot.jp/2012/03/installing-debian-linux-on-ppc-part-v.html I don't remember whether I ever blogged about it, but I found I could use dd to dump the partition table segments and use those to restore Mac OS9 bootability when the CD driver restore wouldn't work (as in when using a non-Apple drive). Another factor was the size of the drive involved, for me. Tangerine clamshell, and the ROM was written with the assumption of max 120G HD. Using a 160G HD made it harder to keep the MAC OS-9 partition bootable. -- Joel Rees Be careful when you look at conspiracy. Look first in your own heart, and ask yourself if you are not your own worst enemy. Arm yourself with knowledge of yourself, as well. -- 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/caar43iobv92yyvm_pew6wp7s5ph1x0wgsar9_oe+ft6rars...@mail.gmail.com
