Re: [PATCH] Backup old boot sectors before installation
Zhu Yi wrote: On Mon, 2009-12-14 at 11:24 +0800, Isaac Dupree wrote: hmm bootloader installation is often done by distro install-CDs. Will the distro be smart enough to save these backups to the disk somewhere sensible, rather than to the temporary in-memory filesystem? The backup files will (normally) be stored in /boot/grub/ together with grub.cfg and core.img. if it's there, then excellent, you are right. After all, /boot/grub needs to be permanently on the disk in order for the installed bootloader to work, also :-) ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
On Mon, 2009-12-14 at 11:24 +0800, Isaac Dupree wrote: > hmm > bootloader installation is often done by distro install-CDs. > > Will the distro be smart enough to save these backups to the disk > somewhere sensible, rather than to the temporary in-memory > filesystem? The backup files will (normally) be stored in /boot/grub/ together with grub.cfg and core.img. I assume it is not in memory. No? Thanks, -yi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
On Mon, 2009-12-14 at 10:58 +0800, Isaac Dupree wrote: > maybe the boot sector is small enough that we could just keep > separate > additional backup files each time grub-setup/grub-install is used? > e.g. > backup-1 > backup-2 > backup-3 > > or maybe using date/time instead of sequential numbering would be > nicer. Yup, I thought this before. This is certainly an option, but it also requires the user to remember what is 1, 2, 3 or what did I do on date1, date2, date3 on the recovery. Thanks, -yi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
richardvo...@gmail.com wrote: An automatic backup is valuable both for savvy users who know how but forgot, and for those who will find the backup and restore procedures online only after their computer is bricked. hmm bootloader installation is often done by distro install-CDs. Will the distro be smart enough to save these backups to the disk somewhere sensible, rather than to the temporary in-memory filesystem? I'm... Just being paranoid enough to ask this question -- I never quite trust by install CDs not to install a bootloader, because I have to find the right place in the GUI install sequence to disable doing so (and hope that disabling works -- as a supposedly "advanced" option, sometimes it's not been tested enough). Anything GRUB2 upstream can do to make this less risky will make me happy! ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
On Mon, 2009-12-14 at 10:59 +0800, kashyap garimella wrote: > In conclusion, I believe this backup feature is useful and > either > implementation should do the work. If we can merge the good > parts of > them, we can get a better one. I just curious why the thread > is stuck > since September. Any blocking issues with it? Can we keep the > topic > moving forward? Your comments are highly welcome. > > The reason is very simple. If you are good user, you should have > already backed up your copy on your own. And this feature is not > necessary. Is grub2 only designed for "good users"? I'm not. Or at least, Ubuntu update-grub2 script is not. It messes up with the two disks (with drivemap? not sure) in my laptop and overwrote PGP encrypted hard disk. That's the motivation for me to write this patch. Boot sectors are important. You know how to backup is one story. But when to backup is another and even important in this case. Thanks, -yi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
>> In conclusion, I believe this backup feature is useful and either >> implementation should do the work. If we can merge the good parts of >> them, we can get a better one. I just curious why the thread is stuck >> since September. Any blocking issues with it? Can we keep the topic >> moving forward? Your comments are highly welcome. >> > The reason is very simple. If you are good user, you should have already > backed up your copy on your own. And this feature is not necessary. That opinion was voiced, then countered and I think even the author of that opinion eventually retracted it. An automatic backup is valuable both for savvy users who know how but forgot, and for those who will find the backup and restore procedures online only after their computer is bricked. > > -Garimella Kashyap > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
On Mon, Dec 14, 2009 at 8:18 AM, Zhu Yi wrote: > On Fri, 2009-12-11 at 17:39 +0800, Felix Zielcke wrote: > > > > Someone already made a patch for this inside grub-setup > > See here and also for the discussion of it: > > http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00242.html > > Thanks. If I knew this patch, I won't try to write one my own. I did do > some basic search and asked in #grub2 IRC before writing it though. > > Anyway, I did a quick review for Garimella's patch. Both the ideas of > the two patches are the same: backup the mbr and boot sectors will be > overwritten by core.img to a file before grub2 overwrites them. The > implementations slightly differ in: > > 1. The format of the backup file. > > The old boot sectors and the start of embed_region position is required > for both patches. Garimella also added some redundant fields (i.e. image > size and 0xff) for integrity checking. I think it's a good idea. But > something like a md5/sha1 checksum should be even better. > > 2. The image backup and recovery. > > Both of the patches choose to backup the old boot sectors in > grub-setup.c. On the recovery, Garimella selected to do it in > grub-setup.c and I used grub-install script with dd(1). I don't think > this is a very big deal and either way is OK. The reason I choose > grub-install is I want to keep the grub-setup.c as clean as possible. > Because given the backup file format, one can recover it with dd(1) even > without any help with grub-setup. > > md5/sha sum is a good idea. If you want, I can implement it. > 3. The backup policy. > > Garimella's patch backups every time before grub-setup overwrote the > boot sectors. There might be a problem when someone run > grub-setup/grub-install twice. So the backup image ends up with the > grub2 boot sectors. This makes the recovery for the "real" boot sectors > impossible. My patch won't overwrite if a previous backup image already > existed. grub-install will remove the backup image after a successful > recovery. > I think this is questionable. Some prefer to backup only the previous copy of mbr. Some prefer to save the oldest copy. We can take the users' opinion. > 4. Blocklists installation. > > This is not very important because blocklists is not recommended. To be > completeness, my patch backups the mbr if blocklists are used due to > embedding is not possible. This will be detected by grub-install as > well. > > > In conclusion, I believe this backup feature is useful and either > implementation should do the work. If we can merge the good parts of > them, we can get a better one. I just curious why the thread is stuck > since September. Any blocking issues with it? Can we keep the topic > moving forward? Your comments are highly welcome. > > The reason is very simple. If you are good user, you should have already backed up your copy on your own. And this feature is not necessary. -Garimella Kashyap ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
Zhu Yi wrote: 3. The backup policy. Garimella's patch backups every time before grub-setup overwrote the boot sectors. There might be a problem when someone run grub-setup/grub-install twice. So the backup image ends up with the grub2 boot sectors. This makes the recovery for the "real" boot sectors impossible. My patch won't overwrite if a previous backup image already existed. grub-install will remove the backup image after a successful recovery. maybe the boot sector is small enough that we could just keep separate additional backup files each time grub-setup/grub-install is used? e.g. backup-1 backup-2 backup-3 or maybe using date/time instead of sequential numbering would be nicer. -Isaac ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Backup old boot sectors before installation
On Fri, 2009-12-11 at 17:39 +0800, Felix Zielcke wrote: > > Someone already made a patch for this inside grub-setup > See here and also for the discussion of it: > http://lists.gnu.org/archive/html/grub-devel/2009-09/msg00242.html Thanks. If I knew this patch, I won't try to write one my own. I did do some basic search and asked in #grub2 IRC before writing it though. Anyway, I did a quick review for Garimella's patch. Both the ideas of the two patches are the same: backup the mbr and boot sectors will be overwritten by core.img to a file before grub2 overwrites them. The implementations slightly differ in: 1. The format of the backup file. The old boot sectors and the start of embed_region position is required for both patches. Garimella also added some redundant fields (i.e. image size and 0xff) for integrity checking. I think it's a good idea. But something like a md5/sha1 checksum should be even better. 2. The image backup and recovery. Both of the patches choose to backup the old boot sectors in grub-setup.c. On the recovery, Garimella selected to do it in grub-setup.c and I used grub-install script with dd(1). I don't think this is a very big deal and either way is OK. The reason I choose grub-install is I want to keep the grub-setup.c as clean as possible. Because given the backup file format, one can recover it with dd(1) even without any help with grub-setup. 3. The backup policy. Garimella's patch backups every time before grub-setup overwrote the boot sectors. There might be a problem when someone run grub-setup/grub-install twice. So the backup image ends up with the grub2 boot sectors. This makes the recovery for the "real" boot sectors impossible. My patch won't overwrite if a previous backup image already existed. grub-install will remove the backup image after a successful recovery. 4. Blocklists installation. This is not very important because blocklists is not recommended. To be completeness, my patch backups the mbr if blocklists are used due to embedding is not possible. This will be detected by grub-install as well. In conclusion, I believe this backup feature is useful and either implementation should do the work. If we can merge the good parts of them, we can get a better one. I just curious why the thread is stuck since September. Any blocking issues with it? Can we keep the topic moving forward? Your comments are highly welcome. Thanks, -yi ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] mips & gfxterm kludge
On Sun, Dec 13, 2009 at 11:05:50PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > Robert Millan wrote: > > Possible approach to solving mips / gfxterm kludge. > > > > Comments? > > > > > It's already done cleanly when using some changes from gfxmenu branch > (look at how it was solved in experimental) Oh, ok. -- Robert Millan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: execution of update-grub in chroots might fail
* Michael Prokop wrote: > as reported in #550337 update-grub might fail inside chroots. > I'm providing detailed information about this issue in this mail as > discussed on IRC in #grub. [...] > The problem is NOT the grub package itself (it installs and updates > just fine). The problem exists in packages that call update-grub but > don't have a clean interface *when* (and how) to execute it. See > #481468 and #550337 for example. [...] Sorry for not being explicit enough: the mentioned bug ids refer to Debian's bug tracking system, so #550337 refers to http://bugs.debian.org/550337 #481468 refers to http://bugs.debian.org/481468 #550337 refers to http://bugs.debian.org/550337 etc. regards, -mika- ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: my plan for Multiboot 2
Bogdan wrote: > Is it just me or does this whole thing on abandoning Multiboot 2 seem like a > terrible idea? (That's a retorical question since I've already talked to > several people in the OSDev community about it.) The only reason why people > still use Multiboot is because it's the best we've got. It's not flexible and > it's way behind the needs of current OSes. > > It's a misunderstanding. We don't abandon multiboot2. The draft we want to discard isn't much better than multiboot1. But we will develop multiboot1 in a way to become multiboot2 and to correspond to the need of OSes. The best you can push it is by helping us with describing and implementing features you need. As Robert said our resources are scarce that's why just a suggestion is probably not enough, you need to do things. > Instead of several versions of Multiboot 1 popping up for other CPU > architectures we could just have Multiboot 2. One day people will finally > realise that no one can cope with Multiboot 1 anymore and by then we'll need > to support both Multiboot 1 and Multiboot 2 in all kernels/boot loaders even > for non-x86 architectures. > > I prefer to have tagged multiboot before going non-x86 > Cheers, > Bogdan > > > > > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
execution of update-grub in chroots might fail
[Please Cc me on replies as I'm not subscribed to the ML but read/write through gmane. Thanks] Hi, as reported in #550337 update-grub might fail inside chroots. I'm providing detailed information about this issue in this mail as discussed on IRC in #grub. Situation = For example postinst of memtest86+ uses: if [ "$1" = "configure" ] && [ -x "`which update-grub2 2>/dev/null`" ] ; then update-grub2 fi which is the recommended and suggested way to install grub menu entries. Problem === When executing update-grub the command might fail. For example it *does* fail inside chroots on openvz containers (see end of mail for full details regarding the setup in question): # update-grub2 grub-probe: error: cannot find a device for /. Then the installation of for example the memtest86+ package fails. Recommended fixes were (binded) mounting /proc, /sys and /dev, though this is already present and doesn't help. The problem is NOT the grub package itself (it installs and updates just fine). The problem exists in packages that call update-grub but don't have a clean interface *when* (and how) to execute it. See #481468 and #550337 for example. Affected: The problem affects at least (verified) current Debian/unstable and Debian/testing. Rationale = People having to deal with chroots for deployments or building live systems usually want to ship grub as bootloader. Then grub needs to be installed as *package* inside the chroot *without* the need for an existing grub.cfg and having grub in the boot sector of any physical device of the build system. Instead grub is being used as bootloader on the later deployed system/live system instead. So grub being installed in a chroot without directly accessing/using it there is necessary and common practice. This works for the grub package itself just fine, but fails for any package that wants to install additional menu files through update-grub. Implementing the according logic (when to execute update-grub and when not) inside the non-grub packages isn't a reasonable approach IMHO because it would require changes in *any* single package as soon as *something* needs to be changed, instead of adjusting just the interface script once when necessary. What I'm searching for == An official and clean way how packages can interact with grub without failing in situations like the mentioned openvz setup. Addon: It would be nice if there's a way to skip grub commands inside chroots completely (and that there's no need for mount --bind of /dev). It's often not needed as the hardware of the chroot doesn't match the system where grub is finally being used (for example also see #538118). Possible solutions == 1) Maintainer scripts of non-grub packages use 'update-grub || true' so the grub-probe call doesn't cause the package to fail its installation (which doesn't affect chroots only but is just a workaround then). 2) The grub package provides a way to disable any grub related commands like update-grub, grub-install,... so they can be just called by the maintainer scripts of non-grub packages without having to deal with situations like openvz. (Could be realized by preseeding and/or a configuration file.) Could be combined with a dpkg trigger. 3) grub-probe learns how to deal with the openvz situation (though this might fail in other similar and existing situations and doesn't really solve the interface issue AFAICT). 4) The grub package provides an official interface to update-grub for maintainer scripts. Like policy-rc.d exists for invoke-rc.d a specific interface for grub would provide maintainers as well as admins a way to configure grub setup and its command execution according to their needs. Could be combined with a dpkg trigger as well. Details regarding /proc/mounts of the setup in question === On the host system: # mount /dev/md1 on / type ext3 (rw,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) # cat /proc/mounts none /sys sysfs rw,nosuid,nodev,noexec 0 0 none /proc proc rw,nosuid,nodev,noexec 0 0 udev /dev tmpfs rw,size=10240k,mode=755 0 0 /dev/md1 / ext3 rw,errors=remount-ro,data=ordered 0 0 tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0 usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0 /var/lib/vz/private/3000 /var/lib/vz/root/3000 simfs rw 0 0 tmpfs /var/lib/vz/root/3000/lib/init/rw tmpfs rw,nosuid,mode=755 0 0 proc /var/lib/vz/root/3000/proc proc rw,nosuid,nodev,noexec 0 0
Re: [PATCH] mips & gfxterm kludge
Robert Millan wrote: > Possible approach to solving mips / gfxterm kludge. > > Comments? > > It's already done cleanly when using some changes from gfxmenu branch (look at how it was solved in experimental) -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH] mips & gfxterm kludge
Possible approach to solving mips / gfxterm kludge.
Comments?
--
Robert Millan
=== modified file 'term/gfxterm.c'
--- term/gfxterm.c 2009-10-24 19:01:27 +
+++ term/gfxterm.c 2009-12-13 20:37:57 +
@@ -27,7 +27,7 @@
#include
#include
-#define DEFAULT_VIDEO_MODE "1024x600"
+#define DEFAULT_VIDEO_MODE "640x480,800x600,1024x768,0x0"
#define DEFAULT_BORDER_WIDTH 10
#define DEFAULT_STANDARD_COLOR 0x07
=== modified file 'video/sm712.c'
--- video/sm712.c 2009-12-02 10:48:10 +
+++ video/sm712.c 2009-12-13 20:33:44 +
@@ -55,7 +55,7 @@ grub_video_sm712_video_fini (void)
{
if (framebuffer.mapped)
grub_pci_device_unmap_range (framebuffer.dev, framebuffer.ptr,
- 1024 * 600 * 2);
+ framebuffer.mode_info.width * framebuffer.mode_info.height * (framebuffer.mode_info.depth / 8));
return grub_video_fb_fini ();
}
@@ -68,7 +68,7 @@ grub_video_sm712_setup (unsigned int wid
grub_err_t err;
int found = 0;
- int NESTED_FUNC_ATTR find_card (grub_pci_device_t dev, grub_pci_id_t pciid __attribute__ ((unused)))
+ int NESTED_FUNC_ATTR find_card (grub_pci_device_t dev, grub_pci_id_t pciid)
{
grub_pci_address_t addr;
grub_uint32_t class;
@@ -92,8 +92,16 @@ grub_video_sm712_setup (unsigned int wid
depth = (mode_type & GRUB_VIDEO_MODE_TYPE_DEPTH_MASK)
>> GRUB_VIDEO_MODE_TYPE_DEPTH_POS;
- if ((width != 1024 && width != 0) || (height != 600 && height != 0)
- || (depth != 16 && depth != 0))
+ if (width == 0)
+width = 1024;
+
+ if (height == 0)
+height = 600;
+
+ if (depth == 0)
+depth = 16;
+
+ if (width != 1024 || height != 600 || depth != 16)
return grub_error (GRUB_ERR_NOT_IMPLEMENTED_YET,
"Only 1024x600x16 is supported");
@@ -107,10 +115,10 @@ grub_video_sm712_setup (unsigned int wid
}
/* Fill mode info details. */
- framebuffer.mode_info.width = 1024;
- framebuffer.mode_info.height = 600;
+ framebuffer.mode_info.width = width;
+ framebuffer.mode_info.height = height;
framebuffer.mode_info.mode_type = GRUB_VIDEO_MODE_TYPE_RGB;
- framebuffer.mode_info.bpp = 16;
+ framebuffer.mode_info.bpp = depth;
framebuffer.mode_info.bytes_per_pixel = 2;
framebuffer.mode_info.pitch = 1024 * 2;
framebuffer.mode_info.number_of_colors = 256;
@@ -126,7 +134,7 @@ grub_video_sm712_setup (unsigned int wid
/* We can safely discard volatile attribute. */
framebuffer.ptr = (void *) grub_pci_device_map_range (framebuffer.dev,
framebuffer.base,
- 1024 * 600 * 2);
+ width * height * (depth / 8));
framebuffer.mapped = 1;
err = grub_video_fb_create_render_target_from_pointer (&framebuffer.render_target, &framebuffer.mode_info, framebuffer.ptr);
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: var=foo should be valid?
Hi, On Dec/12/2009, Carles Pina i Estany wrote: > We should fix it. We have three options (maintaining the current > behaviour for the user): > > > a) simple_patch (just swapping that two lines) After talking with Robert last night and for the time being I've committed the simple one (r1933) to fix the current bug. -- Carles Pina i Estany http://pinux.info ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: my plan for Multiboot 2
Is it just me or does this whole thing on abandoning Multiboot 2 seem like a terrible idea? (That's a retorical question since I've already talked to several people in the OSDev community about it.) The only reason why people still use Multiboot is because it's the best we've got. It's not flexible and it's way behind the needs of current OSes. Instead of several versions of Multiboot 1 popping up for other CPU architectures we could just have Multiboot 2. One day people will finally realise that no one can cope with Multiboot 1 anymore and by then we'll need to support both Multiboot 1 and Multiboot 2 in all kernels/boot loaders even for non-x86 architectures. Cheers, Bogdan ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
